Programming Naming Conventions : Différence entre versions
De Transport
| (Une révision intermédiaire par le même utilisateur non affichée) | |||
| Ligne 4 : | Ligne 4 : | ||
* all upper cases for constants | * all upper cases for constants | ||
* explicit names, even if they have to be long, for variables | * explicit names, even if they have to be long, for variables | ||
| − | * 4 spaces for indentation | + | * Python |
| − | * shared pointers in C++ | + | ** 4 spaces for indentation (no tab!) |
| − | * const and references for function arguments wherever possible in C++ | + | ** import the modules and use their content with the module prefix (instead of importing everything from the module, because of risks of name collisions; only exception is for limited scope in functions) |
| + | * C++ | ||
| + | ** shared pointers in C++ | ||
| + | ** const and references for function arguments wherever possible in C++ | ||
Other resources | Other resources | ||
* [http://en.wikipedia.org/wiki/Naming_convention_(programming) Wikipedia] | * [http://en.wikipedia.org/wiki/Naming_convention_(programming) Wikipedia] | ||
Version actuelle en date du 12 août 2012 à 18:24
I tend to favour the following rules, as can be seen in the Traffic Intelligence project
- UpperCamelCase for classes
- lowerCamelCase for methods
- all upper cases for constants
- explicit names, even if they have to be long, for variables
- Python
- 4 spaces for indentation (no tab!)
- import the modules and use their content with the module prefix (instead of importing everything from the module, because of risks of name collisions; only exception is for limited scope in functions)
- C++
- shared pointers in C++
- const and references for function arguments wherever possible in C++
Other resources
