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.
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.
Don't rely on proprietary languages, libraries, or other code.
In the open-source community this is considered rude. Open-source
developers don't trust what they can't see the source code of.
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.
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.
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.
For Python projects, the
PyChecker
program can be a useful check. It's not out of beta yet, but nevertheless
often catches nontrivial errors.
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.)
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.