Monday, 21 February 2011

More on bad astro code

Along with my own rant, a large portion of the blogosphere picked up on two articles in Nature regarding the state of scientific programming. Just before Christmas, this article turned up on arXiv. I mentioned it in a comment on AstroCompute and it was promoted into a post there.

The basic content agrees on what everyone seems to appreciate. The article gives a broader range of code (including databases and visualization tools) but all the ideas are the same. In fact, their list of common "features" in astronomy codes (Section 2.1) is almost a checklist for how bad said code can be. Compare your favourite code against this:
  • the code is written in Fortran (bonus if it's earlier than Fortran 77);
  • the code includes frequent GOTO statements;
  • compilation instructions are through a terminal script rather than a Makefile (or other standard builder);
  • in release form, code is non-portable;
  • no variable naming convention is adopted;
  • filenames and paths are hardcoded; or
  • standard algorithms (like matrix inversion, list sorting) are re-invented.
STARS doesn't fare too well. I'll give it the benefit of the doubt on portability and it does use a Makefile. That leaves a score of 5/7. We haven't even started on documentation yet...

How does your code compare? What else could be added to the scorecard?

No comments:

Post a Comment