Messages in this thread Patch in this message | | | From | Michael Frank <> | Subject | PATCH, RFC: Version 5 of 2.6 Codingstyle | Date | Mon, 16 Feb 2004 11:47:53 +0800 |
| |
Changes:
Expanded references.
Pointer to RTL reference.
Cleanups and fixed more typos
diff against in-kernel version attached.
Regards Michael
--- Documentation/CodingStyle.mhf.orig.4 2004-02-15 04:30:40.000000000 +0800 +++ Documentation/CodingStyle 2004-02-16 11:38:40.000000000 +0800 @@ -41,10 +41,10 @@ if (condition) do_this; do_something_everytime;
-Outside of comments and except in Kconfig, spaces are never used for -indentation, and the above example is deliberately broken. +Outside of comments, documentation and except in Kconfig, spaces are never +used for indentation, and the above example is deliberately broken.
-Don't leave whitespace at the end of lines. +Get a decent editor and don't leave whitespace at the end of lines. Chapter 2: Breaking long lines and strings @@ -57,7 +57,7 @@ Statements longer than 80 columns will be broken into sensible chunks. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long -argument list. Long strings are as well broken into smaller strings. +argument list. Long strings are as well broken into shorter strings. void fun(int a, int b, int c) { @@ -203,12 +203,9 @@ { int result = 0; char *buffer = kmalloc(SIZE); - lock(something); - if (buffer == NULL) { - result = -1; - goto out; - } + if (buffer == NULL) + return -ENOMEM;
if (condition1) { while (loop1) { @@ -219,9 +216,7 @@ } ... out: - unlock(something); - if (buffer != NULL) // This test is not needed for kfree - kfree(buffer); // as kfree checks pointer + kfree(buffer); return result; } @@ -235,7 +230,7 @@ Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, -you should probably go back to chapter 4 for a while. You can make +you should probably go back to chapter 5 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does @@ -344,7 +339,7 @@ have a reference count on it, you almost certainly have a bug. - Chapter 11: Macros, Enums and Inline functions + Chapter 11: Macros, Enums, Inline functions and RTL Names of macros defining constants and labels in enums are capitalized. @@ -357,13 +352,13 @@ Generally, inline functions are preferable to macros resembling functions. -Macros with multiple statements should be enclosed in a do - while block. +Macros with multiple statements should be enclosed in a do - while block: -#define macrofun(a,b,c) \ -do { \ - if (a == 5) \ - do_this(b,c); \ -} while (0) +#define macrofun(a,b,c) \ + do { \ + if (a == 5) \ + do_this(b,c); \ + } while (0) Things to avoid when using macros: @@ -389,12 +384,15 @@ bite you if somebody e.g. turns FOO into an inline function.
4) forgetting about precedence: macros defining constants using expressions -must enclose the expression in parentheses. Beware of similar issues in +must enclose the expression in parentheses. Beware of similar issues with macros using parameters. #define CONSTANT 0x4000 #define CONSTEXP (CONSTANT | 3) +The cpp manual deals with macros exhaustively. The gcc internals manual also +covers RTL which is used frequently with assembly language in the kernel. + Chapter 12: Printing kernel messages @@ -404,7 +402,7 @@ Kernel messages do not have to be terminated with a period. -Printing numbers in parenthesis (%d) adds no value and should be avoided. +Printing numbers in parentheses (%d) adds no value and should be avoided. Chapter 13: References @@ -414,8 +412,12 @@ Prentice Hall, Inc., 1988. ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback). -GNU manuals for cpp, gcc and indent, available from www.gnu.org, while in -compliance with K&R and this text. +The Practice of Programming +Brian W. Kernighan, Rob Pike +Addison-Wesley, 1999, ISBN 0-201-61586-X + +GNU manuals - where in compliance with K&R and this text - for cpp, gcc, +gcc internals and indent, all available from www.gnu.org. -- -This document was updated by a community effort on LKML on 14 February 2004. +Last updated on 16 February 2004 by a community effort on LKML. | |