Constants

Code should not contain any magic. Magic in this case is defined as hard coded strings and numbers that are not constants. The problem with magic is that it quickly becomes a maintenance nightmare if a variable can be or is set in more than one place or the same value is used by a number of objects. Worse, the magic value has little meaning other than that given to it by the method it is being passed into or the code surrounding it.

For example, imagine an application that displays a number of dialogs that all have to be the same size, lets say 400 by 300 pixels. One could call the set size method of each dialog passing in the hard coded values 400 and 300 like this: "dialog.setSize( 400, 300 )". This works fine until you come across a dialog that needs to be larger. The only option at this point is to search through the code looking for every instance of "setSize( 400, 300 )". If you miss an instance of this call your program is in error and outside the specification which stated all dialogs must be the same size. The solution is to define two constants DIALOG_WIDTH and DIALOG_HEIGHT that take the values 400 and 300 respectively. When calling the setSize method one now uses the constants. Changing the size of the dialogs is simply a matter of updating the constants.

The next statement seems a bit bizarre but it's important to note: constants should be constant. In other words they should be final and probably static, many are also public although that is not always the case. Constants should also be marked as such by using a coding convention. In the Java world (and many other languages) constants are marked out by being in CAPITALS with underscores separating words.

Variable Names

Always use meaningful but terse variable names. Calling loop variables i, n and j, m is fine - these are the defacto standards and everyone understands what they are. No one understands what myObjectThingy is though or worse myObThg. If the object being referenced is a person call it person. If you are in a loop going through people in an array call the current person currPerson or something similar that is meaningful in context. Don't call it thePersonThatIsTheOneThatWeAreCurrentlyProcessing.

Some people like to add clutter to variable names for example adding m or m_ to the start of member variables, this is called Hungarian notation. Hungarian notation has fallen out of favour in recent years with the rise of more powerful IDEs and a change in thinking about how to write good code. In the past Hungarian notation was a useful reminder of what a variable did when you were 400 lines into a 1000 line method. Modern IDEs can highlight variables instantly and so show you which are member variables and which are local. Best practice has also changed so that methods are shorter and often now fit on a couple of screens.