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
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
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;
}
print("Allocated %d elements.\n", y);
done:
- if (z) {
+ if (z != NULL) {
free(z);
}
* 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
--------
"struct x { .. };". We know there are still such typedefs in the code,
but for new code, please don't do that anymore.
+Initialize pointers
+-------------------
+
+All pointer variables MUST be initialized to NULL. History has
+demonstrated that uninitialized pointer variables have lead to various
+bugs and security issues.
+
+Pointers MUST be initialized even if the assignment directly follows
+the declaration, like pointer2 in the example below, because the
+instructions sequence may change over time.
+
+Good Example:
+
+ char *pointer1 = NULL;
+ char *pointer2 = NULL;
+
+ pointer2 = some_func2();
+
+ ...
+
+ pointer1 = some_func1();
+
+Bad Example:
+
+ char *pointer1;
+ char *pointer2;
+
+ pointer2 = some_func2();
+
+ ...
+
+ pointer1 = some_func1();
+
Make use of helper variables
----------------------------
Good Example:
- char *name;
+ char *name = NULL;
+ int ret;
name = get_some_name();
if (name == NULL) {
Good example:
x = malloc(sizeof(short)*10);
- if (!x) {
+ if (x == NULL) {
fprintf(stderr, "Unable to alloc memory!\n");
}
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.
git.samba.org / metze / samba / wip.git / blobdiff