described here are hopefully easy enough to follow as they are very
common and supported by tools and editors.
-The basic style, also mentioned in prog_guide4.txt, is the Linux kernel
+The basic style for C code, also mentioned in prog_guide4.txt, is the Linux kernel
coding style (See Documentation/CodingStyle in the kernel source tree). This
closely matches what most Samba developers use already anyways, with a few
exceptions as mentioned below.
+The coding style for Python code is documented in PEP8,
+http://www.python.org/pep/pep8 (with spaces).
+If you have ever worked on another free software Python project, you are
+probably already familiar with it.
+
But to save you the trouble of reading the Linux kernel style guide, here
are the highlights.
Comments should always use the standard C syntax. C++
style comments are not currently allowed.
+The lines before a comment should be empty. If the comment directly
+belongs to the following code, there should be no empty line
+after the comment, except if the comment contains a summary
+of multiple following code blocks.
+
+This is good:
+
+ ...
+ int i;
+
+ /*
+ * This is a multi line comment,
+ * which explains the logical steps we have to do:
+ *
+ * 1. We need to set i=5, because...
+ * 2. We need to call complex_fn1
+ */
+
+ /* This is a one line comment about i = 5. */
+ i = 5;
+
+ /*
+ * This is a multi line comment,
+ * explaining the call to complex_fn1()
+ */
+ ret = complex_fn1();
+ if (ret != 0) {
+ ...
+
+ /**
+ * @brief This is a doxygen comment.
+ *
+ * This is a more detailed explanation of
+ * this simple function.
+ *
+ * @param[in] param1 The parameter value of the function.
+ *
+ * @param[out] result1 The result value of the function.
+ *
+ * @return 0 on success and -1 on error.
+ */
+ int example(int param1, int *result1);
+
+This is bad:
+
+ ...
+ int i;
+ /*
+ * This is a multi line comment,
+ * which explains the logical steps we have to do:
+ *
+ * 1. We need to set i=5, because...
+ * 2. We need to call complex_fn1
+ */
+ /* This is a one line comment about i = 5. */
+ i = 5;
+ /*
+ * This is a multi line comment,
+ * explaining the call to complex_fn1()
+ */
+ ret = complex_fn1();
+ if (ret != 0) {
+ ...
+
+ /*This is a one line comment.*/
+
+ /* This is a multi line comment,
+ with some more words...*/
+
+ /*
+ * This is a multi line comment,
+ * with some more words...*/
Indention & Whitespace & 80 columns
-----------------------------------
int ret = 0;
if (y < 10) {
- z = malloc(sizeof(int)*y);
- if (!z) {
+ z = malloc(sizeof(int) * y);
+ if (z == NULL) {
ret = 1;
goto done;
}
print("Allocated %d elements.\n", y);
done:
- if (z) {
+ if (z != NULL) {
free(z);
}
}
-Checking Pointer Values
------------------------
-
-When invoking functions that return pointer values, either of the following
-are acceptable. Use your best judgement and choose the more readable option.
-Remember that many other persons will review it:
-
- if ((x = malloc(sizeof(short)*10)) == NULL ) {
- fprintf(stderr, "Unable to alloc memory!\n");
- }
-
-or:
-
- x = malloc(sizeof(short)*10);
- if (!x) {
- fprintf(stderr, "Unable to alloc memory!\n");
- }
-
-
Primitive Data Types
--------------------
ret = some_function_my_name(get_some_name());
...
+Please try to avoid passing function return values to if- or
+while-conditions. The reason for this is better handling of code under a
+debugger.
+
+Good example:
+
+ x = malloc(sizeof(short)*10);
+ if (x == NULL) {
+ fprintf(stderr, "Unable to alloc memory!\n");
+ }
+
+Bad example:
+
+ if ((x = malloc(sizeof(short)*10)) == NULL ) {
+ fprintf(stderr, "Unable to alloc memory!\n");
+ }
+
+There are exceptions to this rule. One example is walking a data structure in
+an iterator style:
+
+ while ((opt = poptGetNextOpt(pc)) != -1) {
+ ... do something with opt ...
+ }
+
+But in general, please try to avoid this pattern.
+
+
+Control-Flow changing macros
+----------------------------
+
+Macros like NT_STATUS_NOT_OK_RETURN that change control flow
+(return/goto/etc) from within the macro are considered bad, because
+they look like function calls that never change control flow. Please
+do not use them in new code.
+
+The only exception is the test code that depends repeated use of calls
+like CHECK_STATUS, CHECK_VAL and others.
+
+
+Function names in DEBUG statements
+----------------------------------
+
+Many DEBUG statements contain the name of the function they appear in. This is
+not a good idea, as this is prone to bitrot. Function names change, code
+moves, but the DEBUG statements are not adapted. Use %s and __func__ for this:
+
+Bad Example:
+ DEBUG(0, ("strstr_m: src malloc fail\n"));
+
+Good Example:
+ DEBUG(0, ("%s: src malloc fail\n", __func__));