Best Practices
Place config where it is used
Group Properties in Interface
Include an AndHowInit class in your deployable artifact, not in library or dependency
AndHow allows only a single class implementing the AndHowInit interface on the classpath and will complain (i.e. throw a RuntimeException) at startup if it finds more. Why? AndHowIinit configures how AndHow configures your application - it cannot be ambiguous which AndHowInit is intended to be the effective one. If an AndHowInit instance is included in a library, it prohibits applications using that library from creating their own AndHowInit.
If you have a dual-use library, such as a calculation utility that can be run from command line or bundled into a larger application, use a packaging tool like Maven to create two packaged version: One with an AndHowInit instance for independant usage, and another without an AndHowInit instance for so the library can be included as a dependency in other applications.
Include an andhow.properties file in your deployable artifact, not in library or dependency
Incluing an andhow.properties file in a library is essentially just like setting default values for each Property. Properties already can have their defalaults declared in their construction, so there is no need to do this. Worse, if the deployed application includes its own properties file, it may become ambiguous which one is suppose to be in use (though web containers like Tomcat and SpringBoot generally get this right).
If you want to include a sample configuration file for applications using a library, it might be clearer to call it andhow.properties.sample or similar.