Skip to content

GitLab

coding_style_c_cpp · Changes

Page history
Update coding_style_c_cpp authored by Yogesh Hegde's avatar Yogesh Hegde
Show whitespace changes
Inline Side-by-side
Showing with 41 additions and 41 deletions
coding_style_c_cpp.md
View page @ 8d89006e
......@@ -28,63 +28,63 @@ are coding, since coding styles are a habit that needs to be cultivated.
| **Rule No.** | **Description** | **Examples** |
|--------------|---------------|-------------------|
| 1.1 | Always comment all the lines of code that you write including `.c`, `.h`, `makefiles` and `CmakeList` files. | [Example](#1.1) |
| 1.2 | Always use Doxygen Comment Layout for all project Documentation. | [Example](#1.2) |
| 1.2.1 | All files should contain comments describing filename, file description, author, and known bugs in Doxygen format. | [Example](#1.2.1) |
| 1.2.2 | All functions should contain comments describing its action, its arguments and its return type in .c/cpp and .h files in Doxygen format | [Example](#1.2.2) |
| 1.2.3 | Split include files into standard include files and project include files. | [Example](#1.2.3) |
| 1.1 | Always comment all the lines of code that you write including `.c`, `.h`, `makefiles` and `CmakeList` files. | [Example](#anchor-11) |
| 1.2 | Always use Doxygen Comment Layout for all project Documentation. | [Example](#anchor-12) |
| 1.2.1 | All files should contain comments describing filename, file description, author, and known bugs in Doxygen format. | [Example](#anchor-121) |
| 1.2.2 | All functions should contain comments describing its action, its arguments and its return type in .c/cpp and .h files in Doxygen format | [Example](#anchor-122) |
| 1.2.3 | Split include files into standard include files and project include files. | [Example](#anchor-123) |
### Naming Convention
| **Rule No.** | **Description** | **Examples** |
|--------------|--------------------------------|------------------|
| 2.01 | Function Names should make clear what action it does. | [Example](#2.01) |
| 2.02 | For all the functions that are exposed to the user use camelCase | [Example](#2.02) |
| 2.03 | For all internal functions use lowercase with `_` as a word separator. | [Example](#2.03) |
| 2.04 | Variable names should use all lower case letters and use `_` as the word separator | [Example](#2.04) |
| 2.05 | Variables names should include the units in their name if it stores some quantity | [Example](#2.05) |
| 2.06 | Pointer Variables should have `*` before their name and not their dataType | [Example](#2.06) |
| 2.07 | Global Constant variables should be all caps with `_` separators | [Example](#2.07) |
| 2.08 | Structure Names should be nouns and in camelCase | [Example](#2.08) |
| 2.09 | #define and Macro Names should be in upper case using `_` separators | [Example](#2.09) |
| 2.10 | Enum Names should be in CamelCase | [Example](#2.10) |
| 2.11 | Enum labels should be in Upper Case with `_` Word Separators | [Example](#2.11) |
| 2.01 | Function Names should make clear what action it does. | [Example](#anchor-201) |
| 2.02 | For all the functions that are exposed to the user use camelCase | [Example](#anchor-202) |
| 2.03 | For all internal functions use lowercase with `_` as a word separator. | [Example](#anchor-203) |
| 2.04 | Variable names should use all lower case letters and use `_` as the word separator | [Example](#anchor-204) |
| 2.05 | Variables names should include the units in their name if it stores some quantity | [Example](#anchor-205) |
| 2.06 | Pointer Variables should have `*` before their name and not their dataType | [Example](#anchor-206) |
| 2.07 | Global Constant variables should be all caps with `_` separators | [Example](#anchor-207) |
| 2.08 | Structure Names should be nouns and in camelCase | [Example](#anchor-208) |
| 2.09 | #anchor-define and Macro Names should be in upper case using `_` separators | [Example](#anchor-209) |
| 2.10 | Enum Names should be in CamelCase | [Example](#anchor-210) |
| 2.11 | Enum labels should be in Upper Case with `_` Word Separators | [Example](#anchor-211) |
### Formatting
| **Rule No.** | **Description** | **Examples** |
|--------------|------------------------------------------------------------------------------------|------------------|
| 3.01 | Only One statement per line. | [Example](#3.01) |
| 3.02 | Only One variable per line. | [Example](#3.02) |
| 3.03 | Always place function braces on new line. | [Example](#3.03) |
| 3.04 | Always place if, while, do, for etc.. start braces on the same line. | [Example](#3.04) |
| 3.05 | Always place closing braces on the new line. | [Example](#3.05) |
| 3.06 | Always Add comments to the closing braces and tell what are they closing. | [Example](#3.06) |
| 3.07 | Add space between Keywords and () when next to each other. | [Example](#3.07) |
| 3.08 | Never add space between function names and () when next to each other. | [Example](#3.08) |
| 3.09 | A Line Should Not Exceed 78 Characters. | [Example](#3.09) |
| 3.10 | Always put the constant on the left hand side of an equality/inequality comparison | [Example](#3.10) |
| 3.11 | Never use goto statements. | [Example](#3.11) |
| 3.12 | Use continue statement if it is absolutely necessary. | [Example](#3.12) |
| 3.13 | Use break statement if it is absolutely necessary. | [Example](#3.13) |
| 3.14 | Never mix continue with break in the same loop, | [Example](#3.14) |
| 3.15 | Never use ?: statement instead use if else. | [Example](#3.15) | |
| 3.01 | Only One statement per line. | [Example](#anchor-301) |
| 3.02 | Only One variable per line. | [Example](#anchor-302) |
| 3.03 | Always place function braces on new line. | [Example](#anchor-303) |
| 3.04 | Always place if, while, do, for etc.. start braces on the same line. | [Example](#anchor-304) |
| 3.05 | Always place closing braces on the new line. | [Example](#anchor-305) |
| 3.06 | Always Add comments to the closing braces and tell what are they closing. | [Example](#anchor-306) |
| 3.07 | Add space between Keywords and () when next to each other. | [Example](#anchor-307) |
| 3.08 | Never add space between function names and () when next to each other. | [Example](#anchor-308) |
| 3.09 | A Line Should Not Exceed 78 Characters. | [Example](#anchor-309) |
| 3.10 | Always put the constant on the left hand side of an equality/inequality comparison | [Example](#anchor-310) |
| 3.11 | Never use goto statements. | [Example](#anchor-311) |
| 3.12 | Use continue statement if it is absolutely necessary. | [Example](#anchor-312) |
| 3.13 | Use break statement if it is absolutely necessary. | [Example](#anchor-313) |
| 3.14 | Never mix continue with break in the same loop, | [Example](#anchor-314) |
| 3.15 | Never use ?: statement instead use if else. | [Example](#anchor-315) | |
### General
| **Rule No.** | **Description** | **Examples** |
|--------------|------------------------------------------------------------------------------------------------------------------------------------------|------------------|
| 4.01 | Divide each action inside your codes into functions. | [Example](#4.01) |
| 4.02 | Never repeat code blocks, if any action in code gets repeated it should be converted into a function and be used. | [Example](#4.02) |
| 4.03 | Use the .h extension for header files and .c/cpp or for source files. | [Example](#4.03) |
| 4.04 | Never define data or variables in header files, instead define them in a .c/cpp file and use extern. | [Example](#4.04) |
| 4.05 | Never use a bare naked number in source code instead use #define or enum to label them. | [Example](#4.05) |
| 4.06 | Check every system call for an error return, unless you know you wish to ignore errors, In which case you can cast the return to (void). | [Example](#4.06) |
| 4.07 | Check every call to malloc or realloc for errors. | [Example](#4.07) |
| 4.08 | Use const keyword to allow passing as variables that cannot change to indicate when a function doesn't modify the variable. | [Example](#4.08) |
| 4.09 | Always use #if 0 to comment out code blocks. | [Example](#4.09) |
| 4.10 | Use Descriptive Macro Names Instead of #if 0 for example #if NOT_YET_IMPLEMENTED | [Example](#4.10) |
| 4.01 | Divide each action inside your codes into functions. | [Example](#anchor-401) |
| 4.02 | Never repeat code blocks, if any action in code gets repeated it should be converted into a function and be used. | [Example](#anchor-402) |
| 4.03 | Use the .h extension for header files and .c/cpp or for source files. | [Example](#anchor-403) |
| 4.04 | Never define data or variables in header files, instead define them in a .c/cpp file and use extern. | [Example](#anchor-404) |
| 4.05 | Never use a bare naked number in source code instead use #anchor-define or enum to label them. | [Example](#anchor-405) |
| 4.06 | Check every system call for an error return, unless you know you wish to ignore errors, In which case you can cast the return to (void). | [Example](#anchor-406) |
| 4.07 | Check every call to malloc or realloc for errors. | [Example](#anchor-407) |
| 4.08 | Use const keyword to allow passing as variables that cannot change to indicate when a function doesn't modify the variable. | [Example](#anchor-408) |
| 4.09 | Always use #anchor-if 0 to comment out code blocks. | [Example](#anchor-409) |
| 4.10 | Use Descriptive Macro Names Instead of #if 0 for example #if NOT_YET_IMPLEMENTED | [Example](#anchor-410) |
### Classes
......