# Conventions Its a tough balance to make method names meaningful, short and familiar. Here are some of the established conventions in the AndHow Project. These conventions represent what has happened up to this point and why. Community direction in the future could easily change this. These Property classes are the main interaction point for most users, so the names used are important. Existing Property names, such as StrProp, IntProp, BigDecProp, and LocalDateTimeProp follow these conventions: * The names all end with Prop rather than Property to keep the names short * For property types that are based on a boxed primative, the type is shortened to three characters, such as BolProp, DblProp, IntProp and LngProp. The idea here is that these types are so common and familiar that anyone will recognize what the type is, even in this short form. * BigDecProp and LocalDateTimeProp show the limits of abbreviation. 'BigDec' is still pretty recognizable in its shortened form, while 'LocalDateTime' can't really be abbreviated without becoming ambiguous. * FlagProp is special purpose - Its a boolean type with special usage and behaviours. As a precident, it would be purpose wins over datatype. If the Property classes are the most visible classes of AndHow, the builder methods used to assemble the instances are the most visible methods. Most of those methods are validation / requirements related. Prior to version 0.4.2, all of those methods began with must or mustBe. Those names were clear, but too long. As a result of a [discussion](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Feeverman%2Fandhow%2Fdiscussions%2F605\&sa=D\&sntz=1\&usg=AFQjCNEAWXA3YzIJWImWGv8AkGXUWBhqog) [resulting](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Feeverman%2Fandhow%2Fissues%2F587\&sa=D\&sntz=1\&usg=AFQjCNHQWrjZTU-knT8IW-wId9URfRvWtg) [in](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Feeverman%2Fandhow%2Fissues%2F608\&sa=D\&sntz=1\&usg=AFQjCNFIr-Oyyiwc6beAu4Q5iFCkdZYk4Q) [several](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Feeverman%2Fandhow%2Fissues%2F609\&sa=D\&sntz=1\&usg=AFQjCNHxee_LBdPsHixijm3LREr1KK1Z-A) [tasks](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Feeverman%2Fandhow%2Fissues%2F611\&sa=D\&sntz=1\&usg=AFQjCNFnOYqOdTZkJtLVbWV6jkPNXHIgzQ), those method names were shorted. The intent was to base the validation methods on existing, well-known validation or assertion methods. For String related validation, this was easy since the String class has several assertion style methods to copy from. Things were less clear cut for numeric or date related validation. Here are notable precidents: * StrProp.StrPropBuilder.oneOf() and startsWithIgnoringCase() is based on [Hamcrest Matchers](http://www.google.com/url?q=http%3A%2F%2Fhamcrest.org%2FJavaHamcrest%2Fjavadoc%2F2.2%2Forg%2Fhamcrest%2FMatchers.html\&sa=D\&sntz=1\&usg=AFQjCNGu4_51fcMI3G04DQRnprHskFQoYg) * Numeric validation methods are all based on Hamcrest Matchers as well * PropertyBuilderBase.notNull(), which is used by all builders, is based on JUnit assertions (isNotNull in JUnit) * LocalDateTimeBuilder validation is based on a [Hamcrest extension for validating dates and times](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FeXparity%2Fhamcrest-date%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Forg%2Fexparity%2Fhamcrest%2Fdate%2FLocalDateTimeMatchers.java\&sa=D\&sntz=1\&usg=AFQjCNFTl5Lvy4xWm_4ncD3bE_xMr9imJw) The general guide in preference order might be: 1. Use true/false assertion method names from the type class if possible, e.g. String.startsWith() 2. Use Java utility comparison / assertion / validation method names were possible (no current examples of this) 3. Use JUnit assertion method names, though these often need to have 'assert' or 'is' prefixes removed 4. Use Hamcrest or a Hamcrest extension for the type as a reference --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.andhowconfig.org/developer-guide/conventions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.