[Tutor] [OT] Best Practices for Scientific Computing

Joel Goldstick joel.goldstick at gmail.com
Tue Dec 30 00:57:01 CET 2014


On Mon, Dec 29, 2014 at 6:50 PM, Patti Scott <
pscott_74 at yahoo.com.dmarc.invalid> wrote:

> Could someone clarify "Modularize code rather than copying and pasting?"
>
> thanks
>

Sure --

When you have nearly identical or identical pieces of code, make functions
rather than cut and paste the same code.  Call the function from various
places. It makes it easier to bug fix later

> --------------------------------------------
> On Fri, 11/14/14, Albert-Jan Roskam <fomcl at yahoo.com.dmarc.invalid> wrote:
>
>  Subject: [Tutor] [OT] Best Practices for Scientific Computing
>  To: "Python Mailing List" <tutor at python.org>
>  Date: Friday, November 14, 2014, 12:19 PM
>
>  Hi,
>
>  I thought this might be worth sharing, especially on a
>  windy, rainy Friday evnening:
> http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745
>
>
>  Here are the best practices mentioned in the article:
>
>  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.
>  Make names consistent, distinctive, and meaningful.
>  Make code style and formatting consistent.
>  Let the computer do the work.
>  Make the computer repeat tasks.
>  Save recent commands in a file for re-use.
>  Use a build tool to automate workflows.
>  Make incremental changes.
>  Work in small steps with frequent feedback and course
>  correction.
>  Use a version control system.
>  Put everything that has been created manually in version
>  control.
>  Don't repeat yourself (or others).
>  Every piece of data must have a single authoritative
>  representation in the system.
>  Modularize code rather than copying and pasting.
>  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 design and purpose, not mechanics.
>  Document interfaces and reasons, not implementations.
>  Refactor code in preference to explaining how it works.
>  Embed the documentation for a piece of software in that
>  software.
>  Collaborate.
>  Use pre-merge code reviews.
>  Use pair programming when bringing someone new up to speed
>  and when tackling particularly tricky problems.
>  Use an issue tracking tool.
>
>
>  Have a great weekend!
>
>
>  Regards,
>
>  Albert-Jan
>
>
>
>
>
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  All right, but apart from the sanitation, the medicine,
>  education, wine, public order, irrigation, roads, a
>
>  fresh water system, and public health, what have the Romans
>  ever done for us?
>
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  _______________________________________________
>  Tutor maillist  -  Tutor at python.org
>  To unsubscribe or change subscription options:
>  https://mail.python.org/mailman/listinfo/tutor
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>



-- 
Joel Goldstick
http://joelgoldstick.com


More information about the Tutor mailing list