Best Practices for Scientific Computing

linchpin

“Best Practice” is defined as “a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.” Think of a best practice as a way that generally works better than other ways. This paper helps describe the best practice around writing programs. This outline (written by Jonathan Callahan) helps summarize the document, but you should read the entire six page document for yourself.

  1. Write programs for people, not computers.
    1. a program should not require its readers to hold more than a handful of facts in memory at once
    2. names should be consistent, distinctive and meaningful
    3. code style and formatting should be consistent
    4. all aspects of software development should be broken down into tasks roughly an hour long
  2. Automate repetitive tasks.
    1. rely on the computer to repeat tasks
    2. save recent commands in a file for re-use
    3. use a build tool to automate scientific workflows
  3. Use the computer to record history.
    1. software tools should be  used to track computational work automatically
  4. Make incremental changes.
    1. work in small steps with frequent feedback and course correction
  5. Use version control.
    1. use a version control system
    2. everything that has been created manually should be put in version control
  6. Don’t repeat yourself (or others).
    1. every piece of data must have a single authoritative representation in the system
    2. code should be modularized rather than copied and pasted
    3. re-use code instead of rewriting it
  7. Plan for mistakes.
    1. add assertions to programs to check their operation
    2. use an off-the-shelf unit testing library
    3. use all available oracles when testing programs
    4. turn bugs into test cases
    5. use a symbolic debugger
  8. Optimize software only after it works correctly.
    1. use a profiler to identify bottlenecks
    2. write code in the highest-level language possible
  9. Document design and purpose, not mechanics.
    1. document interfaces and reasons, not implementations
    2. refactor code instead of explaining how it works
    3. embed the documentation for a piece of software in that software
  10. Collaborate.
    1. use pre-merge code reviews
    2. use pair programming when bringing someone new up to speed and when tackling particularly tricky problems

This method of seeking out and using a best practice will help you not re-invent the wheel of programming, but do those things that makes you a better professional.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s