Introduction
This is an article on our day-to-day programming practices. The article is targeted from beginners to pro who are involved in programming hands on. Life glides when we begin programming and our projects are small, the factorials, finding out primes and so on. When we master the skill set of branching, looping, expressions etc the next program waiting for us is a project of some size, which matters. Trouble begins when we find that our source is not confined in one screen only and spans across multiple files. Beginning from here on, we, the lazy programmers, start doing mistakes, which are repeated throughout our lifetime and never gets corrected (I am not an exception and hence this article).
Most of us, except a few god-gifted, who are pro in the industry still continues to do the same. Hence let's find out some of the best practices prescribed and found over our experiences of coding. The set to avoid and the set to follow.
1. Naming Convention
Naming variables are one of the major issues in programming. Include the scope in name, include datatype and many more are the frequently asked questions and issues, lets try and find out how to find the best of practices.
General Convention
For some special reason (I wish it be different) spaces are not allowed in a variable name. To avoid make it the way it’s said “start with lowercase and make it mixed case”. Different logical units of a variable should start with uppercase letters. Prefix the same with datatype, e. g., intMarksObtained, chrFirstName. Follow fixed length convention for the datatype prefix except for cases the need be. Hungarian notation varies in length for prefixing the datatype
Naming Objects
I prefer prefixing objects with obj. Other conventions include prefixing with class name in full or short. Choosing amongst them is a matter of personal choice.
Never combine hierarchical information of an object in variable names, it will complicate life rather than making things simple, e. g., AutoCarMyCar or AutoCarFriends describes the variable beyond it’s class information. Don’t try such naming standards, won’t make your life easy. A better approach would be making it objMyCar or carMyCar.
Naming Class Members
In general two practices are commonly followed prefixing or suffixing members with “_” (underscore). Recommendations are that suffix of _ should be used, which increases readability. I prefer, though, prefixing it; which increases my readability.
Follow general guidelines for naming following _, e. g., _intPosition.
Scope Incorporation
There are suggestions that scope be included in a placeholder to identify the scope of a variable/member, e. g. lintPosition, indicating local variable or pintNoOfRecords, indicating a global variable. I don’t find this particular convention useful unless we are maintaining or modifying extremely ugly piece of code.
However for global member g_ or g should act as a prefix e. g., gintCounter or g_intCounter. This convention distinctly differentiates our global variables and their uses in different places of the program.
Iterators
For historical reasons most programmers use i, j …as iterators. I prefer using this convention only. This practice can be changed to big names if we are dealing with huge number of iterators within a single function, otherwise it should be done the i, j… way only. All programmers (as much as I know) understand or assumes i, j … kind of variables to be iterators. Reuse these iterators at will with a noble practice of adding a single line to reinitialize the iterator with the desired values before using.
int i;
i = 0;
while ( <expr> >= i)
{
….
}
i = 0;
while (<expr> >= i)
{
…
}
C++ Warning
Declaration of a variable can be done in any part of a code, hence tendencies go towards declaring and using an iterator. Beware of the fact that if not declared within a block it will draw a compile time error, in case the same name is used for another iteration in later part of the function. Do not bypass this error by putting braces to mark the iteration as a block, as it might not reflect other changes expected to be reflected elsewhere.
Best Practices - Programming->Classes/Functions >>
]
