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.
|
Most developers find Linux coding style easy to read, and there is
|
||||||
If you change an existing file, follow the existing style.
|
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
|
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle
|
||||||
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.
|
|
||||||
|
|
||||||
Spaces within a line don't matter much, and won't be
|
In addtion to Linux coding style this project has few addtional
|
||||||
considered part of the style. Just make it readable:
|
wishes to contributors.
|
||||||
|
|
||||||
if(x){ // OK
|
* Many small patches are favoured over one big. Break down is done on
|
||||||
if( x ){ // OK
|
basis of logical functionality; for example #endif mark ups,
|
||||||
if (x) { // OK
|
compiler warning and exit codes fixes all should be individual
|
||||||
if(x==y && a==b){ // OK
|
small patches.
|
||||||
if(x == y && a == b){ // poor
|
|
||||||
if(x==y&&a==b){ // poor
|
|
||||||
|
|
||||||
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
|
* In writing arithmetic comparisons, use "<" and "<=" rather than
|
||||||
FoulCodingStyle (int iInsanity)
|
">" and ">=". For some justification, read this:
|
||||||
{
|
http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
|
||||||
if (iInsanity)
|
|
||||||
{
|
|
||||||
GoHackEmacs () ;
|
|
||||||
}
|
|
||||||
else
|
|
||||||
{
|
|
||||||
SeekHelpForYourLisp () ;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
|
* Be nice to translators. Don't change translatable strings if you
|
||||||
Curly braces belong at the end of a line. If you must, go ahead
|
can avoid it. If you must rearrange individual lines (e.g., in
|
||||||
and make function bodies an exception to that rule. (as Linus does)
|
multi-line --help strings), extract and create new strings, rather
|
||||||
|
than extracting and moving into existing blocks. This avoids
|
||||||
Big fprintf() calls and similar go like this:
|
making unnecessary work for translators.
|
||||||
|
|
||||||
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.
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user