Why Java Code Naming Conventions Suck

ThatIsFrom The JavaLanguageSpecification, ThirdEdition. 6.8 NamingConventions The classLibraries of the JavaPlatform attemptToUse, WheneverPossible, NamesChosen accordingTo the ConventionsPresented here. TheseConventions helpToMake Code moreReadable And Avoid CertainKinds ofNameConflicts. 6.8.4 MethodNames MethodNames ShouldBe verbsOr VerbPhrases, inMixedCase, WithThe FirstLetterLowercase and theFirstLetter ofAny SubsequentWords Capitalized. HereAre SomeAdditional SpecificConventions for MethodNames: Methods to Get and Set anAttribute thatMightBeThought OfAsAVariable V ShouldBeNamed getV and setV. AnExample is TheMethods getPriority and setPriority ofClass Thread. AMethod ThatReturns TheLengthOfSomething ShouldBeNamed length, as in class String. AMethod ThatTests A boolean Condition V AboutAnObject ShouldBeNamed isV. AnExample Is TheMethod isInterrupted ofClass Thread. AMethod ThatConverts ItsObject ToA ParticularFormat F ShouldBeNamed toF. ExamplesAre TheMethod toString ofClass Object and TheMethods toLocaleString and toGMTString ofClass java.util.Date. WheneverPossible andAppropriate, Basing TheNamesOfMethods In ANewClass On Names In AnExistingClass ThatIsSimilar, Especially AClassFrom TheJavaApplicationProgrammingInterfaceClasses, WillMakeItEasierToUse. MethodNames CannotObscure OrBeObscured ByOtherNames

That's from Programming Style, Naming Conventions. General Naming Conventions It's usually best to choose a consistent set of naming convnetions for use throughout your code. Naming conventions usually govern things such as how you capitalize your variables, classes, and functions, whether you include a prefix for pointers, static data, or global data, and how you indicate that something is a private field of a class. There are a lot of common naming conventions for classes, functions and objects. Usually these are broken into several broad categories: c-style naming, camelCase, and CamelCase. C-style naming separates words in a name using underscores: this_is_an_identifer. There are two forms of camelCase: one that begins with a lowercase letter and then capitalizes the first letter of every ensuing word, and one that capitalizes the first letter of every single word. One popular convention is that leading capital letter CamelCase is used for the names of structs and classes, while normal camelCase is used for the names of functions and variables (although sometimes variables are written in c-style to make the visual separation between functions and variables more clear). It can be useful to use prefixes for certain types of data to remind you what they are: for instance, if you have a pointer, prefixing it with "p_" tells you that it's a pointer. If you see an assignment between a variable starting with "p_" and one that doesn't begin with "p_", then you immediately know that something fishy is going on. It can also be useful to use a prefix for global or static variables because each of these has a different behavior than a normal local variable. In the case of global variables, it is especially useful to use a prefix in order to prevent naming collisions with local variables (which can lead to confusion). Finally, a common convention is to prefix the private fields and methods of a class with an underscore: e.g., _private_data. This can make it easier to find out where to look in the body of a class for the declaration of a method, and it also helps keep straight what you should and should not do with a variable. For instance, a common rule is to avoid returning non-const references to fields of a class from functions that are more public than the field. For instance, if _age is a private field, then the public getAge function probably shouldn't return a non-const reference since doing so effectively grants write access to the field!

WhY ThEy DiD NoT WaNtEd Us To WrItE CoDe LiKe ThIs?