1. 28

  2. 12

    It’s really no more clear. I much prefer putting the constants to the right, as a general rule.

    I expected it to be about using a single comparator in sort algorithms, ect.

    1. 14

      Yeah, I think this is definitely in the realm of one person’s aesthetic sense. I think that, e.g.,

      if (x < MIN_VALUE || x > MAX_VALUE) {
              return (EINVAL);

      … makes a lot of sense, especially when you consider a verbal version: less than the minimum or greater than the maximum allowed value.

      1. 2

        It does. Except that you should get rid of those parens around EINVAL. There is no need for those. :-)

        1. 2

          While that’s technically true in this example, I’ve read and written so much SunOS cstyle code that it looks weird without the parens at this stage.

    2. 9

      Let’s compromise by getting rid of both > and <= so you only have “less than” and “greater than or equal to”

      1. 8

        (< 5 x 10)

        1. 7

          Incorrect rants are the best rants? No, (x < 10 && 5 < x) does not imply 10 < 5.

          I agree that some form of consistency here makes reading such conditions less error prone. I’m partial to using half-open intervals [l,u) and expressing membership as (l <= x && x < u).

          1. 6

            I’ll also note that many generic sort functions (e.g. c++) require only a less-than function to work.

            1. 26

              No. If you get confused by > then you have bigger issues.

              1. 13

                I see the article more as an reminder that consistency in notation can have benefits and can help avoid bugs.

                If you feel confident enough to not follow such advice, feel free. I am pretty sure more than just a couple of bugs I fixed were related to smart people who were confused by logical expressions.

                My counterpoint for that article would be, that such errors should be caught by unit test cases.

                1. 3

                  Totally agree. This is simply a programming literacy issue, and one that can be caught by modern compilers. In the case of his error example, the left hand comparison would be reported as dead code by Cobertura and should also be identified by appropriate unit testing with branch coverage. The tools are available, and some people choose not to use them.

                  1. 3

                    I think you’re unfairly implying that the author is confused by the > sign which is not true. They said that conditionals are confusing, and (paraphrasing) being consistent about conditionals reduces confusion. I think that’s a totally valid statement.

                    1. 0

                      Conditionals aren’t confusing. This is just completely basic stuff. It’s like getting confused over 1 + 2 * 3 or foo(a, bar(b, c)). It’s completely unacceptable to call yourself a programmer if you find this kind of thing difficult. If you do, you’re a very new beginner.

                      1. 2

                        Well once everyone is as smart as you we can use over-complicated conditionals…

                        …until then.

                        1. 1

                          You don’t need to be anywhere near as smart as I am to understand greater-than conditionals.

                          1. 1


                            Again, not what we’re talking about.

                  2. 5

                    For numbers, > looks not so confusing (expect for range comparisons), but for dates and times, I prefer always using <. For some reason, I become confused with “comes after” and “comes before” notions, but if dates are arranged from left to right, it becomes clear.

                    But maybe for people who are native speakers of languages using right-to-left writing, use of < might be even more confusing.

                    1. 3

                      I’m confused and disappointed by the reactionary, defensive comments here. Who’s ranting or yelling? Is the author accusing someone of stupidity if they cannot understand complex comparison expressions?

                      I’m not ashamed to admit we enforce this rule at work. It yields consistency and simplicity that is important for us to cut out unnecessary mental overhead during code review. Across dozens of contributors and hundreds of repositories, it makes a difference. And happily, not one person of our team has rejected the rule out of arrogance that they are “smart enough” to eschew it.

                      I think of it this way: if someone has written a complex boolean expression that is deeply nested and mixes the and/or/not operations arbitrarily, I suggest they apply De Morgan’s laws and simplify the expression into a normal form. It isn’t that I cannot understand a complex, non-normalized expression—I don’t want to have to!

                      That’s all this rule is, a normal form for comparisons.

                      1. 1

                        The linked post contains the sentence

                        This is such a nice way to express numbers I wonder why programming languages allow for the greater than sign ( > ) at all.

                        If this isn’t indicative of a piece that’s more akin to a rant than a reasoned discussion, I don’t know what is.

                        I fully support coding conventions that encourage consistent usage of range operators, but to go from there to actually removing a character from the ASCII set to address what is, in the grand scheme of things, a rather minor issue is pretty extreme.

                        1. 1

                          I don’t see it as lengthy, impassioned, or angry. It meets exactly none of the criteria I would use to qualify ranting. It’s merely controversial.

                      2. 3

                        It’s totally personal, as I can see. Making a rant just to yell to people how to do things (your way) is just silly.

                        For instance, I find putting the variable first easier to read in my head:

                        x > 5 && x < 10

                        as for me that is the subject of the statement. But whatever.

                        1. 2

                          It seems like this is just a “normal form” and the author is arguing this one to be super to the others because it places things in the program text in the same physical orientation as a number line. That seems reasonable.

                          Folks reactions to it in this thread (and the thread from two years ago) seem somewhat out of proportion. The author’s tone isn’t commendable, but neither are the tones of many reactions here on lobsters. Two years ago somebody went as far as to write a satire of this which has a ranty tone, and lead to much ranting on lobsters. /shug

                          1. 1

                            I had posted this story with the description, but the description was removed by pushcx with the reason “Please don’t use the story text for personal comments. Mailed you a copy to post as a comment.” Hereby posted below.

                            @pushcx: I appreciate you mailing me the copy to post as a comment; and I also appreciate that you did not want to post it ‘as me’. But immediately removing the description feels like a very heavy-handed solution to a comment posted in the wrong place. Either converting the description to a comment, or posting a comment saying ‘please post your description as a comment next time’ would communicate the norm (a) more publically, and (b) without making it look like the submitter made a completely different submission. – Having said all that: no need to apologize for or defend how you did it this time, this is after all a trivial matter. Just something to consider next time somebody accidentally misinterprets the ‘Text’ field.

                            I came across this article just now, but I independently discovered the joys of only using <= and < a few years ago, after cleaning up a bit too much code that looked something like this:

                            if days_so_far > max_days:
                            if days_so_far < max_days and days_so_far > (max_days - 7):

                            Merely rewriting that to use <, so that the variables appeared in order of size, was a huge relief:

                            if  (max_days - 7) < days_so_far and days_so_far < max_days and:
                            if max_days < days_so_far:

                            Llewelyn’s article is the first time I’ve seen someone else give this advice – so hooray, I’m not alone!

                            Why I like only using < and <=: when the < marks all point the same way, the numbers and variables always go from small to large, and it makes it easier to mentally move the (a < b) expressions around and place them next to each other and see which conditions cover which bits of the number line. Especially when there are multiple comparisons involved.

                            The only case where I’m still tempted to use the greater-than sign is when it really is just a single comparison.

                            if 2 <= sys.argv still feels like a weird way to say “sys.argv is at least 2”… not that >= or ‘greater or equal than’ is a great way to say ‘at least’.

                            (Previous submission & discussion)

                            Stories with similar links:

                            1. Don't use the greater than sign in programming via pushcx 3 years ago | 31 points | 17 comments