s4:kdc/db-glue: fix supported_enctypes samba_kdc_trust_message2entry()
[nivanova/samba-autobuild/.git] / README.Coding
index 8416290861026cd262916f2e8df2872644999516..52dca49bede76e0e884d77a32c0055e47170f68c 100644 (file)
@@ -26,9 +26,6 @@ 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.
 
-We try to stay compatible with Python 2.4, so please don't rely on any
-features that were introduced later, such as the "with" statement.
-
 But to save you the trouble of reading the Linux kernel style guide, here
 are the highlights.
 
@@ -283,8 +280,8 @@ Good Examples:
                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;
                        }
@@ -293,7 +290,7 @@ Good Examples:
                print("Allocated %d elements.\n", y);
 
         done:
-               if (z) {
+               if (z != NULL) {
                        free(z);
                }
 
@@ -301,25 +298,6 @@ Good Examples:
        }
 
 
-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
 --------------------
 
@@ -367,3 +345,54 @@ Bad Example:
        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__));