[IPOL discuss] Best Practices for Scientific Computing

[Nicolas Limare]

http://software-carpentry.org/2012/10/best-practices-for-scientific-computing/

The following pre-print is now available on arXiv:

    Best Practices for Scientific Computing
    D.A. Aruliah, C. Titus Brown, Neil P. Chue Hong, Matt Davis,
    Richard T. Guy, Steven H.D. Haddock, Katy Huff, Ian Mitchell, Mark
    Plumbley, Ben Waugh, Ethan P. White, Greg Wilson, and Paul Wilson.

    Abstract
    Scientists spend an increasing amount of time building and using
    software. However, most scientists are never taught how to do this
    efficiently. As a result, many are unaware of tools and practices
    that would allow them to write more reliable and maintainable code
    with less effort. We describe a set of best practices for
    scientific software development that have solid foundations in
    research and experience, and that improve scientists’ productivity
    and the reliability of their software.

If you’re interested, the key practices recommended are:

* Write programs for people, not computers.
  - A program should not require its readers to hold more than a handful
    of facts in memory at once.
  - Names should be consistent, distinctive, and meaningful.
  - Code style and formatting should be consistent.
  - All aspects of software development should be broken down into tasks
    roughly an hour long.
* Automate repetitive tasks.
  - Rely on the computer to repeat tasks.
  - Save recent commands in a file for re-use.
  - Use a build tool to automate their scientific workflows.
* Use the computer to record history.
  - Software tools should be used to track computational work
    automatically.
* Make incremental changes.
  - Work in small steps with frequent feedback and course correction.
* Use version control.
  - Use a version control system.
  - Everything that has been created manually should be put in version
    control.
* Don’t repeat yourself (or others).
  - Every piece of data must have a single authoritative representation in
    the system.
  - Code should be modularized rather than copied and pasted.
  - Re-use code instead of rewriting it.
* Plan for mistakes.
  - Add assertions to programs to check their operation.
  - Use an off-the-shelf unit testing library.
  - Turn bugs into test cases.
  - Use a symbolic debugger.
* Optimize software only after it works correctly.
  - Use a profiler to identify bottlenecks}.
  - Write code in the highest-level language possible.
* Document the design and purpose of code rather than its mechanics.
  - Document interfaces and reasons, not implementations.
  - Refactor code instead of explaining how it works.
  - Embed the documentation for a piece of software in that software.
* Conduct code reviews.
  - Use code review and pair programming when bringing someone new up to
    speed and when tackling particularly tricky design, coding, and
    debugging problems.
  - Use an issue tracking tool.

-- 
Nicolas LIMARE - CMLA - ENS Cachan         http://limare.perso.math.cnrs.fr/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20121005/8e7f3df3/attachment.pgp>