C Coding style - mipidisaster/miLibrary GitHub Wiki
The template and the format for C++ files is stored within the _preferences
folder of this repository. The aim of this page of the wiki, is to detail the style used (or intended to be used) within this repository.
The layout follows the same style as per the ROS suggested style, found here.
The below has been mainly copied across from the http://wiki.ros.org/CppStyleGuide, so please refer to that for more details. I've made a few changes to how variables/functions are to be used if are based locally, globally, universal. Google C++ Style Guide
The following shortcuts are used in this section to denote naming schemes:
- CamelCased: The name starts with a capital letter, and has a capital letter for each new word, with no underscores.
- camelCased: Like CamelCase, but with a lower-case first letter
- under_scored: The name uses only lower-case letters, with words separated by underscores. (yes, I realize that under_scored should be underscored, because it's just one word).
- ALL_CAPITALS: All capital letters, with words separated by underscores.
All files are under_scored.
Source files have the extension .cpp.
Header files have the extension .h.
Be descriptive, e.g., instead of laser.cpp, use hokuyo_topurg_laser.cpp.
If the file primarily implements a class, name the file after the class. For example the class ActionServer would live in the file action_server.h.
Class names (and other type names) are CamelCased E.g.:
class ExampleClass;
Exception: if the class name contains a short acronym, the acronym itself should be all capitals, e.g.:
class HokuyoURGLaser;
Name the class after what it is. If you can't think of what it is, perhaps you have not thought through the design well enough.
Compound names of over three words are a clue that your design may be unnecessarily confusing.
In general, function and class method names are camelCased, and arguments are under_scored, e.g.:
int exampleMethod(int example_arg);
Functions and methods usually perform an action, so their name should make clear what they do: checkForErrors() instead of errorCheck(), dumpDataToFile() instead of dataFile(). Classes are often nouns. By making function names verbs and following other naming conventions programs can be read more naturally.
In general, variable names are under_scored.
Be reasonably descriptive and try not to be cryptic. Longer variable names don't take up more space in memory, I promise.
Integral iterator variables can be very short, such as i, j, k. Be consistent in how you use iterators (e.g., i on the outer loop, j on the next inner loop).
STL iterator variables should indicate what they're iterating over, e.g.:
std::list<int> pid_list;
std::list<int>::iterator pid_it;
Alternatively, an STL iterator can indicate the type of element that it can point at, e.g.:
std::list<int> pid_list;
std::list<int>::iterator int_it;
Constants, wherever they are used, are ALL_CAPITALS. ....However, if a constant/#define is specific to a class or C++ file, then the name needs to start with the name of the class or filename. e.g.
#define AD741x_EXAMPLE_DEFINE
class AD741x {}
Variables that are members of a class (sometimes called fields) are under_scored, with a preceding/trailing underscore added (only protected and private). E.g.:
private:
int _example_int_;
public:
int public_int;