Coding style

From UBIFSWiki

Kernel Coding Style

Additional comments

ChangeLogs

• Log message must have the following line at the end

Signed-off-by: Your name <your email address>

• Just describe what the commit does. No per-file description is needed.

Comments

• No C++ comments.

// Comment
==>
/* Comment */

• The form of short comment (don't use period):

/* Your short comment */

• The form of long comment (use period):

/*
 * Your long
 * comment.
 */

• Comment only non-obvious/tricky things, not the obvious ones.
• In short descriptions, do not use dot.

@elem: this is an element.
==>
@elem: this is an element

• Do not name enums. Do not use enum types anyway.

enum name_of_enum {
...
}
==>
enum {
...
}

Notification and Error Messages

• In general, we use the following strategy to print errors: the lowest function prints error message, the callers don't. Of course there may be exceptions.
  • E.g. if you call wbuf_write() from xxx() and it returns an error, do not print any error message because wbuf_write() have already done it. Just return error code up to the caller.

Macros

• Use spaces, not tabs to align "\" sign for the end of multi-line macros

#define M_XYZ .......->\    // "." means space, "->" means tab character
......abcd->->..\
==> 
#define M_XYZ .........\
......abcd.............\

Declaration

• Define variables in one line.

int a;
int b;
int c;
==>
int a, b, c;

Types

• Do not use space between conversion type and variable.

(uint32_t) msg
==>
(uint32_t)msg