| I'm under the impression that the wording of the blog post is really the "offending" part here. I understand why danShumway would read it as some part of a style guide (since it's worded in a very absolute way); and there, I'd also perceive it as a waste of effort and paper. And yes, adding something to a style guide should include you consulting your teammates, which also ideally shouldn't be on a one-on-one basis. If you do that, you instantly create one of those "I thought we all agreed that..." situations because of unclear communication. > Though in reality it will probably only come up 1-2 times per year That would be my guess from personal experience, too. In addition to that, those range checks would usually be error checks, in which case two other cases can crop up: a) It's better to check them separately anyway (as part of the much more important "fail fast" rule). This way, you can produce two different error messages which is way more useful if you really have to deal with the case: if (x < 0) throw ArgumentOutOfRangeException("x cannot be negative","x");
if (x > y) throw ArgumentOutOfRangeException("x cannot be greater than y","x");
...or some functional `Either`-equivalent. And even if you just return a special value (0, maybe?) this style wouldn't be too bad.b) You're checking within a unit test, where using some assert-function basically makes the decision for you. Asserts usually log an error message on failure, which is important to be readable and depends on the order of the arguments. Thus, this won't be a real issue as much as you even encounter a range check. And that frequency just doesn't warrant the time effort to set in stone some arcane rule that half your team wouldn't remember anyway, since it only applies once a year at maximum. On a personal note: My team recently went over our original style guide, which sadly was neglected for quite a while before I even joined it. I can tell you from personal experience that people are willing to define the most arcane rules you can imagine. We've hat people arguing for things they (as a single person) seem to have adopted two decades ago, are purely subjective (no objective upside whatsoever, as opposed to this one) and go against any established style guide in the programming language we use, which means that our style would always clash with third-party code in some really obscure way. |
I wonder if the purpose isn't often to at any price avoid discussion and disagreement. I can see how a style guide is preferable to firing the people that are impossible to talk to, but that would be much healthier for the team.