Naming Conventions

One of the primary reasons that programmers do not create everything in assembly code is readability. High-level languages are more verbose but also far more readable and therefore far more accessible. o­ne of the most common tasks we must perform as a coder is naming.

Professional code not o­nly works, it is compatible and easy to maintain. Proper naming is a critical component of making code both maintainable and compatible. For this reason, strict naming conventions are a core aspect of all coding standards and style guidelines.

The first rule of naming conventions is so pure that is universal among all high-level programming languages. Programmers must select meaningful identifiers for all constructs. For instance, if a programmer names a function A1 (), then the next programmer will have to perform some trace work to determine the function’s function.

Rather than A1 () the programmer could have chosen Calculate (). The second name gives the reader a much better idea of what is transpiring but it still requires some work to determine what exactly the function is calculating.

On the other hand, if the coder had named the function GetBattingAverage (), then the read would know exactly what purpose the function served. GetBattingAverage () and GetEarnedRunAverage () are far easier to distinguish than A1 () and A2 ().

Another universal naming convention is that the importance of a name’s meaning grows with the scope of a construct. For instance, it is critical that global variables have strongly defined names because other programmers will access them. Within the context of an application, TIME_TO_LIVE is obvious while B1 is not.

Within a construct, therefore local scope, strongly defined names are less important. This does not mean that a programmer wants to abandon strong names in local scopes but that local context often provides the meaning. An example of this is the variable i, which is used universally as an index or counter.