Using Fortran's implicit none keyword is a
Good Idea. The tiny amount of typing time you save by
relying on Fortran's automatic declaration of variables,
is more than likely wiped out by the debugging time spent
clearing up silly problems implicit none
would have avoided from the beginning.
Similarly, in C, use ANSI-C rather than older `K&R'
C, and use prototypes religiously. That is, if you have a
module myfuncs.c, then create a header file
myfuncs.h containing the prototypes of the
functions within it, and include it (#include
"myfuncs.h") both in any modules which use those
functions and inside myfuncs.c as well. That
way, if you change the interface to any functions in that
module, the compiler will prompt you to change the calls
to that function everywhere that it is used.
This way, the compiler can help you avoid a whole class of
embarrassingly silly problems.
Make your code portable. Unless you are specifically targetting your code at a particular (supercomputer) processor, or magic parallelizing compiler, you will save yourself time in the long run by not making assumptions about the machine or compiler environment. Especially given the imminent arrival of 64-bit machines, you are probably not doing yourself any favours by, for example, assuming that integers are four bytes. Probably more pertinently, exploiting compiler-specific features might prevent you running your code on some new faster architecture. If you do decide to use some non-portable features, you can make the future porting effort easier by having second or third thoughts about precisely how to use them, and by isolating them into a few subroutines, rather than scattering them throughout your code. It follows that....
Compiler Warnings Are Your Friend. Try compiling your
codes with compiler warnings switched on (with the option
-Wall on GNU compilers, +w2 on
Sun Workshop compilers, and -w0 on Compaqs).
You might be surprised at the number of peculiarities and
non-standard features this exposes, each of which is a
potential portability problem for the future. Don't treat
compiler warnings as irrelvant nagging -- each of them is,
to some extent, an error you have made, which has the
possibility of turning round and biting you later. I
would particularly advise this if you develop using GNU
compilers, as these seem particularly liberal about
standards: gcc in particular seems happy to
take any old nonsense, say `I know what you mean', and
produce code from it -- in my experience it usually
guesses my intentions correctly, but I don't want to rely
on it. You can also adjust the strictness of the C
compiler's conformance to the ANSI-C standard by using
compiler options (Sun: -Xa and
-Xc; DEC: -std1; GNU:
-ansi and -pedantic). Having
said all this, I don't want to overstate the importance of
compiler warnings: the main plank of this advice is to
spend time now to save time and aggravation later, but
this tradeoff is unlikely to be in your favour if you
spend time removing every last anomaly from your code.