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