contrib
proc
ps
.gitignore
AUTHORS
BUGS
COPYING
COPYING.LIB
ChangeLog
CodingStyle
Makefile.am
NEWS
README
README.top
TODO
autogen.sh
configure.ac
free.1
free.c
kill.1
pgrep.1
pgrep.c
pkill.1
pmap.1
pmap.c
pwdx.1
pwdx.c
skill.1
skill.c
slabtop.1
slabtop.c
snice.1
sysctl.8
sysctl.c
sysctl.conf
sysctl.conf.5
tload.1
tload.c
top.1
top.c
top.h
uptime.1
uptime.c
vmstat.8
vmstat.c
w.1
w.c
watch.1
watch.c
102 lines
3.3 KiB
Plaintext
102 lines
3.3 KiB
Plaintext
If you start a new file, you get to choose the style.
|
|
If you change an existing file, follow the existing style.
|
|
|
|
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.
|
|
|
|
Spaces within a line don't matter much, and won't be
|
|
considered part of the style. Just make it readable:
|
|
|
|
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
|
|
|
|
This is evil:
|
|
|
|
szWinStallman
|
|
FoulCodingStyle (int iInsanity)
|
|
{
|
|
if (iInsanity)
|
|
{
|
|
GoHackEmacs () ;
|
|
}
|
|
else
|
|
{
|
|
SeekHelpForYourLisp () ;
|
|
}
|
|
}
|
|
|
|
|
|
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.
|