Department of Mathematics

Math 300: Mathematical Computing

Python Trade-offs

In Python as in every programming language one must constantly weigh many considerations in choosing how to write code. Is speed worth sacrificing everything else for? Should we sacrifice speed for readability? Will this be used enough to write code to handle every possible input? Is the elegant solution so obscure that nobody will understand it? Does that matter?

Here is a list of some of the considerations programmers must make for every line they write. The list is not exhaustive.

This is often the most important consideration in writing code. The whole point of writing a program is to get a computer to do something quickly that would take a human a long time to duplicate.
This is the other side of the speed coin. Surprisingly often a programmer finds a solution to a problem that is fast, but requires a great amount of memory in the computer, whereas a slower solution uses much less memory. Which way one goes depends on the situation.
Again, often the fastest code is harder to understand on first reading than a slower, more conventional method. A good programmer always asks herself whether other people will need to work on her code, or whether she will revisit it herself after a long period of time, and must more or less carefully according to those evaluations. Copious comments can help a great deal here.
Often a programmer must choose between forms of code that are shorter, but more difficult to understand, or slower, or in some other way troublesome. Brevity is worth striving for, but a good programmer always must decide whether the result will hurt other goals.
How easy is it to break your program? For something only you will run, that probably does not matter very much. For something that will be run by paying customers, it is incredibly important, and worth a lot of extra code and effort.
Often one has a choice of writing quick-and-dirty but ugly or slow code, or on the other hand, "doing it right". Sometimes doing it quickly is the way to go, sometimes it is better to take more time writing and save time when you run the code or try to modify it later.

Department of Mathematics, PO Box 643113, Neill Hall 103, Washington State University, Pullman WA 99164-3113, 509-335-3926, Contact Us
Copyright © 1996-2020 Kevin Cooper