1 2*** Patches not matching these rules will be rejected *** 3 4First off, read Linus' CodingStyle in the kernel Documentation/ directory. 5Most of it applies directly. There are a number of other points worth making, 6however. 7 8The script "check_style.py" in the oprofile-tests CVS module can help 9identify some problems. Note that it generates a lot of false positives, 10as well as false negatives, so be careful in its use. If all else fails, 11use common sense. 12 13General points 14-------------- 15 16Keep lines within 80 columns with a maximum tab size of 8. You may 17exceed 80 columns if the alternative is uglier (see format_output.h). 18 19Keep files (especially headers) focussed on one small aspect. 20Make judicious use of forward declarations. 21 22 Rationale: reduce false include dependencies 23 24Separate out more general routines and place them in the appropriate 25utility library (e.g. libop/, libutil++). 26 27 Rationale: re-use, clean organisation 28 29Avoid complex conditionals via helper functions (e.g. comma_match) 30 31Avoid ifdefs: prefer configure options / build trickery. 32 33Use Doxygen comments judiciously. Actual source code should generally 34only document the unexpected. Comments should not duplicate what the code 35says (this means variable/function naming is uber-important). The Doxygen 36function comments go in the header (except for static functions obviously). 37 38Do not use trailing comments, unless they are used for an enum or struct 39member, e.g. : 40 41 enum foo { 42 bar, /**< foo */ 43 baz, /**< quux */ 44 }; 45 46If you do this, you must use the above doxygenated markup. 47 48Makefile.am: prefer using 49LIST = \ 50 foo1 \ 51 foo2 52rather than 53LIST = foo1 foo2 54 55 Rationale: diffs are a lot easier to read. 56 57Arbitrary rules 58--------------- 59 60Two blank lines between functions. 61 62Use tabs for indentation, spaces for alignment. Avoid wrapping lines, 63but if you do, choose a reasonable point and align the next line 64sensibly. If there is no sensible alignment point, use single extra 65tab to indicate "continuation". Avoid using tabs for alignment: it 66breaks on different sized tabs. Lines should be less than 80 67on screen characters wide (assuming a maximum tab-size of 8). 68 69rationale: http://www.movementarian.org/docs/whytabs/ 70 71C++ inline methods in headers. use Java braces : 72 73 void method() { 74 } 75 76Avoid using inline methods at all. 77 78Space types like this : 79 80 void blah(int * x, int * y); 81 void blah(int & x); 82 int & ref = get_ref(); 83 int * x = &y; 84 int z = *x; 85 int arr[4]; 86 87Rationale: makes application of operators visually different from 88type specifications. 89 90Use "char const *" not "const char *". 91 92Make use of the C++ standard library. That's what it's there for. Bear 93in mind we support gcc 2.91.66 94 95Avoid CamelCase in preference to cpp_std_library. 96 97Use "using namespace std;" in .cpp files. Use std:: qualification in .h files. 98 99Avoid do { } while(). Avoid defines. 100 101Single-line for/while/if blocks should generally not use containing 102braces. Never use the comma operator to avoid braces. If there is more 103than one visual line (regardless of number of statements), you need 104braces. If there is an else clause, you should probably use braces; if 105any of the branches in an if/else if change has braces, they all should. 106 107Spacing : 108 109 if (blah) { 110 call_method(¶m); 111 x = y + z; 112 x = func(a, b, c + SOME_DEFINE); 113 114Use noncopyable, scoped_ptr, and scoped_array. 115 116Use the standard comments + include guards for headers. 117 118Do not inline unless you have good reason. 119 120Use anon namespaces for static variables. 121 122In a derived class re-implementing a virtual function, include the 123(unnecessary) "virtual" keyword in the function declaration. 124 125"nr_doobries" not "no_doobries" - disambiguates between "number" and "negative" 126 127Wrap long function definitions like this if possible : 128 129struct some_frobnication const & 130my_frobnicator(vector<string> const & values, bool bogo); 131 132or, if not : 133 134static void my_frobnicator(vector<string> const & values, 135 vector<string> const & things); 136 137Note the spaces for alignment here. Avoid such long prototypes at all where sensible. 138