« Programming Naming Conventions » : différence entre les versions
De Transport
Aller à la navigationAller à la recherche
m a renommé ProgrammingStyle en Programming Naming Conventions |
Aucun résumé des modifications |
||
| 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] | ||
Dernière version du 12 août 2012 à 22: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
