aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/style-guide.txt133
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.