auth/ntlmssp_client: correct spelling of response

[samba.git] / README.Coding

diff --git a/README.Coding b/README.Coding
index c4e9dfebf9885575b810b875c999e913548afcfd..3d4c5a59e5d191bbe545ec116b938dee5710b257 100644 (file)
--- a/README.Coding
+++ b/README.Coding
@@ -16,15 +16,15 @@ style should never outweigh coding itself and so the guidelines
 described here are hopefully easy enough to follow as they are very
 common and supported by tools and editors.
 
-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 basic style for C code 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.
+http://www.python.org/pep/pep8. New Python code should be compatible with
+Python 2.6, 2.7, and Python 3.4 onwards. This means using Python 3 syntax
+with the appropriate 'from __future__' imports.
 
 But to save you the trouble of reading the Linux kernel style guide, here
 are the highlights.
@@ -90,6 +90,17 @@ 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
+BinPackArguments: false
+
 
 =========================
 FAQ & Statement Reference
@@ -189,7 +200,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 calls, declarations, and
+definitions. In function calls, 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
@@ -374,6 +391,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) {
@@ -428,6 +446,55 @@ The only exception is the test code that depends repeated use of calls
 like CHECK_STATUS, CHECK_VAL and others.
 
 
+Error and out logic
+-------------------
+
+Don't do this:
+
+       frame = talloc_stackframe();
+
+       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
 ----------------