coding-style.txt 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216
  1. Dpkg C coding style 2009-09-29
  2. ===================
  3. C language extensions
  4. ~~~~~~~~~~~~~~~~~~~~~
  5. The code base assumes C89 plus the following C99 extensions:
  6. * Named initializers.
  7. * Trailing comma in enum.
  8. * Variadic macros.
  9. * Working bool type in <stdbool.h>.
  10. Those are checked at build time, and it will abort in case a needed extension
  11. is not supported.
  12. General
  13. ~~~~~~~
  14. Most of the Linux CodingStyle applies.
  15. The code has a mix of an old coding style being phased out and the new
  16. style. New files should use the new style, changes to files with the old
  17. style should switch the code being touched except for the indentation level,
  18. which should be preserved to match (2 spaces).
  19. Code should generally strive for clarity. Monster functions should be split
  20. into logical and small pieces.
  21. Variable and function names should be generally descriptive, not needed
  22. for variables commonly used (for example and index inside a loop, etc),
  23. acronyms should only be used if they are widely known externally or
  24. inside the project. The names should separate logical concepts within
  25. with underscores.
  26. On comments use UTF-8 characters for quotes, copyrigth symbols, etc.
  27. On strings in code use simple or double quotes «''» «""». Not the unpaired
  28. ones «`'». Strings marked for translation, should only be fixed if there's
  29. other changes to be done on them, oterwise we get unneeded fuzzies.
  30. <http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html>
  31. Code documentation
  32. ~~~~~~~~~~~~~~~~~~
  33. Public declarations should be documented using JavaDoc style comments.
  34. Indentation, alignment and spacing
  35. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  36. Lines should be 80 chars max. Indentation is done with hard tabs (which
  37. should be considered to take 8 spaces width). Aligning with spaces:
  38. static void
  39. function(void *ptr, int value)
  40. {
  41. void *ref_ptr = get_ref(ptr);
  42. int ref_value = get_value(ref);
  43. if (value > 10)
  44. do_something(GLOBAL_MACRO, ptr, value, "some-string",
  45. ref_ptr, ref_value, "other-string",
  46. "extra-string");
  47. }
  48. When wrapping, logical operators should be kept on the preceding line:
  49. if (really_long_variable_to_be_checked_against_a &&
  50. really_long_variable_to_be_checked_against_b)
  51. foo();
  52. Spaces between operators:
  53. if (a && (b || c) && c == d)
  54. break;
  55. a = (b + 4 * (5 - 6)) & 0xff;
  56. Spaces between asignments:
  57. a += b;
  58. Spaces after comma:
  59. foo(a, b);
  60. Space after keywords (for, while, do, if, etc, but sizeof should be
  61. treated like a function):
  62. for (i = 0; i < 10; i++)
  63. foo(i);
  64. memcpy(dst, src, sizeof(src));
  65. Definition of local variables, related code blocks, functions bodies
  66. should be split with blank lines:
  67. int
  68. function(void)
  69. {
  70. int a;
  71. foo();
  72. bar();
  73. quux();
  74. return 0;
  75. }
  76. Braces
  77. ~~~~~~
  78. Braces should be placed on the same line as the keyword, but on a new line
  79. for the function body. No braces should be used for unambiguous one line
  80. statements:
  81. if (a > 0) {
  82. foo(a);
  83. bar(a);
  84. } else {
  85. quux(0)
  86. bar(0);
  87. }
  88. for (;;) {
  89. foo();
  90. bar();
  91. }
  92. do {
  93. foo();
  94. bar();
  95. } while (quux());
  96. switch (foo) {
  97. case a:
  98. bar();
  99. break;
  100. case b:
  101. default:
  102. baz();
  103. break;
  104. }
  105. Code conventions
  106. ~~~~~~~~~~~~~~~~
  107. Prefer assigning outside of conditionals:
  108. n = read_items();
  109. if (n < 100)
  110. foo();
  111. String comparisons should use comparison operators to make it easier to
  112. see what operation is being done:
  113. if (strcmp(a, b) == 0)
  114. foo();
  115. if (strcmp(a, b) < 0)
  116. foo();
  117. Dpkg Perl coding style 2010-05-10
  118. ======================
  119. General
  120. ~~~~~~~
  121. In general you should follow the conventions listed in perlstyle(1).
  122. All the code should run with the “use strict” and “use warnings” pragmas.
  123. Code documentation
  124. ~~~~~~~~~~~~~~~~~~
  125. Public modules should be documented with POD (see perlpod(1)). Private
  126. code doesn't have to use POD, simple comment lines (starting with "#") are
  127. enough. Public scripts are documented in their corresponding manual pages.
  128. Indentation, alignment and spacing
  129. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  130. Lines should be 80 chars max. The indentation level is 4 characters, and
  131. indentation is done with hard tabs (which should be considered to take 8
  132. spaces width) and spaces.
  133. if ($foo) {
  134. if ($bar) {
  135. print "Hello\n";
  136. unless ($baz) {
  137. print "Who are you?\n";
  138. }
  139. }
  140. }
  141. Perl version
  142. ~~~~~~~~~~~~
  143. We don't want to impose a too-recent Perl version, so only use features
  144. supported by the Perl version that is currently in Debian oldstable when
  145. possible. Currently that means Perl 5.8.8.
  146. Object methods
  147. ~~~~~~~~~~~~~~
  148. Use a single line to retrieve all the arguments and use $self as name
  149. for the current object:
  150. sub do_something {
  151. my ($self, $arg1, $arg2, %opts) = @_;
  152. ...
  153. }
  154. Supplementary optional arguments should be named and thus stored in a
  155. hash.