About programming style in object-oriented programming¶

Generic guidelines¶

In object-oriented programming, the first thing to consider is the rationality and usefulness of your class. An essential mission of a class is to bring data (attributes) and the code handling the data (methods) together.

If a class has no methods (excluding constructor and destructor), the class is not reasonable, since you could simply use a struct. Also if a class has, besides constructor and destructor, only set and get methods, you could again use a struct, whereupon these methods would become needless. On the other hand, if a class has no attributes, most probably its methods do not belong together (since they have no common data to handle), and thus, they should not be written in a class.

The names of classes shall mainly be in singular form. Almost always there is no reason for using plural, since a class typically describes properties of a single object. However, a class can have (and typically has) several instances.

It is a common practice to use underline as the last character of a member variable of a class, although this is not required by the C++ compiler. This makes it easier to distinguish them from other variables.

More special rules¶

Style issues listed below have been taken from the Finnish book “Olioiden ohjelmointi C++:lla” written by Matti Rintala and Jyke Jokinen (pp. 341-353). Most of the points have been mentioned in other parts of the material with larger explanation. Therefore they are listed here shortly.

• Each header file (.hh) contains a single public interface (class). Header files contain only definitions (no implementations).

• Header files must be prevented from including more than once:

  #ifndef CLASS_A_HH
  #define CLASS_A_HH
  ...
  #endif // CLASS_A_HH
  

• include directives can be used to include only header files. If you include several files, you must list your own files first and after that the library files.

• The implementation of an interface is written in the implementation file (.cpp) in the same order as they are in the corresponding header file (.hh).

• Classes have been defined with a good public interface (as small as possible), and all the operations are conducted via this interface.

  • Especially, an object must not change the values of another object’s attributes, not even if the objects are instances of the same class.

• Write the public part of a class before the private one.

• The public part of a class contains no member variables.

• The private part of a class contains no useless variables.

• No operations of a class are implemented outside the member functions.

• The member variables of a class must be initialized in the initialization list of the constructor in the same order as they are defined in the header file.

• When possible, define a member function as a const function.

• If you want to pass an object as a parameter, use a reference to the object instead the object itself, whenever possible.

• Earlier style issues gave guidelines for code comments. In that context, it was mentioned that comments concerning a member function of a class are written in the header file (.hh) above the function, rather than in the implementation file (.cpp).