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.
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
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.
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
----------------