CSC/ECE 517 Fall 2010/ch4 4c t1

Naming Convention in Object-Oriented Languages

Naming convention in object-oriented programming refers to the naming rules that the programmer adopts for software elements, such as classes, methods, and variables. Naming convention may refer to the way in which compound words are capitalized, how descriptive the names are, as well as the length of the names among other attributes. The name selected for any variable, class or method within a program should convey the meaning and use of the object and should generally promote the readability of the code. There are standardized naming conventions that are used in the industry (e.g., camelCase), as well as language-specific naming conventions (e.g., Java, C++).

The advantages of using a consistent naming convention are most apparent when a programmer is working as part of a team. Use of a naming convention allows the different developers within the team to read and understand each others code with more ease since all of the programmers are using a matching set of rules. It also ensures that name collisions are less likely when programmers are working on parts of the program that rely on modules or classes from other developers. It may be rare that a programmer will write, maintain, and ultimately retire a program. With that in mind, having a standardization within a company or team can save labor costs in the long run. 80% of the lifetime cost for a piece of software isn't the development of the program but rather the maintenance of the software.^[2]

When individuals are developing code, they too will experience benefits of using a consistent naming convention. A developer will find it easier to move between projects or pick up old projects they developed if they have been employing a consistent naming convention across all of their work. It is also important for a programmer to remember that code they are developing as part of an individual project may be incorporated as part of a larger team project in the future, so using a standardized naming convention will ensure that code is easier to hand off to other developers in the future.

History of Naming Conventions

Before the introduction of modern development environments and compilers, naming conventions were developed to serve a different purpose than how they are used today. Many standards were developed to indicate the variable type, scope, or purpose or to limit the length of the variable name because of limitations of the development tools.

Positional notation was adopted as a naming convention for very short names where the position of the character in the name indicates the attribute that it specifies. For example, an eight character name such as TB4C5UPD might represent "Table 4, Column 5, Update" where the first three characters represent the object, the second two represent the subobject, and final three characters represent the action. Positional notation achieved its goal of short names, but was difficult to read and grew out of favor as the need to maintain short names disappeared.

Hungarian notation (more specifically “Apps Hungarian”) was developed by Charles Simonyi in the 1970’s while he was working for Xerox PARC. In Apps Hungarian, a prefix is added to the variable name to indicate the purpose of the variable. For example, tbRocks might be used to indicate a table of rock types in a geology program, with “tb” indicating that it is a table. Or frmTestEntry could be used to indicate a user form that would be used to administer a test.

Modern development tools have afforded code developers more flexibility in naming objects in their programs. Inspection tools that are built into the development environment allow attributes such as type and usage to be tracked based on the implementation in the project. Therefore the naming conventions for most modern object-oriented languages are able to focus on clearly describing the function of the software object (e.g., variable, method, class).

The Linux kernel coding style manual states "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.".^[7]

Standardized Naming Conventions for Object-Oriented Languages

Camel Case

Camel case is the use of capitalization to add clarity to compound names assigned in code. It evolved as a common standard because of the need to avoid commonly available delimiters, such as hyphens (-) or underscores (_), that were used as keywords in the syntax of languages.^[6] There are two common variants of camel case that are used.

Lower camel case (or camelCase) involves using a lower-case letter for the first word in the name with each subsequent word using an upper-case letter.

int setName(){
}

Upper camel case (or CamelCase) involves using an upper-case letter for the first word in the name and for all subsequent words. CamelCase is sometimes referred to as PascalCase.

int SetName(){
}

camelCase or CamelCase is often times used as the foundation for language-specific naming conventions.

C-Style

C-Style is most notably used in the family of "C" languages (C, C++, etc). The C-Style naming convention specifies a standard practice in defining constants, functions, and variable names.
For example, constants should be defined in all caps:

#define MAX_HEIGHT

Functions, typedef, variable names, structs, unions and enum tags should all be in lowercase;

typedef hello
int myheight

When using a naming scheme, avoid using similar looking names, such as myWindow and MyWindow or my_window and mywindow. Having similarly named methods or variables might be confusing when another coder is trying to debug the code. Using a leading and trailing underscore are reserved for system purposes^[1][3]

__STDC__ //preprocessor symbol

Java

The Java naming convention allows for an easy flowing, logical naming scheme. It allows a programmer to easily understand the nature of the class, method or variables being called. For class names, nouns are suggested with each first letter in the string capitalized.

class Person(){
}

class MyExample(){
}

Methods, in most cases, should be verbs describing the action of the method. The first letter is lowercase followed by the first letter of the internal word in the string uppercased.

public string getStudentName() {
  return studentName;
}

public void throwBallOverFence() {
  // code to throw a ball over a fence
}

Variables should have a meaningful but short name. The first letter is lowercased followed by the first letter of the internal word in the string uppercased. For example: “int windowSize”, “string firstName”. Temporary variables generally are 1 character long. For integers, i, j, k, m, n are usually used and “c, d, e” are used for charaters.

public int countNumbers(){
  int studentNumber = 0;
  int teacherNumber = 0;
  for(int i = 0; i < 20; i++){
    // i is a local variable and will only
    // execute within this loop
  }
}

For class constants, the entire string is capitalized with words separated by an underscore “_”. For example: “static final int WINDOW_SIZE = 640;”, “static final string WINDOW_NAME = “Charlie”;” It is recommended to NOT use underscores in variable names, although it is allowable by the compiler.^[2]

int MAX_WINDOW_WIDTH = 640;
int MIN_WINDOW_HEIGHT = 50;

Naming Convention Considerations

Classes

When naming a class, the name of the class should reflect the object that the class is describing. If the programmer decides to name a class “class1”, no indication is given of the object that is being represented by the class.

class class1 {
}

If the developer upgrades the class name to “appleclass” the name gives more insight into the purpose, but includes useless information (“class”) that hampers readability.

class appleclass {
}

Consider a change of the name to simply “Apple”. The purpose of the class is very clear and readability is improved significantly from where the programmer started.

class Apple {
}

Methods

Method names should clearly indicate the what action is performed when calling the method. Take for example the method “methodb”, which tells the reader nothing about the purpose of the method.

class Apple {
    int methodb() {
    }
}

If the name is upgraded to “colormethod” it adds some additional info to the readability since it is now clear that it has something to do with the color of the apple, but it still lacks clarity.

class Apple {
    int colormethod() {
    }
}

If the name is refined to “getColor”, the reader can now distinguish that the method will return the color of the Apple object.

class Apple {
    int getColor() {
    }
}

Variables

Consider the case of a programmer creating a counter variable. If the programmer chooses to name the variable “a”, the name gives the reader of the code no idea of the programmers intent for that variable.

class Apple {
    int a=0;
    ...
    void printNumWorms() {
        print a + ‘ worms’;
    }
}

If the programmer chooses to upgrade the name to “thiscounter”, they have given more information (we now know we are dealing with a counter) but we still don’t know how this counter is used unless we analyze more of the code.

class Apple {
    int thiscounter=0;
    ...
    void printNumWorms() {
        print thiscounter + ‘ worms’;
    }
}

Now consider that the programmer upgrades the variable name to “wormCounter”. It gives a clear indication that the counter is counting worms, so we know how it is used. Notice that the capitalization has been updated using camelCase to make it easier to distinguish the different parts of the compound name.

class Apple {
    int wormCounter=0;
    ...
    void printNumWorms() {
        print wormCounter + ‘ worms’;
    }
}

Conclusion

Applying a consistent naming convention to object-oriented development provides an organization or programmer better code readability and maintainability. When chosing a convention, it is important to realize you can use more than one scheme to develop code, as long as it is consistent throughout the program. For example, you could use camelCase with C-Style naming schemes to improve the readability of your program.

References

1. http://www.cprogramming.com/tutorial/style_naming_conventions.html
2. http://java.sun.com/docs/codeconv/CodeConventions.pdf
3. http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html
4. http://en.wikipedia.org/wiki/Naming_convention_(programming)
5. Dale Skrien, "Object-Oriented Design Using Java"
6. http://en.wikipedia.org/wiki/CamelCase
7. http://lxr.linux.no/linux/Documentation/CodingStyle

Other Links

Naming Conventions Wiki from Summer 2008 (1)
Naming Conventions Wiki from Summer 2008 (2)