s4:kdc: only map SDB_ERR_NOT_FOUND_HERE to HDB_ERR_NOT_FOUND_HERE

[metze/samba/wip.git] / README.Coding

diff --git a/README.Coding b/README.Coding
index 9073b77118af0ae06f6621128f6012c0912d8241..e89925cad264fcf237fe8e06513fc7c6247e744c 100644 (file)
--- a/README.Coding
+++ b/README.Coding
@@ -90,6 +90,16 @@ displaying trailing whitespace:
   set textwidth=80
   autocmd BufNewFile,BufRead *.c,*.h exec 'match Todo /\%>' . &textwidth . 'v.\+/'
 
+clang-format
+------------
+BasedOnStyle: LLVM
+IndentWidth: 8
+UseTab: true
+BreakBeforeBraces: Linux
+AllowShortIfStatementsOnASingleLine: false
+IndentCaseLabels: false
+BinPackParameters: false
+
 
 =========================
 FAQ & Statement Reference
@@ -189,7 +199,13 @@ characters or less with whitespace.  For example,
 The previous example is intended to illustrate alignment of function
 parameters across lines and not as encourage for gratuitous line
 splitting.  Never split a line before columns 70 - 79 unless you
-have a really good reason.  Be smart about formatting.
+have a really good reason. Be smart about formatting.
+
+One exception to the previous rule is function declarations and
+definitions. In function declarations and definitions, either the
+declaration is a one-liner, or each parameter is listed on its own
+line. The rationale is that if there are many parameters, each one
+should be on its own line to make tracking interface changes easier.
 
 
 If, switch, & Code blocks
@@ -312,6 +328,17 @@ lib/replace/, new code should adhere to the following conventions:
   * Boolean values are "true" and "false" (not True or False)
   * Exact width integers are of type [u]int[8|16|32|64]_t
 
+Most of the time a good name for a boolean variable is 'ok'. Here is an
+example we often use:
+
+       bool ok;
+
+       ok = foo();
+       if (!ok) {
+               /* do something */
+       }
+
+It makes the code more readable and is easy to debug.
 
 Typedefs
 --------
@@ -363,6 +390,7 @@ it's also easier to use the "step" command within gdb.
 Good Example:
 
        char *name = NULL;
+       int ret;
 
        name = get_some_name();
        if (name == NULL) {
@@ -417,15 +445,70 @@ 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
-----------------------------------
+Error and out logic
+-------------------
 
-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:
+Don't do this:
 
-Bad Example:
-       DEBUG(0, ("strstr_m: src malloc fail\n"));
+       frame = talloc_stackframe();
 
-Good Example:
-       DEBUG(0, ("%s: src malloc fail\n", __func__));
+       if (ret == LDB_SUCCESS) {
+               if (result->count == 0) {
+                       ret = LDB_ERR_NO_SUCH_OBJECT;
+               } else {
+                       struct ldb_message *match =
+                               get_best_match(dn, result);
+                       if (match == NULL) {
+                               TALLOC_FREE(frame);
+                               return LDB_ERR_OPERATIONS_ERROR;
+                       }
+                       *msg = talloc_move(mem_ctx, &match);
+               }
+       }
+
+       TALLOC_FREE(frame);
+       return ret;
+
+It should be:
+
+       frame = talloc_stackframe();
+
+       if (ret != LDB_SUCCESS) {
+               TALLOC_FREE(frame);
+               return ret;
+       }
+
+       if (result->count == 0) {
+               TALLOC_FREE(frame);
+               return LDB_ERR_NO_SUCH_OBJECT;
+       }
+
+       match = get_best_match(dn, result);
+       if (match == NULL) {
+               TALLOC_FREE(frame);
+               return LDB_ERR_OPERATIONS_ERROR;
+       }
+
+       *msg = talloc_move(mem_ctx, &match);
+       TALLOC_FREE(frame);
+       return LDB_SUCCESS;
+
+
+DEBUG statements
+----------------
+
+Use these following macros instead of DEBUG:
+
+DBG_ERR        log level 0             error conditions
+DBG_WARNING    log level 1             warning conditions
+DBG_NOTICE     log level 3             normal, but significant, condition
+DBG_INFO       log level 5             informational message
+DBG_DEBUG      log level 10            debug-level message
+
+Example usage:
+
+DBG_ERR("Memory allocation failed\n");
+DBG_DEBUG("Received %d bytes\n", count);
+
+The messages from these macros are automatically prefixed with the
+function name.