|
|
|
|
|
|
by BurningFrog
2751 days ago
|
|
|
In some organizations, I'm sure. Where I work, it might possibly come up in a code review, or be discussed when pair programming. I think most people would agree when pointed out that this rule makes sense. Even when I've worked under fairly strict coding rules, no one has tried to tell me how to do this particular thing yet, so I was thinking I would start practicing this on Monday, since it seems reasonable. Though in reality it will probably only come up 1-2 times per year, and most of my coding is in Python these days, so what am I even talking about... |
|
|
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:
...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.