Reference standards

Don’t in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)

If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can’t write an imitation of it, but do try to organize the imitation along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.

For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in core and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today’s computers makes simpler algorithms adequate.

Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles nulls and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language.

Or turn some parts of the program into independently usable libraries. Or use a simple garbage collector instead of tracking precisely when to free memory, or use a new GNU facility such as obstacks.

Compatibility standards

Utility programs and libraries for GNU should be totally upward compatible with those in Berkeley Unix, with certain exceptions. When a feature is used only by users (not by programs or command files), and it is done poorly in Berkeley Unix, it is good to replace it completely with something totally different and better. (For example, vi is replaced with Emacs.) But it is nice to offer a compatible feature as well. (There is a free vi-clone, so we will offer it.)

Additional useful features not in Berkeley Unix are welcome. Additional programs with no counterpart in Unix may be useful, but our first priority is usually to duplicate what Unix already has.

Formatting standards:

It is important put the open-brace that starts the body of a C function in column zero, and avoid putting any other open-brace or open-parenthesis or open-bracket in column zero. Several tools look for open-braces in column zero to find the beginnings of C functions.
These tools will not work on code not formatted that way. It is also important for function definitions to start the name of the function in column zero. ctags' or etags’ cannot recognize them otherwise. Thus, the proper format is this:

Aside from this, I prefer code formatted like this:

I find it easier to read a program when it has spaces before the open-parentheses and after the commas. Especially after the commas.

Please use formfeed characters to divide the program into pages at logical places (but not within a function). It does not matter just how long the pages are, since they do not have to fit on a printed page.

When you split an expression into multiple lines, split it before an operator, not after one. For example: