mirror of
https://github.com/sheumann/hush.git
synced 2024-10-12 01:24:10 +00:00
update style-guide.txt
This commit is contained in:
parent
58394b1e29
commit
91de7c0328
@ -20,7 +20,7 @@ in the directory, just your own.
|
|||||||
Declaration Order
|
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 program name and one-line description
|
||||||
- commented author name and email address(es)
|
- commented author name and email address(es)
|
||||||
@ -126,14 +126,15 @@ between it and the opening control block statement. Examples:
|
|||||||
|
|
||||||
do {
|
do {
|
||||||
|
|
||||||
Exceptions:
|
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 you have long logic statements that need to be wrapped, then uncuddling
|
if (some_really_long_checks && some_other_really_long_checks
|
||||||
the bracket to improve readability is allowed:
|
&& some_more_really_long_checks
|
||||||
|
&& even_more_of_long_checks
|
||||||
if (some_really_long_checks && some_other_really_long_checks \
|
) {
|
||||||
&& some_more_really_long_checks)
|
|
||||||
{
|
|
||||||
do_foo_now;
|
do_foo_now;
|
||||||
|
|
||||||
Spacing around Parentheses
|
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
|
Variable and Function Names
|
||||||
---------------------------
|
---------------------------
|
||||||
@ -234,7 +252,7 @@ because it looks like whitespace; using lower-case is easy on the eyes.
|
|||||||
Exceptions:
|
Exceptions:
|
||||||
|
|
||||||
- Enums, macros, and constant variables are occasionally written in all
|
- 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()).
|
ISBLKDEV()).
|
||||||
|
|
||||||
- Nobody is going to get mad at you for using 'pvar' as the name of a
|
- 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:
|
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
|
Do this instead, when the variable is in a header file and will be used in
|
||||||
several source files:
|
several source files:
|
||||||
|
|
||||||
const int var = 80;
|
enum { CONST = 80 };
|
||||||
|
|
||||||
Or do this when the variable is used only in a single source file:
|
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
|
||||||
static const int var = 80;
|
a real storage in rodata for it! (Hopefully, newer gcc will get better
|
||||||
|
at it...). With "define", you have slight risk of polluting namespace
|
||||||
Declaring variables as '[static] const' gives variables an actual type and
|
(#define doesn't allow you to redefine the name in the inner scopes),
|
||||||
makes the compiler do type checking for you; the preprocessor does _no_ type
|
and complex "define" are evaluated each time they uesd, not once
|
||||||
checking whatsoever, making it much more error prone. Declaring variables with
|
at declarations like enums. Also, the preprocessor does _no_ type checking
|
||||||
'[static] const' also makes debugging programs much easier since the value of
|
whatsoever, making it much more error prone.
|
||||||
the variable can be easily queried and displayed.
|
|
||||||
|
|
||||||
|
|
||||||
The Folly of Macros
|
The Folly of Macros
|
||||||
@ -433,8 +450,9 @@ certain library functions are (mis)used. The following table offers a summary
|
|||||||
of some of the more notorious troublemakers:
|
of some of the more notorious troublemakers:
|
||||||
|
|
||||||
function overflows preferred
|
function overflows preferred
|
||||||
----------------------------------------
|
-------------------------------------------------
|
||||||
strcpy dest string strncpy
|
strcpy dest string safe_strncpy
|
||||||
|
strncpy may fail to 0-terminate dst safe_strncpy
|
||||||
strcat dest string strncat
|
strcat dest string strncat
|
||||||
gets string it gets fgets
|
gets string it gets fgets
|
||||||
getwd buf string getcwd
|
getwd buf string getcwd
|
||||||
@ -450,7 +468,7 @@ The above is by no means a complete list. Be careful out there.
|
|||||||
Avoid Big Static Buffers
|
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:
|
like this in code:
|
||||||
|
|
||||||
/* in a .c file outside any functions */
|
/* 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.
|
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
|
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.)
|
would be required, lots more memory would be used, etc.)
|
||||||
- The difference is minor or cosmetic
|
- 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
|
cosmetic, but if the output is significant enough to break other scripts that
|
||||||
use the output, it should really be fixed.
|
use the output, it should really be fixed.
|
||||||
|
|
||||||
@ -577,7 +598,7 @@ like this:
|
|||||||
if (foo)
|
if (foo)
|
||||||
stmt1;
|
stmt1;
|
||||||
new_line();
|
new_line();
|
||||||
stmt2
|
stmt2;
|
||||||
stmt3;
|
stmt3;
|
||||||
|
|
||||||
And the resulting behavior of your program would totally bewilder you. (Don't
|
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
|
A picture is really worth a thousand words here, the following example
|
||||||
illustrates how to emphasize logical blocks:
|
illustrates how to emphasize logical blocks:
|
||||||
|
|
||||||
while (line = get_line_from_file(fp)) {
|
while (line = xmalloc_fgets(fp)) {
|
||||||
|
|
||||||
/* eat the newline, if any */
|
/* eat the newline, if any */
|
||||||
chomp(line);
|
chomp(line);
|
||||||
@ -649,30 +670,37 @@ illustrates how to emphasize logical blocks:
|
|||||||
Processing Options with getopt
|
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
|
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
|
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>
|
#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()
|
And a code block similar to the following near the top of your applet_main()
|
||||||
routine:
|
routine:
|
||||||
|
|
||||||
while ((opt = getopt(argc, argv, "abc")) > 0) {
|
char *str_b;
|
||||||
switch (opt) {
|
|
||||||
case 'a':
|
opt_complementary = "cryptic_string";
|
||||||
do_a_opt = 1;
|
applet_long_options = <applet>_long_options; /* if you have them */
|
||||||
break;
|
opt = getopt32(argc, argv, "ab:c", &str_b);
|
||||||
case 'b':
|
if (opt & 1) {
|
||||||
do_b_opt = 1;
|
handle_option_a();
|
||||||
break;
|
|
||||||
case 'c':
|
|
||||||
do_c_opt = 1;
|
|
||||||
break;
|
|
||||||
default:
|
|
||||||
show_usage(); /* in utility.c */
|
|
||||||
}
|
}
|
||||||
|
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
|
If your applet takes no options (such as 'init'), there should be a line
|
||||||
@ -683,7 +711,4 @@ somewhere in the file reads:
|
|||||||
That way, when people go grepping to see which applets need to be converted to
|
That way, when people go grepping to see which applets need to be converted to
|
||||||
use getopt, they won't get false positives.
|
use getopt, they won't get false positives.
|
||||||
|
|
||||||
Additional Note: Do not use the getopt_long library function and do not try to
|
For more info and examples, examine getopt32.c, tar.c, wget.c etc.
|
||||||
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.
|
|
||||||
|
Loading…
Reference in New Issue
Block a user