s3: VFS: Add a synchronous smb_vfs_fsync_sync() call, built from async primitives.

[samba.git] / README.Coding

diff --git a/README.Coding b/README.Coding
index 19a363fa1dd13d3f605fc9c009a55fae17cb79ac..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.
@@ -99,6 +99,7 @@ BreakBeforeBraces: Linux
 AllowShortIfStatementsOnASingleLine: false
 IndentCaseLabels: false
 BinPackParameters: false
+BinPackArguments: false
 
 
 =========================
@@ -201,8 +202,8 @@ 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.
 
-One exception to the previous rule is function declarations and
-definitions. In function declarations and definitions, either the
+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.
@@ -445,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
 ----------------