Variable and Function Naming Convention

1. Fundamental naming convention rules:

• First and foremost, be consistent.
• Always use self-describing names., i.e., slashIndex instead of j or nodeCount instead of cnt.
• If you are going to use non-standard abbreviations in the your naming conventions, explain your abbreviations in the main program comment block.
• Class names should be nouns unless you have a good reason for it not to be a noun.
• Method or function names should be verbs or verb phrases to show the action the method / function is providing or performing.
For example:
• Function convertMilesToKilometers(ByVal dMiles as Double) as Double
• double convertToKilometers(double dMiles);
• Function convertMilesToKilometers(ByVal dMiles as Double) as Double
• double convertMlesToKilometers(double dMiles);
• Methods or functions returning a boolean type should generally start with verbs like, is, has, can or have, etc.
For example:
• bool isValidString(string strInput);
• boolean hasAllAttributes();
• bool canUpdate();
• boolean haveAllDate();
• Distinguish multiple words in a name either by separating the words with an underscore, i.e., number_of_words, or using Camel Case notation, i.e., numberOfWords. This applies to class as well as method, function and variable names.
• Constant variable names should me in all capital letters and separate words in the name with the underscore, i.e., DEFAULT_PRICE_PER_POUND.
• In the Java Naming Convention, class names always start with a capital letter and method names always start with a lower case letter. Again, I see nothing wrong with applying this to other languages as long as you are consistent.

2. Hungarian Naming Convention

• Over the years I have become a fan of the Hungarian Naming Convention. The combination of this convention, explained shortly plus self-describing variable names conveys more than just intended use for any variable, but also includes type and scope. This naming convention is independent of programming language. If used consistently throughout the program it will add tremendously to the readability and understandability of the code and even reduce the amount of commenting required because the names read as comments.  NOTE: just because I am explaining the Hungarian Naming Convention does not mean I am insisting on you using this naming convention. I will accept any naming convention as long as it following the fundamental rules listed above.
• The implementation of the Hungarian Naming Convention I have settled into has three parts to a variable name: scope, type and usage. I use the format: scope_typeUsage. Where:
• scope - scope of declaration of this variable

  • global - g
  • class - m
  • local - no prefix

• type - abbreviation of the type. Some common abbreviations are:
• bool or boolean - b
• integer - n or i
• unsigned integer - u
• long - l
• unsigned long - ul
• float - f
• double - d
• string or String - str
• char* - lpsz or lp
• char[] - sz
• DWORD - dw (DWORD is a typedef for an unsigned long)
• any pointer - p

• usage - a self-describing name using lower / upper case letters to combine words or even underscores (_) to combine words. For example, nTotalCount or nTotal_Count
• For GUI components this can extended. Some common ones I use are:

• Label - lbl
• Checkbox - cb or chk
• Editbox - ed
• JTextBox or JTextArea- txt
• RichTextEdit - rtf
• Image - img
• Listbox - lb
• CAnyString - as or any (This is a home grown class of mine)

• Name all controls and variables that have a natural association in a consistent manner. For example, if a Label, Checkbox, Image and an integer place holder are suppose work together at local scope than I would name them as follows to show the association and make your code easier to follow for both you and me.

  • JLable for user input: lblUserInput
  • JComboBox listing possible input options: cbUserInput
  • JImage associated with the input dialog: imgUserInput
  • int for the actual converted input: nUserInput