It's better to write your code so that it's easy for a later person to understand it while reading.<p>To that end, use a greater-than sign if reading the code makes more sense that way.<p>E.g. if the method name is `findAllUsersOverAge18()` then it'd be more sensible to have a check such as:
`if (userAge > 18)`
than to have a check for
`if (18 < userAge)`<p>Both statements are technically correct, but the one makes a huge difference in terms of reading it and understanding it, without a Q/A: "Why is this conditional turned around?" "Well, Steve is opposed to ever using greater-than signs so we have to invert all our logic".<p>I also can't help but pointing out- except for certain conventions such as loop iterator variables, it's a much worse programming practice to use non-descriptive, single variable names, such as `x`.
This post is basically saying "the simpler way is what I think is the simpler way", while in reality everyone see a way simpler then other.<p>Since it doesn't hurt the performance there's no need to advice a way over another, the first way that come up on your head is the simpler for you. Go ahead and finish your project fast mate.
Have you ever in real life hear someone say "If 80kg is less than your weight, then you are overweight."<p>Probably not. We say: "If your weight is more than 80kg then you are overweight."<p>When talking we are used to first mention "x", and <i>after</i> that the numerical value we compare it to. No matter if it's less than or larger than what we want to compare it to.<p>If you swap these around, then whoever listens to you - or reads your code - will take a few seconds longer to understand what you mean.
I spotted the incorrect one instantly. Why? Because there are two good ways to write this correctly, and he chose to not use one, and to use the other incorrectly in in his example.<p>5 < x && x < 10<p>10 > x && x > 5<p>Both seem equally readable to me.<p>His argument also seems predicated on the assumption that numbers are always increasing.<p>If x > 10 relax() else countdown(x) // easier to read "if timer is greater than 10, relax, otherwise, countdown"<p>If 10 < x relax() else countdown(x) // harder to read "if 10 is less than timer, relax, otherwise, countdown"
I do exactly this in my own code, for one-sided bounds like "if (0 <= x)" as well as for two-sided bounds like "if (0 <= i && i < length)".<p>But when collaborating with other programmers, I follow the majority style. There are lots of programmers who prefer to write comparisons with the varying item on the left and the constant item on the right, and "varying item is on the left" is just as valuable a hint to them as "lower item is on the left (if expression is true)" is to me.<p>So I wouldn't elevate a personal stylistic preference to a rule: this will lead to pointless arguments. Writing code that's clear to all the programmers on a project should be the goal.
I can see the utility for intervals, but for simple checks I think clarity of intent trumps all. Sometimes if foo.value > bar makes more sense. THis is especially true when foo is the subject of the method.<p>Someone already submitted a PR to the Ruby style guide for this, and I can't express how strongly I disagree. <a href="https://github.com/bbatsov/ruby-style-guide/pull/546" rel="nofollow">https://github.com/bbatsov/ruby-style-guide/pull/546</a>
For the range case, languages like Python got it right because the statement "1 < x < 5" means exactly what it would seem to mean.<p>For other languages I’m not sure it matters for inequalities.<p>For equality though, I always use the form "if (constant == x)" as opposed to "if (x == constant)" because in C it <i>guarantees</i> that the compiler will trip over an accidental-assignment typo. That is, "if (constant = x)" is a compilation error but "if (x = constant)" might be missed.
I picked up the "always use the less-than sign when you're comparing" rule of thumb from something written by Bjarne Stroustrup, though I can't find an online reference to cite. I don't always do it for single comparisons, but I do whenever there are multiple ones such as checking for whether a value is in a certain range.
Except then you start using floating-point and then the transformations do not work anymore.<p>> 1 < nan<p>=> false<p>> nan > 1<p>=> false