Re: [Tutor] [OT] Best Practices for Scientific Computing
Could someone clarify "Modularize code rather than copying and pasting?" thanks On Fri, 11/14/14, Albert-Jan Roskam wrote: Subject: [Tutor] [OT] Best Practices for Scientific Computing To: "Python Mailing List" 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@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Best Practices for Scientific Computing
On Mon, Dec 29, 2014 at 6:50 PM, Patti Scott < pscott...@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 wrote: > > Subject: [Tutor] [OT] Best Practices for Scientific Computing > To: "Python Mailing List" > 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@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Joel Goldstick http://joelgoldstick.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Best Practices for Scientific Computing
> 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
We can make this more concrete.
Let's say that we are writing a program to do all kinds of dice rolls.
(I've been reading the 5th edition D&D Basic Rules lately, so that's
been on my mind. :P) Say that we want to roll two 6-sided dice and
print out the result of summing both dice rolls.
We might imagine a program like this:
###
import random
dice1 = random.randint(1, 6)
dice2 = random.randint(1, 6)
print("2d6: %d" % (dice1 + dice2))
###
Later, we might want another similar program that rolls four dice and
adds their result. Well, that's easy enough: we can just copy and
paste.
#
import random
dice1 = random.randint(1, 6)
dice2 = random.randint(1, 6)
dice3 = random.randint(1, 6)
dice4 = random.randint(1, 6)
print("4d6: %d" % (dice1 + dice2 + dice3 + dice4))
#
Notice, though, that we needed to be a bit careful: we could just as
easily mis-typed something:
#
import random
dice1 = random.randint(1, 6)
dice2 = random.randint(1, 6)
dice3 = random.randint(1, 6)
dice4 = random.randint(1, 6)
print("4d6: %d" % (dice1 + dice2 + dice3 + dice3))
#
Whooops.
This is a contrived error, but several of the interesting bugs in
real-world code originate from errors during copy-and-paste. We might
also say that this code isn't that flexible because a "minor" change
in the requirements (let's roll roll seven dice instead!) should be
reflected as a minor change in the code, and at the moment, it isn't:
we can see that we have to make multiple changes.
So let's fix that. We can do so by generalizing the program, so that
it can handle a multitude of dice roles in a general way. We can
design a function to do this. Let's write a function, 'throwDice',
that takes a number of dice we want to throw, and returns their sum.
#
import random
def throwDice(n):
"""Returns the sum of n d6 dice."""
sum = 0
for i in range(n):
sum += random.randint(1, 6)
return sum
#
Once we have this function, now we can throw all sorts of dice, like:
print("2d6: %d" % throwDice(2))
or
print("4d6: %d" % throwDice(4))
Heck, we can start throwing dice like crazy:
#
for i in [1, 2, 3, 4, 5]:
print("%dd6: %d" % (i, throwDice(i)))
#
(Visit http://repl.it/7Ix to see and run this program in your browser.)
This is what it means to use functions to avoid copy-and-paste: if we
find ourselves extending our program to do something more by copying
and pasting, where it starts to feel repetitive, then we should stop
and pause. We might be able to generalize what we're doing as a
reusable function instead. And then the repetition won't be in the
physical flow of our code, but rather that repetition will show up as
separate uses of that general function.
If you have more questions, please feel free to ask.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
