In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types and functions etc. in source code and documentation.

Reasons for using a naming convention

•to reduce the effort needed to read and understand source code
•to enhance source code appearance (for example, by disallowing overly long names or abbreviations)

Here are some of the benefits obtained by adopting a common naming convention:

•to provide additional information (i.e., metadata) about the use to which an identifier is put
•to help formalize expectations and promote consistency within a development team
•to enable the use of automated refactoring or search and replace tools with minimal potential for error
•to enhance clarity in cases of potential ambiguity
•to enhance the aesthetic and professional appearance of work product (for example, by disallowing overly long names, comical or “cute” names, or abbreviations)
•to help avoid “naming collisions” that might occur when the work product of different organizations is combined
•to provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation and to provide better understanding in case of code reuse after a long interval of time

Business value
Although largely hidden from the view of most business users, well-chosen identifiers make it significantly easier for subsequent generations of analysts and developers to understand what the system is doing and how to fix or extend the source code for new business needs.

For example, although the following:
a = b * c;
is syntactically correct, it is entirely opaque as to intent or meaning. Contrast this with:
dblWeeklyPay = dblHoursWorked * dblPayRate;
which implies the intent and meaning of the source code, at least to those familiar with the underlying context of the application.

Comments
Commented code helps future generations of developers easily understand what sections of code are supposed to be doing. Using comment blocks native to the language make note of the major function of the following few lines as well as outline expected input and output (if applicable). Believe it or not commenting your code will help you too.
# qchecker.pl # This program will check the current Q for any old items # checkActiveQ # Function that will look up items in the Active Q sub checkActiveQ{ # Code here … }

Variables
Variables should be prefixed to indicate their data type. Optionally, especially for large programs, the prefix can be extended to indicate the scope of the variable. The body of a variable or procedure name should use mixed case (CamelCase) and should be as long as necessary to describe its purpose. In addition, function names should begin with a verb, such as initNameArray or closeDialog.

For frequently used or long terms, standard abbreviations are recommended to help keep name lengths reasonable. In general, variable names greater than 16 are considered too long.

When using abbreviations, make sure they are consistent throughout the entire application. Randomly switching between cnt and Count within a project will lead to unnecessary confusion.

Variable Data Types

Use the following prefixes to indicate a variable’s data type.

Data type Prefix Example
Boolean bln blnFound
Byte byt bytRasterData
Collection object col colWidgets
Currency cur curRevenue
Date (Time) dtm dtmStart
Double dbl dblTolerance
Error err errOrderNum
Integer int intQuantity
Long lng lngDistance
Object obj objCurrent
Single sng sngAverage
String str strFName
Variant var varCheckSum

Using CamelCase
Indicate word boundaries using medial capitalization (also called “CamelCase” and many other names), thus rendering “two words” as either “twoWords” or “TwoWords”.

Meh!..

1.capitalizationIsUsuallyAtTheBeginning
2.underlines_are_usually_under_the_words_not_the_spaces
3.subject.verb(noun,noun)

Indentation
Indentation rules (most coding standards impose) really contradict
rules of good writing,
the way people perceive information,
and the grammar rules.
Making things (that group naturally, but not syntactically) inside
parenthesis also contradicts how texts are usually typed.
If (you try to type text that way)
you’ll face misunderstanding even (if programmers read you)
otherwise
your text will be easy to read,
and your writing will be productive
!

If you have questions or comments let me know by posting a comment.