Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Datovka Datovka
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 88
    • Issues 88
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 7
    • Merge requests 7
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Datovka projects
  • DatovkaDatovka
  • Wiki
  • code style

code style · Changes

Page history
Update code style authored Jun 26, 2018 by Karel Slaný's avatar Karel Slaný
Hide whitespace changes
Inline Side-by-side
code-style.md
View page @ 32934b97
......@@ -45,7 +45,8 @@ Many of the rules of the [FreeBS kernel style](https://www.freebsd.org/cgi/man.c
* Should a template if a template situation occur (e.g. to avoid errors when working with `foreach`).
* preprocessor statements
* We use `#ifndef _HEADER_FILE_H_` as header guards (for file header_file.h). Leading and trailing underscore is mandatory.
* We used `#ifndef _HEADER_FILE_H_` as header guards (for file header_file.h). Leading and trailing underscore were mandatory.
* Nowadays we use a `#pragma once` header guards.
* The `#endif` statement is followed by comment specifying corresponding `#ifdef` or `#if` statement (i.e. `#endif \* _HEADER_FILE_H_ *\`)
* We use `#else` statements followed by a comment with the negation of the condition that leads to the else statement.
* We prefer C-style commentaries.
......@@ -74,13 +75,17 @@ Many of the rules of the [FreeBS kernel style](https://www.freebsd.org/cgi/man.c
* function and variable declaration and definition
* **Never** declare or define functions with empty brackets. Always use `void`.
* When defining/declaring a reference or pointer, **always** attach the `*` or `&` to the variable:
* `void func(struct A *a)` (**not** `void func(struct A* a)` nor `void func(struct A * a)`)
* `const MyClass &ref` (**not** `const MyClass& ref` nor `const MyClass & ref`)
* `int *func(void)` (**not** `int* func(void)` nor `int * func(void)`)
* `void func(struct A *a)` (**not** `void func(struct A* a)` **nor** `void func(struct A * a)`)
* `const MyClass &ref` (**not** `const MyClass& ref` **nor** `const MyClass & ref`)
* `int *func(void)` (**not** `int* func(void)` **nor** `int * func(void)`)
* When defining default parameter, then always put a single space around the `=`.
* `void func(int i = 0)` (**not** `void func(int i=0)`)
* There must not be a space between a function name and the opening bracket.
* type casting
* When casting types to different types always attach the closing parenthesis directly to the cast value/variable:
* `(unsigned long)a` (**not** `(unsigned long) a`)
## Doxygen
* The style is a mix of the Qt and Java style.
......
Clone repository
  • accessibility code
  • accounts db
  • behaviour recommendations
  • best practice
  • cli send msg dlg
  • cli
  • code style
  • compilation
  • data structures
  • help
  • Home
  • localisation
  • manual test scenarios
  • manual
  • mep login
View All Pages