minow@decvax.UUCP (Martin Minow) (11/16/85)
Here are a few more guidelines (from experience -- most of my stuff has to
run on two different architectures).
22. Actually port your code to at least two different architectures,
operating systems, and compilers.
23. Run your code through lint wherever possible.
24. Develop a consistant method of conditionally compiling machine,
system, and compiler-dependent segments. Use #if, rather than
#ifdef to protect yourself against typo's (assuming your preprocessor
warns you of undefined symbols in #if's).
25. Distribute a fairly large, useful, tool through mod.sources: you
will soon discover that you weren't paranoid enough.
26. Run your code through lint. (Oh, for a public-domain lint!)
Martin Minow
decvax!minowgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/19/85)
> 24. Develop a consistant method of conditionally compiling machine, > system, and compiler-dependent segments. Use #if, rather than > #ifdef to protect yourself against typo's (assuming your preprocessor > warns you of undefined symbols in #if's). I don't recommend this practice. The vast majority of properly- written C source code should be independent of target architecture, and you are much better off isolating system dependencies in separate modules (read, files) than sprinkling them throughout your code. No matter how many #ifdefs you use, the minute your code written like that moves to a new architecture you have a tedious job ahead adding zillions of additional cases throughout a mountain of source code. There is much less work if the actual applications do not need to be modified due to all the system dependencies being contained in a handful of known files.