BankAndCustomer
|
In order to facilitate joint development in C++, it makes sense if programming guidelines are followed. Here are the most important guidelines for this C++ project.
Uniform rules apply to the individual types of identifiers.
In principle, the English language should be used for all identifiers.
As a rule, each class should be declared in a header file and defined in a source code file (exceptions are template classes, inline methods and structs). Both files get the class name as name.
If several classes are declared in a header file and defined in a source code file, a meaningful module name should be chosen for the files.
C++ header files and global type files get the extension .h.
C++ source code files get the extension .cpp.
Class names are always introduced with a capital letter at the beginning.
To signal an assignment to a project or library, a maximum of 3 letters can be used as abbreviations. The first of these must be an uppercase letter and the other two lowercase letters. The following class name starts again with an uppercase letter. The name should be chosen so that the class's job is clear. If it is a name consisting of several words, they should be written individually according to the CamelCase notation with leading capital letters ( e.g. 'GloBaseMaker').
Template classes get a 'T' inserted before their name, after the project or library abbreviation (e.g. 'GloTOndemandSet').
Alternatively, an assignment to a project or to a library can be realized via a namespace. For the designation of the namespace only 3 lowercase letters should be used as an abbreviation (e.g. glo::BaseMaker). However, the repetition of an abbreviation befor the class name should then be avoided.
The attributes of classes are always introduced with a 'm_' (stands for member). This is then followed by a controversial and not entirely consistent marking according to the Hungarian notation followed by a meaningful name that begins with a capital letter (for example, 'm_sApplicationName' for a string).
The methods of classes are always introduced with a lowercase letter. Usually a verb should be used which describes the service of the method (e.g. 'loadIconPath'. If the status of a class is to be queried, it has proven to be useful to start the method name with an 'is' or 'has' (e.g. 'isStored' or 'hasConnection'
Global variables are always introduced with a 'g_' (stands for global). This is then followed by a controversial and not entirely consistent marking according to the Hungarian notation followed by a meaningful name that begins with a capital letter (e.g. 'g_sGloVersion' for a string).
Local variables are always introduced with a 't_' (stands for temporary). This is then followed by a controversial and not entirely consistent marking according to the Hungarian notation followed by a meaningful name starting with a capital letter (e.g. 't_iErr' for a local Int variable).
Parameters are usually introduced with a controversial and not entirely consistent marking according to the Hungarian notation, followed by a meaningful name starting with a capital letter (e.g. 'eLockMode' for an enum value).
To simplify the search for content, some file types are predefined or suggested.
As already mentioned under File names. Usually, each class should be declared in a header file and defined in a source code file (exceptions are template classes, inline methods and structs). Both files get the class name as name.
If several classes are declared in a header file and defined in a source code file, a meaningful module name should be chosen.
The global constants, enumerations and structures are stored in a header file. The name of this file should be the project or library abbreviation with a following 'Types' ( e.g. 'GloTypes').
If constants, enumerations and structures only affect one class, you must always consider whether they belong in the respective classes.
Global error codes for a project are stored in a header file. The name of this file should be the project or library abbreviation with a following 'Errors' ( e.g. 'GloErrors').
A ToList 'ToDo.txt' is placed in the respective C ++ project directory. In this to-do list, individual requirements and things still to be done are listed with priority according to the manner of a Scrum backlog.
In order to simplify the recognition of content, some formatting is predefined or suggested.
Every text file with special characters must be saved in UTF8 format so that the special characters are handled uniformly.
Each logical section in the source code should be indented. Indentations are in 2 character increments. This indentation should not be defined as tab characters.
The characters '{' and '}' always stand alone in a line. Pairs of brackets are always in one column. It is recommended to also bracket single-line statements in '{' and '}'. Example:
To support clarity, logical units are divided by comments and interruptions with lines. Example:
The line length should not exceed 80 characters. There are cases where this cannot be adhered to.
Recommendations for line breaks if the line length is exceeded.
In the case of an extensive if statement or while and do-while loops:
Individual logically related declarations and assignments should be in the same column.
Comments and documentation are necessary to keep the source code understandable.
Comments in the source code should be written in English or translated if possible. Block or line comments can be used as required.
The documentation should be available in several languages and meet the requirements of doxygen.
The documentation of the C++ projects is realized with doxygen. Here doxygen is not described as such, but how and where it is used.
If there should be a language-specific documentation, the respective documentation text is enclosed between '\if german' (for german) and '\endif'. For the English language this would be, for example, '\if english' and '\endif'. This should make it possible for every programmer to use the respective OpenSource products or to work on the project, regardless of which language(s) he or she speaks.
Each header file gets a hint about the license after the include blocker. A short description can be multilingual; the license text is always in English.
Example for class 'GloLocalThread'.
The file and class name, the author name and copyright entry as well as the project or module name are adjusted.
The class is described after any necessary forward declarations and includes directly above the class declaration.
Example for template class 'GloTOndemandSet':
The description text for attributes is described directly in front of it as shown in the example.
Example of an attribute 'GloObjID m_RefObjID':
The description text for enumerations is described as shown in the example.
Example 1 for an Enum 'EnWatchStyle':
Example 2 for an Enum 'EnOpenClose':
The description text for functions and methods is described as shown in the example.