1
0
mirror of https://github.com/ceph/ceph synced 2024-12-30 07:23:11 +00:00
ceph/CodingStyle

132 lines
3.1 KiB
Plaintext
Raw Normal View History

2011-07-11 16:57:22 +00:00
Ceph Coding style
-----------------
Coding style is most important for new code and (to a lesser extent)
revised code. It is not worth the churn to simply reformat old code.
C code
------
For C code, we conform by the Linux kernel coding standards:
http://lxr.linux.no/linux/Documentation/CodingStyle
C++ code
--------
For C++ code, things are a bit more complex. As a baseline, we use Google's
coding guide:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
As an addendum to the above, we add the following guidelines, organized
by section.
* Naming > Type Names:
Google uses CamelCaps for all type names. We use two naming schemes:
- for naked structs (simple data containers), lower case with _d
suffix ('d' for data). Not _t, because that means typdef.
struct my_type_d {
2011-07-11 16:57:22 +00:00
int a, b;
my_type_d() : a(0), b(0) {}
2011-07-11 16:57:22 +00:00
};
- for full-blown classes, CamelCaps, private: section, accessors,
probably not copyable, etc.
2011-07-11 16:57:22 +00:00
* Naming > Variable Names:
Google uses _ suffix for class members. That's ugly. We'll use
a m_ prefix, like so:
2011-07-11 16:57:22 +00:00
class Foo {
public:
int get_foo() const { return m_foo; }
void set_foo(int foo) { m_foo = foo; }
private:
int m_foo;
};
2011-07-11 16:57:22 +00:00
* Naming > Constant Names:
2011-07-13 18:25:22 +00:00
Google uses kSomeThing for constants. We prefer SOME_THING.
2011-07-11 16:57:22 +00:00
* Naming > Function Names:
Google uses CamelCaps. We use_function_names_with_underscores().
Accessors are the same, {get,set}_field().
* Naming > Enumerator Names:
Name them like constants, as above (SOME_THING).
* Comments > File Comments:
Don't sweat it, unless the license varies from that of the project
(LGPL2) or the code origin isn't reflected by the git history.
2011-07-11 16:57:22 +00:00
* Formatting > Tabs:
Indent width is two spaces. When runs of 8 spaces can be compressed
to a single tab character, do so. The standard Emacs/Vim settings
header is:
// -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
// vim: ts=8 sw=2 smarttab
2011-07-11 16:57:22 +00:00
* Formatting > Conditionals:
- No spaces inside conditionals please, e.g.
if (foo) { // okay
2011-07-13 18:25:22 +00:00
if ( foo ) { // no
2011-07-11 16:57:22 +00:00
- Always use newline following if:
2011-07-13 18:25:22 +00:00
if (foo)
bar; // okay, but discouraged...
if (foo) {
bar; // this is better!
}
2011-07-13 18:25:22 +00:00
if (foo) bar; // no, usually harder to parse visually
2011-07-11 16:57:22 +00:00
The following guidelines have not been followed in the legacy code,
but are worth mentioning and should be followed strictly for new code:
* Header Files > Function Parameter Ordering:
Inputs, then outputs.
* Classes > Explicit Constructors:
You should normally mark constructors explicit to avoid getting silent
type conversions.
* Classes > Copy Constructors:
- Use defaults for basic struct-style data objects.
- Most other classes should DISALLOW_COPY_AND_ASSIGN.
- In rare cases we can define a proper copy constructor and operator=.
* Other C++ Features > Reference Arguments:
Only use const references. Use pointers for output arguments.
* Other C++ Features > Avoid Default Arguments:
They obscure the interface.