update style-guide.txt

1 files changed, 79 insertions, 54 deletions

diff --git a/docs/style-guide.txt b/docs/style-guide.txt
index ba0cdbaa4..5bb3441cd 100644
--- a/docs/style-guide.txt
+++ b/docs/style-guide.txt
@@ -20,7 +20,7 @@ in the directory, just your own.
 Declaration Order
 -----------------
 
-Here is the order in which code should be laid out in a file:
+Here is the preferred order in which code should be laid out in a file:
 
  - commented program name and one-line description
  - commented author name and email address(es)
@@ -126,14 +126,15 @@ between it and the opening control block statement. Examples:
 
                 do {
 
-Exceptions:
-
- - if you have long logic statements that need to be wrapped, then uncuddling
-   the bracket to improve readability is allowed:
+If you have long logic statements that need to be wrapped, then uncuddling
+the bracket to improve readability is allowed. Generally, this style makes
+it easier for reader to notice that 2nd and following lines are still
+inside 'if':
 
-                if (some_really_long_checks && some_other_really_long_checks \
-                    && some_more_really_long_checks)
-                {
+                if (some_really_long_checks && some_other_really_long_checks
+                 && some_more_really_long_checks
+                 && even_more_of_long_checks
+                ) {
                         do_foo_now;
 
 Spacing around Parentheses
@@ -208,6 +209,23 @@ block. Example:
         }
 
 
+Labels
+~~~~~~
+
+Labels should start at the beginning of the line, not indented to the block
+level (because they do not "belong" to block scope, only to whole function).
+
+        if (foo) {
+                stmt;
+ label:
+                stmt2;
+                stmt;
+        }
+
+(Putting label at position 1 prevents diff -p from confusing label for function
+name, but it's not a policy of busybox project to enforce such a minor detail).
+
+
 
 Variable and Function Names
 ---------------------------
@@ -234,7 +252,7 @@ because it looks like whitespace; using lower-case is easy on the eyes.
 Exceptions:
 
  - Enums, macros, and constant variables are occasionally written in all
-   upper-case with words optionally seperatedy by underscores (i.e. FIFOTYPE,
+   upper-case with words optionally seperatedy by underscores (i.e. FIFO_TYPE,
    ISBLKDEV()).
 
  - Nobody is going to get mad at you for using 'pvar' as the name of a
@@ -299,22 +317,21 @@ Use 'const <type> var' for declaring constants.
 
         Don't do this:
 
-                #define var 80
+                #define CONST 80
 
         Do this instead, when the variable is in a header file and will be used in
         several source files:
 
-                const int var = 80;
-
-        Or do this when the variable is used only in a single source file:
-
-                static const int var = 80;
+                enum { CONST = 80 };
 
-Declaring variables as '[static] const' gives variables an actual type and
-makes the compiler do type checking for you; the preprocessor does _no_ type
-checking whatsoever, making it much more error prone. Declaring variables with
-'[static] const' also makes debugging programs much easier since the value of
-the variable can be easily queried and displayed.
+Although enum may look ugly to some people, it is better for code size.
+With "const int" compiler may fail to optimize it out and will reserve
+a real storage in rodata for it! (Hopefully, newer gcc will get better
+at it...).  With "define", you have slight risk of polluting namespace
+(#define doesn't allow you to redefine the name in the inner scopes),
+and complex "define" are evaluated each time they uesd, not once
+at declarations like enums. Also, the preprocessor does _no_ type checking
+whatsoever, making it much more error prone.
 
 
 The Folly of Macros
@@ -432,15 +449,16 @@ Unfortunately, the way C handles strings makes them prone to overruns when
 certain library functions are (mis)used. The following table  offers a summary
 of some of the more notorious troublemakers:
 
-function     overflows         preferred
-----------------------------------------
-strcpy       dest string       strncpy
-strcat       dest string       strncat
-gets         string it gets    fgets
-getwd        buf string        getcwd
-[v]sprintf   str buffer        [v]snprintf
-realpath     path buffer       use with pathconf
-[vf]scanf    its arguments     just avoid it
+function     overflows                  preferred
+-------------------------------------------------
+strcpy       dest string                safe_strncpy
+strncpy      may fail to 0-terminate dst safe_strncpy
+strcat       dest string                strncat
+gets         string it gets             fgets
+getwd        buf string                 getcwd
+[v]sprintf   str buffer                 [v]snprintf
+realpath     path buffer                use with pathconf
+[vf]scanf    its arguments              just avoid it
 
 
 The above is by no means a complete list. Be careful out there.
@@ -450,7 +468,7 @@ The above is by no means a complete list. Be careful out there.
 Avoid Big Static Buffers
 ------------------------
 
-First, some background to put this discussion in context: Static buffers look
+First, some background to put this discussion in context: static buffers look
 like this in code:
 
         /* in a .c file outside any functions */
@@ -500,6 +518,9 @@ between xmalloc() and stack creation, so you can code the line in question as
 
 and the right thing will happen, based on your configuration.
 
+Another relatively new trick of similar nature is explained
+in keep_data_small.txt.
+
 
 
 Miscellaneous Coding Guidelines
@@ -527,7 +548,7 @@ The only time we deviate from emulating the GNU behavior is when:
           would be required, lots more memory would be used, etc.)
         - The difference is minor or cosmetic
 
-A note on the 'cosmetic' case: Output differences might be considered
+A note on the 'cosmetic' case: output differences might be considered
 cosmetic, but if the output is significant enough to break other scripts that
 use the output, it should really be fixed.
 
@@ -577,7 +598,7 @@ like this:
                 if (foo)
                         stmt1;
                         new_line();
-                stmt2
+                stmt2;
                 stmt3;
 
 And the resulting behavior of your program would totally bewilder you. (Don't
@@ -625,7 +646,7 @@ comment too much as well as too little.
 A picture is really worth a thousand words here, the following example
 illustrates how to emphasize logical blocks:
 
-        while (line = get_line_from_file(fp)) {
+        while (line = xmalloc_fgets(fp)) {
 
                 /* eat the newline, if any */
                 chomp(line);
@@ -649,31 +670,38 @@ illustrates how to emphasize logical blocks:
 Processing Options with getopt
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If your applet needs to process  command-line switches, please use getopt() to
+If your applet needs to process command-line switches, please use getopt32() to
 do so. Numerous examples can be seen in many of the existing applets, but
 basically it boils down to two things: at the top of the .c file, have this
-line in the midst of your #includes:
+line in the midst of your #includes, if you need to parse long options:
 
         #include <getopt.h>
 
+Then have long options defined:
+
+        static const struct option <applet>_long_options[] = {
+                { "list",    0, NULL, 't' },
+                { "extract", 0, NULL, 'x' },
+                { NULL }
+        };
+
 And a code block similar to the following near the top of your applet_main()
 routine:
 
-    while ((opt = getopt(argc, argv, "abc")) > 0) {
-            switch (opt) {
-            case 'a':
-                do_a_opt = 1;
-                break;
-            case 'b':
-                do_b_opt = 1;
-                break;
-            case 'c':
-                do_c_opt = 1;
-                break;
-            default:
-                show_usage();    /* in utility.c */
-            }
-    }
+        char *str_b;
+
+        opt_complementary = "cryptic_string";
+        applet_long_options = <applet>_long_options; /* if you have them */
+        opt = getopt32(argc, argv, "ab:c", &str_b);
+        if (opt & 1) {
+                handle_option_a();
+        }
+        if (opt & 2) {
+                handle_option_b(str_b);
+        }
+        if (opt & 4) {
+                handle_option_c();
+        }
 
 If your applet takes no options (such as 'init'), there should be a line
 somewhere in the file reads:
@@ -683,7 +711,4 @@ somewhere in the file reads:
 That way, when people go grepping to see which applets need to be converted to
 use getopt, they won't get false positives.
 
-Additional Note: Do not use the getopt_long library function and do not try to
-hand-roll your own long option parsing. Busybox applets should only support
-short options. Explanations and examples of the short options should be
-documented in usage.h.
+For more info and examples, examine getopt32.c, tar.c, wget.c etc.