Chess code style

File

---

All the functionality must be put into one or more .cpp and .hpp files into the appropriate module of chess, or a new module should be created if the contributed functionality is a rather large piece of code, or if it does not fit any existing module.

• All the file names are written in lower case for better compatibility with both POSIX and Windows.
• C++ interface headers have .hpp extension
• Implementation files have .cpp extension
• The implementation is put to chess/<module_name>/src, interface is added to the header files in chess/<module_name>/include/. There is no need to add the files to the module explicitly, just rerun CMake and it will add the files automatically.

File Structure

---

Every source file, except for the samples, starts with BSD-compatible license, which template can be found here. The extra/different copyright clauses are possible, as long as the license stays BSD-compatible.
Other rules for both header and implementation files include:

• All the functionality must be put into chess namespace, or, possibly, some nested namespace, e.g. chess::eye
• Code lines should not be very long. Normally, they should be limited to 100 characters.
• No tabulation should be used. Set your editor to use spaces instead.
• Only English text is allowed. Do not put comments or string literals in other languages.
• Indentation is 4 spaces.
• Header files must use guarding macros, protecting the files from repeated inclusion:

    #ifndef _CS_your_header_name_HPP_
    #define _CS_your_header_name_HPP_ 
    #ifdef __cplusplus
    namespace CS { namespace mynamespace {
    ...
    }}
    #endif
    #endif

• Source files must include precomp.hpp header before other headers, in order to make precompiled headers mechanism in Visual C++ work properly.

Designing functions and class interfaces

---

Functionality

The functionality must be well defined and non-redundant. The function should be easy embedded into different processing pipelines that use other chess functions.

Name

The name should basically reflect the function purpose. There are a few common naming patterns in chess:

• Majority of function names have form:

Return value

It should be chosen to simplify function usage. Generally, a function that creates/computes a value should return it. It is the good practice to do so for the functions returning scalar values. However, in case of image processing function it would lead to often allocation/deallocation of large memory blocks, so the image processing functions don't create and return result images rather than modify an output image, passed as a parameter (by reference).

Types of arguments

A consistent argument order is important because it becomes easier to remember the order and it helps programmer to avoid errors, connecting with wrong argument order. The usual order is: *** input parameters, output parameters, flags & optional parameters***.
Input parameters usually have const qualifiers. Large objects are normally passed by a constant reference; primitive types and small structures (int, double, Point, Rect) are passed by value.
Optional arguments often simplify function usage. Because C++ allows optional arguments in the end of parameters list only, it also may affect decisions on argument order—the most important flags go first and less important—after.

Code Layout

There is a single strict coding guideline in Chess: each single file must use a consistent formatting style.
Currently used in Chess and recommended formatting style looks as follows:

if (a > 5) {
    int b = a * a;
    c = c > b ? c : b + 1;
}
else if ( abs(a) < 5 ) {
    c--;
} else {
    printf( "a=%d is far to negative\n", a );
}

Other styles might be also accepted if only the above rule is met. That is, if one changes written by others code, he (she) should use the same coding style.