Live data from Hacker News

Don't use the greater-than sign in programming (2016)

llewellynfalco.blogspot.com

91–96 of 96 posts

Re: Don't use the greater-than sign in programming (2016)

#91

Earlier quoted context omitted.

Unless you plan to only work on personal projects by yourself, any kind standardization in your codebase will always require some kind of team meeting.

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…

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  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.

Re: Don't use the greater-than sign in programming (2016)

#92
post #76

"Go ahead and find out which one, I'll wait" ... As if it required herculean effort. "which is a stupid option because it implies 10 And I stopped reading.

Eventually, cognitive decline will win the day and I will be confused by simple use of conditional operators. Until then, I'm with you pal.

Re: Don't use the greater-than sign in programming (2016)

#94
post #15
post #2

Ha, I've been using this trick for a while, though I wouldn't go so far as to say "don't use the greater-than-sign." Honestly I just wish languages had a cleaner way to write "x is within this range," e.g. "if x in [2,4)"

SQL has "x between 2 and 4" (for example) which is a lot clearer.

or x not between 2 and 4

Re: Don't use the greater-than sign in programming (2016)

#95

Earlier quoted context omitted.

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…

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.…

Yeah, I'm not at all a fan of detailed style guides, and your last section gives an excellent example of why.

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.

Re: Don't use the greater-than sign in programming (2016)

#96

Earlier quoted context omitted.

Yes, there absolutely is. Because we write so many languages left-to-right, '>' denotes 'greater than'. Perhaps right-to-left written languages have mathematical comparison operators with opposite names.

By convention, math is always left to right regardless of the direction of the script it's in, so presumably the operators do the same.

Yeah, I was intending to refer to a time prior to the establishment of those conventions. Presumably those societies with right-to-left writing had independent mathematics with comparison operators. If they named them, there might be opposite conventions back then.
Post reply on HN