Astronomy Computing Today offers 10 Best Practices for Scientific Computing, itself a summary of a paper by Wilson et al.: Best Practices for Scientific Computing.
Software is now considered by many as a scientific instrument, and it has assumed the same importance as “telescopes and test tubes”…[however it] is not yet developed, tested and validated with the same care and attention to detail as physical scientific apparatus, and [Wilson et al.] cite a number of examples of how this has caused serious errors in research results, and has led to corrections in published papers and sometimes retractions of papers.
You can read their top ten things to keep in mind as you write code here.
Can you offer any additions to their list? Or share an instance where failure to adhere to these guidelines has led to more work in the end? Let’s hear it in the comments!
My vote for the best easily adopted tip with big payoffs: write shorter functions. Like, really short — 15 lines or less.
Shorter functions are easier to interpret and test. They also force you to break apart complex code blocks into simpler, independent pieces, which get extracted into new functions.
Comments inside code are great hints to pull that code into a new function, gave it a descriptive name, and remove the (now redundant) comment. This applies even if the new function is only 1 line.
For whatever reason, scientific code tends not to follow this strategy as much as it should. I think our instinct is to use functions only to avoid code duplication, instead of as ways to decompose code into its simplest, atomic pieces.
My best advice: take an immersive class in software practice, such as those offered by Software Carpentry (http://software-carpentry.org/). They offer intensive two-day boot camps, held abroad as well as in the U.S: see http://software-carpentry.org/bootcamps/index.html. They are happy to come to your campus and hold a session there.