Some additional tips and formatting changes.

diff --git a/docs/style-guide.txt b/docs/style-guide.txt
index d1257b7552d84594846b7df5e25a41f4197e8432..72d3b9375f7e5384e16d90615c9e4716474e94c4 100644 (file)
--- a/docs/style-guide.txt
+++ b/docs/style-guide.txt
@@ -15,6 +15,7 @@ files by typing 'indent myfile.c myfile.h' and it will magically apply all the
 right formatting rules to your file. Please _do_not_ run this on all the files
 in the directory, just your own.
 
+
 Declaration Order
 -----------------
 
@@ -28,15 +29,22 @@ Here is the order in which code should be laid out in a file:
  - function declarations (if necessary)
  - function implementations
 
+
 Whitespace
 ----------
 
-Tabs vs Spaces in Line Indentation: The preference in Busybox is to indent
-lines with tabs. Do not indent lines with spaces and do not indents lines
-using a mixture of tabs and spaces. (The indentation style in the Apache and
-Postfix source does this sort of thing: \s\s\s\sif (expr) {\n\tstmt; --ick.)
-The only exception to this rule is multi-line comments that use an asterisk at
-the beginning of each line, i.e.:
+This is everybody's favorite flame topic so let's get it out of the way right
+up front.
+
+
+Tabs vs Spaces in Line Indentation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The preference in Busybox is to indent lines with tabs. Do not indent lines
+with spaces and do not indents lines using a mixture of tabs and spaces. (The
+indentation style in the Apache and Postfix source does this sort of thing:
+\s\s\s\sif (expr) {\n\tstmt; --ick.) The only exception to this rule is
+multi-line comments that use an asterisk at the beginning of each line, i.e.:
 
        /t/*
        /t * This is a block comment.
@@ -52,7 +60,10 @@ lines is that you can set your editor to display tabs at *watever* number of
 spaces is desired and the code will still look fine.
 
 
-Operator Spacing: Put spaces between terms and operators. Example:
+Operator Spacing
+~~~~~~~~~~~~~~~~
+
+Put spaces between terms and operators. Example:
 
        Don't do this:
 
@@ -74,7 +85,10 @@ Operator Spacing: Put spaces between terms and operators. Example:
                if ((argc-1) - (optind+1) > 0)
 
 
-Bracket Spacing: If an opening bracket starts a function, it should be on the
+Bracket Spacing
+~~~~~~~~~~~~~~~
+
+If an opening bracket starts a function, it should be on the
 next line with no spacing before it. However, if a bracet follows an opening
 control block, it should be on the same line with a single space (not a tab)
 between it and the opening control block statment. Examples:
@@ -89,28 +103,11 @@ between it and the opening control block statment. Examples:
                while (!done) {
                do {
 
-Also, please "cuddle" your else statments by putting the else keyword on the
-same line after the right bracket that closes an 'if' statment.
-
-       Don't do this:
-
-       if (foo) {
-               stmt;
-       }
-       else {
-               stmt;
-       }
-
-       Do this instead:
-
-       if (foo) {
-               stmt;
-       } else {
-               stmt;
-       }
 
+Paren Spacing
+~~~~~~~~~~~~~
 
-Paren Spacing: Put a space between C keywords and left parens, but not between
+Put a space between C keywords and left parens, but not between
 function names and the left paren that starts it's parameter list (whether it
 is being declared or called). Examples:
 
@@ -130,6 +127,31 @@ is being declared or called). Examples:
                ...
                baz = my_func(1, 2);
 
+
+Cuddled Elses
+~~~~~~~~~~~~~
+
+Also, please "cuddle" your else statments by putting the else keyword on the
+same line after the right bracket that closes an 'if' statment.
+
+       Don't do this:
+
+       if (foo) {
+               stmt;
+       }
+       else {
+               stmt;
+       }
+
+       Do this instead:
+
+       if (foo) {
+               stmt;
+       } else {
+               stmt;
+       }
+
+
 Variable and Function Names
 ---------------------------
 
@@ -155,6 +177,12 @@ Tip and Pointers
 
 The following are simple coding guidelines that should be followed:
 
+ - When in doubt about the propper behavior of a busybox program (output,
+   formatting, options, etc.), model it after the equivalent GNU program.
+   Doesn't matter how that program behaves on some other flavor of *NIX;
+   doesn't matter what the POSIX standard says or doesn't say, just model
+   busybox programs after their GNU counterparts and nobody has to get hurt.
+
  - Don't use a '#define var 80' when you can use 'static const int var 80'
    instead. This makes the compiler do typechecking for you (rather than
    relying on the more error-prone preprocessor) and it makes debugging