Guideline NM2: Add clarity with consistent naming conventions
|local one-word variables, functions, methods|
|local multi-word variables, functions, methods|
|global one-word classes, variables, functions, methods|
|global multi-word classes, variables, functions, methods|
|private variables, functions, methods (non-Java)|
|private variables, functions, methods (Java)|
Naming conventions is a topic dealt, by many people, with zealous fervor. Perhaps overzealous. But I shall sally forth and muck about with it nonetheless.
The most controversial, perhaps is the multi-word variable name; I've shown
CapitalizeEachWord in the table.
This style has been promoted by Java, one of the first languages to strongly advocate conventions for everybody.
Standards in any industry, make it easier to go from one brand to another, or in our case, from one person's code to another.
Imagine if each computer had its own custom CDROM format--the world would be a lot uglier, wouldn't it?
Or what if--this is really far-fetched, I know--every operating system had a different format for executable programs?
Then it would be impossible to run a Windows program on Linux or Macintosh or... Whoops. That is what we've got today, isn't it?
In large part, yes, but not with Java. Java executable files will run on any computer with a Java virtual machine.
But back to variable names.
Some people will strongly advocate
a_name_like_this, insisting that run together words, even with capitals in between, are difficult to read.
My preference is for the intermediate capitals because it is promoted by Java,
and because it meshes nicely with the pseudo-package identifier technique shown in the table.