STYLE 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181
  1. Code style
  2. ==========
  3. In general, FreeBSD style(9) should be followed unless it is irrelevant
  4. (e.g., $FreeBSD$ tags).
  5. Functions with external linkage are declared like this:
  6. /**
  7. * module_func(arg1, arg2):
  8. * Description of what the function does, referring to arguments as
  9. * ${arg1} or suchlike.
  10. */
  11. int module_func(void *, int);
  12. The identical comment appears in the C file where the function is defined.
  13. Static functions may have the above form of comment, or simply a
  14. /* Brief description of what the function does. */
  15. line before the function.
  16. Line lengths should generally be 78 characters, and not more than 80
  17. characters.
  18. In general, functions should return (int)(-1) or NULL to indicate error.
  19. Errors should be printed via warnp (if errno is relevant) or warn0 (if errno
  20. is not relevant) when they are first detected and also at higher levels where
  21. useful. As an exception to this, malloc failures (i.e., errno = ENOMEM) can
  22. result in failure being passed back up the call chain without being printed
  23. immediately. (Naturally, other errors can be passed back where a function
  24. definition so specifies; e.g., ENOENT in cases where a file not existing is
  25. not erronous.)
  26. The first statement in main(), after variable declarations, should be
  27. "WARNP_INIT;" in order to set the program name used for printing warnings.
  28. In general, functions should be structured with one return statement per
  29. status, e.g., one return() for success and one return() for failure. Errors
  30. should be handled by using goto to enter the error return path, e.g.,
  31. int
  32. foo(int bar)
  33. {
  34. if (something fails)
  35. goto err0;
  36. /* ... */
  37. if (something else fails)
  38. goto err1;
  39. /* ... */
  40. if (yet another operation fails)
  41. goto err2;
  42. /* Success! */
  43. return (0);
  44. err2:
  45. /* Clean up something. */
  46. err1:
  47. /* Clean up something else. */
  48. err0:
  49. /* Failure! */
  50. return (-1);
  51. }
  52. As an exception to the above, if there is only one way for the function to
  53. fail, the idioms
  54. return (baz(bar));
  55. and
  56. int rc;
  57. rc = baz(bar);
  58. /* ... cleanup code here ... */
  59. return (rc);
  60. are allowed; furthermore, in cases such as foo_free(), the idiom
  61. if (we shouldn't do anything)
  62. return;
  63. is preferred over
  64. if (we shouldn't do anything)
  65. goto done;
  66. at the start of a function.
  67. Headers should be included in the following groups, with a blank line after
  68. each (non-empty) group:
  69. 1. <sys/*.h>, with <sys/types.h> first followed by others alphabetically.
  70. 2. <net/*.h>, in alphabetical order.
  71. 3. <*.h>, in alphabetical order.
  72. 4. header files from /lib/, in alphabetical order.
  73. 5. header files from the program being built, in alphabetical order.
  74. 6. header files (usually just one) defining the interface for this C file.
  75. If ssize_t is needed, <unistd.h> should be included to provide it.
  76. If size_t is needed, <stddef.h> should be included to provide it unless
  77. <stdio.h>, <stdlib.h>, <string.h>, or <unistd.h> is already required.
  78. If the C99 integer types (uint8_t, int64_t, etc.) are required, <stdint.h>
  79. should be included to provide them unless <inttypes.h> is already required.
  80. The type 'char' should only be used to represent human-readable characters
  81. (input from users, output to users, pathnames, et cetera). The type
  82. 'char *' should normally be a NUL-terminated string. The types 'signed
  83. char' and 'unsigned char' should never be used; C99 integer types should
  84. be used instead.
  85. When a variable is declared to have a pointer type, there should be a space
  86. between the '*' and the variable name, e.g.,
  87. int
  88. main(int argc, char * argv[])
  89. {
  90. char * opt_p = NULL;
  91. Note that this is inconsistent with FreeBSD style(9). When used as a unary
  92. operator, '*' is not separated from its argument, e.g.,
  93. while (*p != '\0')
  94. p++;
  95. When a struct is referenced, the idiom
  96. /* Opaque types. */
  97. struct foo;
  98. struct bar * bar_from_foo(struct foo *);
  99. is preferable to
  100. #include "foo.h" /* needed for struct foo */
  101. struct bar * bar_from_foo(struct foo *);
  102. unless there is some reason why the internal layout of struct foo is needed
  103. (e.g., if struct bar contains a struct foo rather than a struct foo *). Such
  104. struct declarations should be sorted alphabetically.
  105. The file foo.c should only export symbols of the following forms:
  106. foo_* -- most symbols should be of this form.
  107. FOO_* / BAR_FOO_*
  108. -- allowed in cases where FOO or BAR_FOO is idiomatic (e.g.,
  109. MD5, HMAC_SHA256).
  110. foo() / defoo() / unfoo()
  111. -- where "foo" is a verb and this improves code clarity.
  112. Functions named foo_free should return void, and foo_free(NULL) should have
  113. no effect. The right way to spell a comment about this is
  114. /* Behave consistently with free(NULL). */
  115. If static variables need to be initialized to 0 (or NULL) then they should be
  116. explicitly declared that way; implicit initialization should not be used.
  117. In non-trivial code, comments should be included which describe in English
  118. what is being done by the surrounding code with sufficient detail that if the
  119. code were removed, it could be replaced based on reading the comments without
  120. requiring any significant creativity.
  121. Comments and documentation should be written in en-GB-oed; i.e., with
  122. the 'u' included in words such as "honour", "colour", and "neighbour",
  123. and the ending '-ize' in words such as "organize" and "realize". The
  124. Oxford (aka. serial) comma should be used in lists. Quotation marks
  125. should be placed logically, i.e., not including punctuation marks which
  126. do not form a logical part of the quoted text. Two spaces should be used
  127. after a period which ends a sentence.
  128. When versions of functions are written to exploit special CPU features
  129. (using the cpusupport framework), that code should be placed into a
  130. separate file (e.g., crypto_aes_aesni.c) so that it can be compiled with
  131. different compiler flags. Such a file should start with
  132. #include "cpusupport.h"
  133. #ifdef CPUSUPPORT_FOO_BAR
  134. and end with
  135. #endif /* CPUSUPPORT_FOO_BAR */
  136. Functions for which special CPU-feature-exploiting variants exist should
  137. take the form
  138. {
  139. /* Variable declarations here. */
  140. /* Asserts here, if any. */
  141. #ifdef CPUSUPPORT_FOO_BAR
  142. if (/* We've decided we can use the variant code */) {
  143. /* Call variant code and return. */
  144. }
  145. #endif
  146. /* Normal implementation of the function. */
  147. }