5. Good development practice

Most of these are concerned with ensuring portability, not only across Linuxes but to other Unixes as well. Being portable to other Unixes is not just a worthy form of professionalism and hackerly politeness, it's valuable insurance against future changes in Linux itself.

Finally, other people will try to build your code on non-Linux systems; portability minimizes the number of annoying perplexed email messages you will get.

5.1. Write either pure ANSI C or a portable scripting language

For portability and stability, you should write either in ANSI C or a scripting language that is guaranteed portable because it has just one cross-platform implementation.

Scripting languages that qualify include Python, Perl, Tcl, Emacs Lisp, and PHP. Plain old shell does not qualify; there are too many different implementations with subtle idiosyncracies, and the shell environment is subject to disruption by user customizations such as shell aliases.

Java holds promise as a portable language, but the Linux-available implementations are still scratchy and poorly integrated with Linux. Java is still a bleeding-edge choice, though one likely to become more popular as it matures.

5.2. Follow good C portability practices

If you are writing C, do feel free to use the full ANSI features -- including function prototypes, which will help you spot cross-module inconsistancies. The old-style K&R compilers are history.

On the other hand, do not assume that GCC-specific features such as the `-pipe' option or nested functions are available. These will come around and bite you the second somebody ports to a non-Linux, non-GCC system.

5.3. Use autoconf/automake/autoheader

If you're writing C, use autoconf/automake/autoheader to handle portability issues, do system-configuration probes, and tailor your makefiles. People building from sources today expect to be able to type "configure; make" and get a clean build -- and rightly so.

5.4. Sanity-check your code before release

If you're writing C, test-compile with -Wall and clean up the errors at least once before each release. This catches a surprising number of errors. For real thoroughness, compile with -pedantic as well.

If you're writing Perl, check your code with perl -c (and maybe -T, if applicable). Use perl -w and 'use strict' religiously. (See the Perl documentation for discussion.)

5.5. Sanity-check your documentation and READMEs before release

Run a spell-checker on them. If you look like you can't spell and don't care, people will assume your code is sloppy and careless too.