CodeSOD: A Tip

David was poking around in some code for a visualization library his team uses. It's a pretty potent tool, with good code quality. While skimming the code, though, David found this mismatched comment and code:

 def get_tip(self): # Returns the position of the seventh point in the path, which is the tip. if config["renderer"] == "opengl": return self.points[34] return self.points[28] # = 7*4

Now, I'm going to set aside the issues of stringly typed fields (at least use a constant or an enum), or magic numbers (again, the constant). What I want to highlight is what David saw: neither 34 nor 28 are seven. It's inaccurate and misleading to refer to either of those as the seventh point in the path. If nothing else, it's confusing. But I don't think it's wrong, or at least, the wrong-ness isn't actually in this code.

Without broader context, I don't know how paths get represented in this code. But what I can see is that, in the OpenGL branch, 34 is actually the 35th element in a zero-based array. 35 is divisible by 7, so it's actually reasonable to believe that the entire path is constructed out of segments of 5 points and the seventh group represents the tip. We can make a similar assumption about 28- which while it's actually the 29th entry, we can imagine a world where we break the path up into groups of four, and for some reason the first point needs to have special meaning. A lot of graphics libraries require the first point in a curved path to be a non-curved vertex, for example, so if this path represents a curve, perhaps the code simply repeats the first point in a curved/non-curved form.

All of that would be useful information to see in a comment. It still leaves us with an extra puzzle: why is the tip the seventh point? Is that just their lucky number?

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!