other: update CodingStyle
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This commit is contained in:
Sami Kerola
parent
5aabf74e73
commit
feb25fc10e
@ -1,101 +1,27 @@
|
||||
If you start a new file, you get to choose the style.
|
||||
If you change an existing file, follow the existing style.
|
||||
Most developers find Linux coding style easy to read, and there is
|
||||
really no reason to reinvent this practise, so procps-ng goes along
|
||||
with others.
|
||||
|
||||
Hard tabs are OK, as long as you consider the tab stops to
|
||||
be every 8 characters. You can also use 2, 3, or 4 spaces.
|
||||
Tabs are kind of yucky, since cut-and-paste mangles them
|
||||
sometimes and they make "diff -Naurd old new" output less
|
||||
readable.
|
||||
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle
|
||||
|
||||
Spaces within a line don't matter much, and won't be
|
||||
considered part of the style. Just make it readable:
|
||||
In addtion to Linux coding style this project has few addtional
|
||||
wishes to contributors.
|
||||
|
||||
if(x){ // OK
|
||||
if( x ){ // OK
|
||||
if (x) { // OK
|
||||
if(x==y && a==b){ // OK
|
||||
if(x == y && a == b){ // poor
|
||||
if(x==y&&a==b){ // poor
|
||||
* Many small patches are favoured over one big. Break down is done on
|
||||
basis of logical functionality; for example #endif mark ups,
|
||||
compiler warning and exit codes fixes all should be individual
|
||||
small patches.
|
||||
|
||||
This is evil:
|
||||
* Use 'FIXME: ' in code comments, manual pages, autotools files,
|
||||
scripts and so on to indicate something is wrong. The reason we do
|
||||
is as simple as being able to find easily where problem areas are.
|
||||
|
||||
szWinStallman
|
||||
FoulCodingStyle (int iInsanity)
|
||||
{
|
||||
if (iInsanity)
|
||||
{
|
||||
GoHackEmacs () ;
|
||||
}
|
||||
else
|
||||
{
|
||||
SeekHelpForYourLisp () ;
|
||||
}
|
||||
}
|
||||
* In writing arithmetic comparisons, use "<" and "<=" rather than
|
||||
">" and ">=". For some justification, read this:
|
||||
http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
|
||||
|
||||
|
||||
Curly braces belong at the end of a line. If you must, go ahead
|
||||
and make function bodies an exception to that rule. (as Linus does)
|
||||
|
||||
Big fprintf() calls and similar go like this:
|
||||
|
||||
fprintf(fd, "%d %d %d %d %d %d\n",
|
||||
sdfsdf_sdfsdf + sdfs_iii, // not an example of good names!
|
||||
iijjij,
|
||||
kjfkkj_sdfssss_sfff,
|
||||
sdflkjfdskj + sdf - sfds,
|
||||
jksss,
|
||||
sfssss + wwwwfwfw
|
||||
);
|
||||
|
||||
Keep these distinct: NULL, '\0', 0, 0.0
|
||||
|
||||
Command-line parsers need to be bomb-proof. It is not acceptable
|
||||
to crash due to a messed up command-line. For an option "-x" that
|
||||
takes an argument, accept both "-x arg" and "-xarg". Remember to
|
||||
support "--" and "--version".
|
||||
|
||||
Be extremely careful when handling data from other users.
|
||||
For example, it is a security hole if /proc/123/cmdline can
|
||||
overflow an array. It is often a security hole if you allow
|
||||
non-ASCII characters to be printed. Assuming the console is
|
||||
not in UTF-8 mode, all of these are bad: "\b\e\f\n\r\t\v\x9b".
|
||||
(the "\x9b" is valid in UTF-8 mode, but equivalent to "\e["
|
||||
when not in UTF-8 mode -- which gives control of terminal
|
||||
settings) It's best if you consider user-supplied data to
|
||||
be unsafe, since this makes for less work in case the code
|
||||
ends up needing to run setuid. Termcap data is user-supplied.
|
||||
Except for the above security issues, don't bother to check
|
||||
for something you can't handle... like printf() failing.
|
||||
It is expected that /dev exists and so on.
|
||||
|
||||
Remember that a read() may return early, with partial data
|
||||
or with -1 and errno set to EINTR. You then must try again.
|
||||
|
||||
char: may be signed or unsigned by default
|
||||
int: always 32-bit
|
||||
long long: always 64-bit
|
||||
pointer: either 32-bit or 64-bit
|
||||
long: same size as a pointer
|
||||
KLONG: same size as a pointer or long IN THE KERNEL
|
||||
|
||||
Functions used in just one file must be marked static.
|
||||
Use the "const" and "restrict" keywords wherever you can.
|
||||
|
||||
Put main() at the bottom of a file so you don't need all
|
||||
those ugly forward declarations.
|
||||
|
||||
Avoid the strcat() function. It is slow. For some odd
|
||||
reason, snprintf() is faster than sprintf().
|
||||
|
||||
Reuse memory allocations when you can. When using realloc(),
|
||||
do your increments by more than one. 25% is a nice amount.
|
||||
|
||||
Avoid compile-time choices. They make documentation difficult,
|
||||
and they are not friendly to binary distribution.
|
||||
|
||||
Write programs that can handle a million processes without
|
||||
getting hopelessly slow. Allow for /proc/123/cmdline to
|
||||
be at least 128 kB.
|
||||
|
||||
The LGPL license is strongly preferred. This allows use of
|
||||
the code in the library.
|
||||
* Be nice to translators. Don't change translatable strings if you
|
||||
can avoid it. If you must rearrange individual lines (e.g., in
|
||||
multi-line --help strings), extract and create new strings, rather
|
||||
than extracting and moving into existing blocks. This avoids
|
||||
making unnecessary work for translators.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user