[BusyBox] I like the style guide

[Larry Doolittle]

I read the Busybox style guide for the first time.
Amazingly enough, I agree with _everything_ in it.
Well, except for the default tab setting (I use 8),
but (as the guide says) that doesn't matter!

I attach spelling fixes.  It represents little more
than a trip through ispell(1). 

    - Larry
-------------- next part --------------
--- style-guide.txt.bak	Mon Aug 21 17:20:21 2000
+++ style-guide.txt	Fri Nov 17 12:48:11 2000
@@ -25,7 +25,7 @@
  - commented GPL boilerplate
  - commented description of program
  - #includes and #defines
- - const and globals variables
+ - const and global variables
  - function declarations (if necessary)
  - function implementations
 
@@ -37,7 +37,7 @@
 up front.
 
 
-Tabs vs Spaces in Line Indentation
+Tabs vs. Spaces in Line Indentation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The preference in Busybox is to indent lines with tabs. Do not indent lines
@@ -56,7 +56,7 @@
 
 Furthermore, The preference is that tabs be set to display at four spaces
 wide, but the beauty of using only tabs (and not spaces) at the beginning of
-lines is that you can set your editor to display tabs at *watever* number of
+lines is that you can set your editor to display tabs at *whatever* number of
 spaces is desired and the code will still look fine.
 
 
@@ -76,7 +76,7 @@
 	While it extends the line a bit longer, the spaced version is more
 	readable. An allowable exception to this rule is the situation where
 	excluding the spacing makes it more obvious that we are dealing with a
-	single term (even if it is a compund term) such as:
+	single term (even if it is a compound term) such as:
 
 		if (str[idx] == '/' && str[idx-1] != '\\')
 
@@ -89,9 +89,9 @@
 ~~~~~~~~~~~~~~~
 
 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
+next line with no spacing before it. However, if a bracket 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:
+between it and the opening control block statement. Examples:
 
 	Don't do this:
 
@@ -128,11 +128,11 @@
 		baz = my_func(1, 2);
 
 
-Cuddled Elses
+Cuddled Else's
 ~~~~~~~~~~~~~
 
-Also, please "cuddle" your else statments by putting the else keyword on the
-same line after the right bracket that closes an 'if' statment.
+Also, please "cuddle" your else statements by putting the else keyword on the
+same line after the right bracket that closes an 'if' statement.
 
 	Don't do this:
 
@@ -156,7 +156,7 @@
 ---------------------------
 
 Use the K&R style with names in all lower-case and underscores occasionally
-used to seperate words (e.g. "variable_name" and "numchars" are both
+used to separate words (e.g., "variable_name" and "numchars" are both
 acceptable). Using underscores makes variable and function names more readable
 because it looks like whitespace; using lower-case is easy on the eyes.
 
@@ -168,7 +168,7 @@
 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 files--left as an exersize to the
+script that can go through and convert files--left as an exercise to the
 reader.
 
 
@@ -177,14 +177,14 @@
 
 The following are simple coding guidelines that should be followed:
 
- - When in doubt about the propper behavior of a busybox program (output,
+ - When in doubt about the proper 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.
+   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
+   instead. This makes the compiler do type checking for you (rather than
    relying on the more error-prone preprocessor) and it makes debugging
    programs much easier since the value of the variable can be easily queried.
 
@@ -192,7 +192,7 @@
    the file. Instead, declare it inside the function body.
 
  - Inside applet files, all functions should be declared static so as to keep
-   the global namespace clean. The only exception to this rule is the
+   the global name space clean. The only exception to this rule is the
    "applet_main" function which must be declared extern.
 
  - If you write a function that performs a task that could be useful outside