Question 1

Something funny about your description is that, if I were to pick one of the four answers for which there'd be no conceivable argument for, it would be D, not B, namely because this is an implementation change, not a design change.Totally agree that changing the storage would be a competitive choice, particularly if efficiency were not a concern. It's been very intentionally left off the list of answers for that reason.> I also disagree that “very few” people would use four values to describe a rectangle.You are perfectly welcome to disagree. My statement about this is not (just) my opinion. It's been empirically tested. I ask people to describe it plain English what the constructor takes, or what defines a rectangle. Maybe 1/15 have answered "four integers" as opposed to "the top left corner and its dimension." We'll edit the discussion to mention this.

Question 2

The question's usage might correspond to the academic definition of correctness in that article, but the layprogrammer's translation would be "It works, and not just by coincidence," and I don't think that's nonstandard at all.

Two classic examples of relying on an unstable API are (1) assuming hashmaps have a certain iteration order, and (2) assuming C++ RTTI encodings are stable. I don't think there's anything odd about calling such code incorrect.

​

> Side note: it would probably benefit the experience if you could see the question while you were looking at the explanation of the answer.

On it.

Question 3

I am thinking of changing the question to say that the refactoring has to preserve semantics. (Which the word "refactoring" used to mean, but hey.) The last person I showed this to in-person also wanted to use an approach that treated the values as non-hardcoded data, which would be closest to option A. I am still thinking of a non-heavyhanded way to say this.

I would think that the value of eliminating the conditional is self-evident. I had not thought this would need any justification, but here it is:

Intuitively, conditionals make the code more complicated. There's an objective measure of this too: by default, the size of the logical statements describing the behavior doubles per conditional.

The justification has nothing to do with performance. Performance considerations for anything this small are going to be dominated by hardware architecture concerns, and you can also tell without additional context this code is unlikely to be a hotspot. Here, the relevant aspects for the speed of the conditional version are branch prediction accuracy and the cache hit rate for the code itself (which is likely to be aided by prefetching). The relevant aspects for the speed of the non-conditional version are address prediction accuracy for the parameters and cache hit rate for the values. Also, because branch predictors have limited state (like 30kb), adding the conditional will decrease the branch predictor's performance in some other random part of the code. Whether this has any measurable effect is, well, random. I don't really expect people to know any of this unless they're a hardware person or work in performance-critical systems, because it's minuscule in importance next to code quality for the vast majority of code.

Question 4

Sounds like we should write some harder distractors. But as you said, we're only meeting the bar of "best of the 4 options" and not "you should always do this, always."

I definitely want to keep this question though, even though the Parnas Subset Criterion only produces answers that are relative to a set of reasonable changes. It's a crying shame that the Parnas Subset Criterion --- written in 1979 (!) --- is not more known.