mirror of
https://github.com/sheumann/hush.git
synced 2024-07-11 19:29:36 +00:00
Added a section to describe how to convert variables to K&R style using the
mk2knr.pl script. Also some minor cleanups.
This commit is contained in:
parent
bac75ac2d5
commit
7ddaf7caae
@ -130,9 +130,9 @@ between it and the opening control block statement. Examples:
|
|||||||
Spacing around Parentheses
|
Spacing around Parentheses
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
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
|
||||||
function names and the left paren that starts it's parameter list (whether it
|
and the left paren that starts it's parameter list (whether it is being
|
||||||
is being declared or called). Examples:
|
declared or called). Examples:
|
||||||
|
|
||||||
Don't do this:
|
Don't do this:
|
||||||
|
|
||||||
@ -200,7 +200,6 @@ block. Example:
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Variable and Function Names
|
Variable and Function Names
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
@ -225,28 +224,55 @@ because it looks like whitespace; using lower-case is easy on the eyes.
|
|||||||
|
|
||||||
Exceptions:
|
Exceptions:
|
||||||
|
|
||||||
- Enums, macros, and constant variables should all be in upper-case with
|
- Enums, macros, and constant variables are occasionally written in all
|
||||||
words optionally seperatedy by underscores (i.e. FIFOTYPE, ISBLKDEV()).
|
upper-case with words optionally seperatedy by underscores (i.e. FIFOTYPE,
|
||||||
|
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
|
||||||
variable that is a pointer to 'var'.
|
variable that is a pointer to 'var'.
|
||||||
|
|
||||||
Note: The Busybox codebase is very much a mixture of code gathered from a
|
|
||||||
variety of sources. This explains why the current codebase contains such a
|
|
||||||
hodge-podge of different naming styles (Java, Pascal, K&R, just-plain-weird,
|
|
||||||
etc.). The K&R guideline explained above should therefore be used on new files
|
|
||||||
that are added to the repository. Furthermore, the maintainer of an existing
|
|
||||||
file that uses alternate naming conventions should -- at his own convenience
|
|
||||||
-- convert those names over to K&R style; converting variable names is a very
|
|
||||||
low priority task. Perhaps in the future we will include some magical Perl
|
|
||||||
script that can go through and convert variable names, left as an exercise for
|
|
||||||
the reader for now.
|
|
||||||
|
|
||||||
For the time being, if you want to do a search-and-replace of a variable name
|
Converting to K&R
|
||||||
in different files, do the following in the busybox directory:
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The Busybox codebase is very much a mixture of code gathered from a variety of
|
||||||
|
sources. This explains why the current codebase contains such a hodge-podge of
|
||||||
|
different naming styles (Java, Pascal, K&R, just-plain-weird, etc.). The K&R
|
||||||
|
guideline explained above should therefore be used on new files that are added
|
||||||
|
to the repository. Furthermore, the maintainer of an existing file that uses
|
||||||
|
alternate naming conventions should, at his own convenience, convert those
|
||||||
|
names over to K&R style. Converting variable names is a very low priority
|
||||||
|
task.
|
||||||
|
|
||||||
|
If you want to do a search-and-replace of a single variable name in different
|
||||||
|
files, you can do the following in the busybox directory:
|
||||||
|
|
||||||
$ perl -pi -e 's/\bOldVar\b/new_var/g' *.[ch]
|
$ perl -pi -e 's/\bOldVar\b/new_var/g' *.[ch]
|
||||||
|
|
||||||
|
If you want to convert all the non-K&R vars in your file all at once, follow
|
||||||
|
these steps:
|
||||||
|
|
||||||
|
- In the busybox directory type 'scripts/mk2knr.pl files-to-convert'. This
|
||||||
|
does not do the actual conversion, rather, it generates a script called
|
||||||
|
'convertme.pl' that shows what will be converted, giving you a chance to
|
||||||
|
review the changes beforehand.
|
||||||
|
|
||||||
|
- Review the 'convertme.pl' script that gets generated in the busybox
|
||||||
|
directory and remove / edit any of the substitutions in there. Please
|
||||||
|
especially check for false positives (strings that should not be
|
||||||
|
converted).
|
||||||
|
|
||||||
|
- Type './convertme.pl same-files-as-before' to perform the actual
|
||||||
|
conversion.
|
||||||
|
|
||||||
|
- Compile and see if everything still works.
|
||||||
|
|
||||||
|
Please be aware of changes that have cascading effects into other files. For
|
||||||
|
example, if you're changing the name of something in, say utility.c, you
|
||||||
|
should probably run 'scripts/mk2knr.pl utility.c' at first, but when you run
|
||||||
|
the 'convertme.pl' script you should run it on _all_ files like so:
|
||||||
|
'./convertme.pl *.[ch]'.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Avoid The Preprocessor
|
Avoid The Preprocessor
|
||||||
@ -299,17 +325,18 @@ Use 'static inline' instead of a macro.
|
|||||||
}
|
}
|
||||||
|
|
||||||
Static inline functions are greatly preferred over macros. They provide type
|
Static inline functions are greatly preferred over macros. They provide type
|
||||||
safety, have no length limitations, no formatting limitations, and under gcc
|
safety, have no length limitations, no formatting limitations, have an actual
|
||||||
they are as cheap as macros. Besides, really long macros with backslashes at
|
return value, and under gcc they are as cheap as macros. Besides, really long
|
||||||
the end of each line are ugly as sin.
|
macros with backslashes at the end of each line are ugly as sin.
|
||||||
|
|
||||||
|
|
||||||
The Folly of #ifdef
|
The Folly of #ifdef
|
||||||
~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Code cluttered with ifdefs is difficult to read and maintain. Don't do it.
|
Code cluttered with ifdefs is difficult to read and maintain. Don't do it.
|
||||||
Instead, put your ifdefs in a header, and conditionally define 'static inline'
|
Instead, put your ifdefs at the top of your .c file (or in a header), and
|
||||||
functions, (or *maybe* macros), which are used in the code.
|
conditionally define 'static inline' functions, (or *maybe* macros), which are
|
||||||
|
used in the code.
|
||||||
|
|
||||||
Don't do this:
|
Don't do this:
|
||||||
|
|
||||||
@ -480,7 +507,8 @@ When in doubt about the proper behavior of a Busybox program (output,
|
|||||||
formatting, options, etc.), model it after the equivalent GNU program.
|
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
|
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
|
matter what the POSIX standard says or doesn't say, just model Busybox
|
||||||
programs after their GNU counterparts and nobody has to get hurt.
|
programs after their GNU counterparts and it will make life easier on (nearly)
|
||||||
|
everyone.
|
||||||
|
|
||||||
The only time we deviate from emulating the GNU behavior is when:
|
The only time we deviate from emulating the GNU behavior is when:
|
||||||
|
|
||||||
@ -585,15 +613,13 @@ one comment) before the block, rather than commenting each and every line.
|
|||||||
There is an optimal ammount of commenting that a program can have; you can
|
There is an optimal ammount of commenting that a program can have; you can
|
||||||
comment too much as well as too little.
|
comment too much as well as too little.
|
||||||
|
|
||||||
A picture is really worth a thousand words here, so here is an example that
|
A picture is really worth a thousand words here, the following example
|
||||||
illustrates emphasizing logical blocks:
|
illustrates how to emphasize logical blocks:
|
||||||
|
|
||||||
while (line = get_line_from_file(fp)) {
|
while (line = get_line_from_file(fp)) {
|
||||||
|
|
||||||
/* eat the newline, if any */
|
/* eat the newline, if any */
|
||||||
if (line[strlen(line)-1] == '\n') {
|
chomp(line);
|
||||||
line[strlen(line)-1] = '\0';
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ignore blank lines */
|
/* ignore blank lines */
|
||||||
if (strlen(file_to_act_on) == 0) {
|
if (strlen(file_to_act_on) == 0) {
|
||||||
@ -650,4 +676,5 @@ use getopt, they won't get false positives.
|
|||||||
|
|
||||||
Additional Note: Do not use the getopt_long library function and do not try to
|
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
|
hand-roll your own long option parsing. Busybox applets should only support
|
||||||
short options, plus explanations and examples in usage.h.
|
short options. Explanations and examples of the short options should be
|
||||||
|
documented in usage.h.
|
||||||
|
Loading…
Reference in New Issue
Block a user