mirror of
https://github.com/ceph/ceph
synced 2024-12-26 13:33:57 +00:00
4e05cc748b
Back in commit7469f26a33
when the COPYING file was added to the repository and the project was "licensed," the license file was GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 However, the license was abbreviated as LGPL2 in various places (pretty much everywhere, actually), due to my own ignorance/carelessness. (I was distinguishing it from shiny new version 3, released 6 months earlier.) Version 2 of LGPL is the "Library General Public License," published in June 1991: https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html Note that this ambiguity persists for most of the project's lifetime. For example, the original debian/copyright in8adc9dac1d
said "LGPL2" bug in4545f8b929
(2009, a year later) it is changed to LGPL2.1 to satisfy Debian's lintian checks. (It's remained LGPL2.1 ever since.) "Correct" the record by changing LGPL2 references to LGPL2.1. Signed-off-by: Sage Weil <sage@redhat.com>
132 lines
3.1 KiB
Plaintext
132 lines
3.1 KiB
Plaintext
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:
|
|
|
|
https://www.kernel.org/doc/Documentation/CodingStyle
|
|
|
|
|
|
C++ code
|
|
--------
|
|
|
|
For C++ code, things are a bit more complex. As a baseline, we use Google's
|
|
coding guide:
|
|
|
|
https://google.github.io/styleguide/cppguide.html
|
|
|
|
|
|
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 {
|
|
int a, b;
|
|
my_type_d() : a(0), b(0) {}
|
|
};
|
|
|
|
- for full-blown classes, CamelCaps, private: section, accessors,
|
|
probably not copyable, etc.
|
|
|
|
* Naming > Variable Names:
|
|
|
|
Google uses _ suffix for class members. That's ugly. We'll use
|
|
a m_ prefix, like so:
|
|
|
|
class Foo {
|
|
public:
|
|
int get_foo() const { return m_foo; }
|
|
void set_foo(int foo) { m_foo = foo; }
|
|
|
|
private:
|
|
int m_foo;
|
|
};
|
|
|
|
* Naming > Constant Names:
|
|
|
|
Google uses kSomeThing for constants. We prefer SOME_THING.
|
|
|
|
* 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.1) or the code origin isn't reflected by the git history.
|
|
|
|
* 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
|
|
|
|
* Formatting > Conditionals:
|
|
|
|
- No spaces inside conditionals please, e.g.
|
|
|
|
if (foo) { // okay
|
|
|
|
if ( foo ) { // no
|
|
|
|
- Always use newline following if:
|
|
|
|
if (foo)
|
|
bar; // okay, but discouraged...
|
|
|
|
if (foo) {
|
|
bar; // this is better!
|
|
}
|
|
|
|
if (foo) bar; // no, usually harder to parse visually
|
|
|
|
|
|
|
|
|
|
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.
|