Bad Code

If my task is to help you “speed up code”, then I feel that the first part is to help you maintain it.

This is one of the 10/90 principles of programming: 10% of the time will be spent writing a program; 90% of the time will be spent maintaining it.1

Let’s start by looking at a code fragment. For the sake of argument, assume that it “works,” in the sense that it’s part of a larger program that produces the results that you expect.

Pick the Python version or the C++ version. Can you figure out what, in my opinion, is wrong with this code?2

Listing 4: What’s wrong with this Python code?

# Compute the vector product of the two velocities
i = 10
while j < i+1:
    k = i + 3
    s[j] += k*j
    j += 1

Listing 5: What’s wrong with this C++ code?

// Compute the vector product of the two velocities
int i = 10;
while (j < i+1) {
    int k = i + 3
    s[j] += k*j
    j += 1
}

Hint

In my opinion:

• There are at two execution-speed problems with this code (though they affect the Python version more than the C++ version). There is also a separate speed problem with only the Python code.

• There are also at least two programming-style problems with the above code.

My answers are in the next section.

Is this worth it?

It’s natural to ask this question. We’re all busy. If the code works, why make a fuss about it?

I offer the following in response:

• If code is unclear, it will be harder to maintain. You may feel that’s the next person’s problem. Except that the next person is likely to be you!

  Suppose you’ve have a program that performs a cluster-finding algorithm. It works, but it’s quickly and sloppily written. You save it and move on to your next project.

  Six months later, your team comes back to you: “You’re the cluster-finding expert. Update your code so that it accommodates this revision.” Of course, you’ve forgotten about your old code.3 You look at it now… and realize that five seconds worth of effort back then would have saved you hours or days re-analyzing your old code to figure out what it did.

• Typically, physics groups don’t do code review. But professional programming environments do.

  A “code review” is when a group of programmers looks over your code to see if it’s acceptable to add to a project, in much the same way a physics group will review a paper to see if it’s acceptable for publication. If you find yourself in a programming group, they’re not going to accept your code if has the kinds of flaws I discuss here.

Figure 67: https://xkcd.com/1833/ by Randall Munroe

---

1

The other 10/90 principle is that 10% of the code is responsible for 90% of a program’s execution time. We’ll deal with creating faster code in the next section.

2

One question you might ask is, what does += mean?

I confess to a weakness: I use this syntax so often that, when I was setting up code examples, I hadn’t even noticed that I used this operator until I wrote most of this appendix.

To explain: The following kind of statement is very common in programming:

a = a + b

To make lines of code a bit shorter, and to allow language interpreters or compilers a chance at improving efficiency, both Python and C++ implement a set of operators:

+=, -=, *=, /=, %=

The first one is by far the one I’ve seen most often. The following two statements do the same thing:

a = a + b

a += b

As do these statements:

value = value + offset

value += offset

C++ goes a step further. Since adding (or subtracting) 1 is very common, the language has ++ (and --) operators. The following statements do the same thing:

a = a + 1;

a += 1;

a++;

++a;

There’s a difference between a++ and ++a, but I’ll leave that topic to a more formal C++ course.

Now you know why the language is called C++!

3

I know you think you’ll remember. You won’t. Although arguments from authority are always suspect, please take it from someone who’s been programming for over five decades.