A problem I often see in software engineering advice is ambiguity about how a rule is meant to be applied. I think of it like a 2D continuum. On one axis is ho

A problem I often see in software engineering advice is ambiguity about how a rule is meant to be applied. I think of it like a 2D continuum. On one axis is how mechanical the rule is. One end is rules like the one in this article where even a simple automated syntactic analysis could enforce the rule. The other end is rules around high level principles that require taste and judgement to apply like the principle of least astonishment (What is "astonishment"? Whose? How is it compared?), single responsibility (What is a "responsibility"? What does it mean to uphold it?). But there is a second axis too which is how literally the guideline is meant to be applied. People often assume that the more mechanical a rule is, the more mechanical you should be in applying it, but that's not the case. It's reasonable to have simple mechanical rules that have plenty of exceptions and require some judgement to know when to ignore them. Likewise, there are vague high level principles that should almost never be violated. When someone assumes that a mechanical rule should be applied blindly, they call it "dogma", but a more charitable interpretation is that the author expects the reader to not follow the rule blindly and understand that there are reasonable exceptions. Mechanical rules can be useful, but mechanical rule-followers less so.