SDL Coding Style Guide

Basic formatting changes can be fixed using the following command in the SDL Core root folder:

. tools/infrastructure/check_style.sh --fix

Generally we use Google Coding Style with the following exceptions/additions:

1. Inline Functions

   • Don't use inline specificator.

2. Names and Order of includes

   • Add all #include explicitly.

   • Recommended to use short paths in #include directives like: #include "base/logging.h". If component has subcomponents - the longer path can be used according the following rule: The longest path to file in #include directive must be started from component name (f.e. #include "utils/threads/thread_manager.h" or #include "application_manager/commands/command.h"). Path to component must be specified in CMakeList.txt as include_directories).

3. Namespaces

   • Using of using-directive to make all names from a namespace available is allowed in method(function) body ONLY

4. Reference Arguments

   • Output parameters must be passed by reference. F.e.

void Foo(const string& in, string& out);

5. Templates

   • In template definitions typename word must be used

6. Naming

   • Only Global const variables must be named with a leading "k" followed by mixed case. F.e. const int kDaysInAWeek = 7;

   • The names of variables and data members are all lowercase, with underscores between words. Data members of classes AND structs additionally have trailing underscores. For instance: a_local_variable, a_struct_data_member_, a_class_data_member_.

   • Enumerators (for both scoped and unscoped enums) should be named either like constants : kEnumName

   • Functions output parameters must have out_prefix in their names;

7. Vertical Whitespaces. They helps visually separate out logical blocks of code. Add one blank line before and after any (first and last line in function/cycle/statement should't be the blank line):

   • Cycles (for, while, etc.);
   • Statements (if);
   • Definition/initialization blocks;
   • Logical block of function calls;