Continuing with my series of answers to questions that were asked during my webcast on Tuesday:

The copy-paste checker example you showed was interesting. I’ve heard that NASA disallows copy-pasting in code because it is so error prone; is this true?



For readers who did not attend the talk: my favourite Coverity checker looks for code where you cut some code from one place, pasted it in another, and then made a series of almost but not quite consistent edits. An example taken from real world code is:

if (!bounds.Contains(p)) { PointF newCenterPt = Utility.GetRectangleCenter(bounds); if (p.X > bounds.Right || p.Y < bounds.Left) newCenterPt.X = p.X; if (p.Y > bounds.Bottom || p.Y < bounds.Top) newCenterPt.Y = p.Y; }

If I hadn’t told you that there was such a defect in this code, it might be quite difficult to spot. The “Y” code was written first, and then copy-pasted to the “X” code above it. “Bottom” was updated to “Right” and “Top” was updated to “Left”, and three of the four “Y”s were updated to “X”; the remaining “Y” makes the logic wrong.

This defect frequently comes up in the context shown, that is, code which is doing something to a rectangle. However, I’ve also seen this defect where instead of “X” and “Y” and so on, it was “offense”, “defense”, “dodge_to_left”, “throw_to_right”, and so on, in the context of an AI for a sportsball game; the effect of the defect was that sometimes a defending player would take the action that was sensible for an offensive player. The worst copy-paste error I’ve seen so far was in financial code that mixed up exchange rates, at one point getting the exchange rate between dollars and euros backwards. That was a potentially extraordinarily costly defect.

Anyway, to return to the actual question, I do not know if NASA has this rule, but it is a pretty good rule! Any current or former NASA programmers reading this, please post a comment.

In lieu of an answer I’ll tell you two related anecdotes.

Anecdote #1: The very first defect I ever discovered was a copy-paste defect. My sixth-grade teacher had some educational software for the Commodore PET computers we had in my elementary school, and the math-drill software was sometimes producing multiple choice questions with all wrong answers. He asked me to see if I could figure out why, knowing that I was interested in learning how software worked. I did not deduce the defect logically; rather, I noticed that there were two lines of code side by side that were identical, except that much like the code above, one of them had every X changed to a Y except the last one. I had no idea what the line of code did, but I changed the last X to a Y, ran the code again, and the bug went away, so I declared victory. Of course ten-year-old Eric was a “cargo cult programmer”, making changes by gut feel without understanding why they were correct. Today I would take a more logically well-founded approach to fixing such a defect, but the technique is still a pretty good one for defect identification, as we’ve seen here.

Anecdote #2: The Jet Propulsion Laboratory, which makes the software and hardware for many NASA probes such as the rover running around on Mars right now, is a Coverity customer. JPL is very hard core about their usage of the static analyzer. For instance, they have fixed every defect found by static analysis regardless of its age; many customers quite reasonably prioritize recently introduced defects over long-existing defects on the assumption that the ones that have been in the product for years are less likely to be deadly, since they’ve not killed anyone yet.

But the bit I find most interesting is how they handle false positives. A “false positive” is a defect that is reported, but the analysis is wrong; there really is no defect in the code. Most customers mark false positives as such in the triage tool, which then suppresses reporting that particular defect at that particular location again when it is found again on the next analysis. JPL doesn’t do that. Rather if static analysis finds a false positive then they change the code such that its correctness is maintained but the false positive defect is no longer reported. The reasoning for this is: if the code is so unclear that it is fooling the static analyzer, then it is also sufficiently unclear to fool the humans reading the code and making decisions based on its deduced semantics! This is a very “meta” way to use a static analyzer, and I love it.