I really think this is just bikeshedding over style.
If we were optimizing for readability and predictability, we'd standardize on the most commonly used format.
``if (x > 5 && x < 10)``
Putting a rule that variables should always be on the left hand side of a comparison also gives you only 2 ways to write any conditional, so it's just as good as getting rid of ``>``. It also has the advantage of being by far the most widespread way that people already write conditionals, so you don't need to hold a team meeting where you explain to a bunch of grumpy senior programmers why even though they think their coding style is easier to read it actually isn't.
But by far the best option is to not have a meeting at all and to not care about things like this. In the absence of real, tangible data that conditional styles are causing bugs, these kinds of debates are very often a pre-optimization, and pre-optimization should be avoided.
When I put the effort into tracking and ordering the root causes of the majority of bugs in my software (both in personal projects and in large corporate environments) I am often surprised at the results. Very rarely are they consistent with the causes I would have predicted.
That's why I call things like this bikeshedding. In a large organization, it is probably more productive for you to hold another meeting about encapsulation and code reviews than it is for you to start up a Slack discussion about what style people use on their conditionals.
But by far the best option is to not have a meeting at all and to not care about things like this.
Indeed. This article reads like someone who doesn't understand inequalities, and proposes a quite possibly hazardous shortcut to it instead. To not understand such basic maths is baffling (this is primary-school stuff), and I wonder at the state of maths education these days to see adults struggling with these concepts.
I have never in over 3 decades of programming ever had to ask myself the question of how to write conditional expressions --- it's something that comes naturally, and in this specific case I would also write it with the variables on the left.
That said, I've come across code where the variable is always on the right. This often seems to be a throwback for some devs to alleviate the problem of mixing up equality and assignment.
That is, it seems that some people have been taught to use this expression (& stick to it religiously):
if (5 == x) ...
simply so that if they make a mistake and type
if (5 = x) ...
the (C/C++) compiler will reject it. So, these people always write the slightly more awkward case (imho) of:
if (5 < x && 10 > x) ...
but to me it doesn't read as cleanly, because we don't say it that way.
Of course, there's the problem of understanding the meaning of 'between' which can be inclusive of the end points, or exclusive...and you really can't tell from the english. In every case, it needs to be clarified. (eg 'pick a number between 1 and 10'):
> This article reads like someone who doesn't understand inequalities, and proposes a quite possibly hazardous shortcut to it instead.
This is how I usually write inequalities. Have you considered that possibly the author and I understand how they work and would like a consistent way of formatting them to save time while reading them?
I agree that this is trivial. But I also write conditionals the way the author suggests. Mostly because that is the way you'd write it if this was math. You'd say 'For x between 5 and 10' and write '5 < x < 10'.
To be clear, my point is not that a math-centric style is bad. My point is that 95% of the time it doesn't matter.
If you were working with me on a project, unless I had solid evidence that conditional styles were causing bugs, your style might warrant one curious comment on a single code review, but nothing else.
If it became obvious that it was causing bugs, we'd standardize on whatever the majority of people in the office already used, even if that was:
Are you serious? These are just 2 neat ways for expressing common boundaries conditions. The point is it's more readable instead of using '>'. That is all.
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.
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...
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.
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.
In certain branches of mathematics, it is routine to work with very long inequality chains. For example:
a < b <= c < d <= f <= g < h
You would then conclude that a < h holds.
I haven't looked at the article, but based on the comments it sounds like the author has this kind of thing in mind. I got the vibe that he was arguing that you shouldn't mix < with >, not that he was arguing that comparisons should only ever be made low-to-high.
This is incredibly poorly thought out. You don't only use conditionals while iterating. Even if you did, wanting to have a math like notation isn't necessarily reasonable. When reading a simple multi-part inequality like 5 < x < 10 I don't think "when 5 is less than x", I still think about it in terms of the variable. The benefit of arranging things in a simple inequality like above is the shorthand notation. You don't get that with:
I use this. I can read lines reading left to right with only </<= very quickly now, because of the visualization of a numberline in my head. Any other arrangement, and I have to slow down to my old, normal processing, and reason very carefully about the code, lest a subtle bug slip by.
For similar reasons, I find this notation helps me prevent errors, because they become visually detectable.
It was a cell growth simulation. Morphogenesis. The goal was to start with a single cell and see if I could make it divide and grow into something neat. The constraint was that all the cells were identical, and 'knew' only a limited amount of things about their environment: how many neighbors were touching them, and the levels of an arbitrary number of 'chemicals' that would diffuse from one cell to the other.
I made the scripting language as an easier way to program the 'rules' in the cell class. Dozens of little rules such as "if chemcial_0 is between 0.879 and .936 the increase chemical_1 by a smidgen," or "if chemical_23 equals 1.738 then undergo mitosis."
The little shorthand syntax was far easier to read than the mess of conditionals in C++.
It was pretty neat. Used Box2d for the physics part.
Got up to making a worm kinda thing with legs.
But then gave up.
Trying to make identical cells differentiate into asymmetrical patterns is something that always intrigued me. Got interested after reading this: http://www.mvla.net/view/19352.pdf
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)"
Is this efficient? I was under the impression (which is likely inaccurate, because I'm no expert on Python) that range returned a generator or a list outright, making this an O(n) operation.
You're correct. It returns a list from from [a, b), but it's just another example of some expressive (albeit computationally inefficient) notation Python has.
Edit: I take that back. Here's a section from Python's range() documentation:
> The advantage of the range type over a regular list or tuple is that a range object will always take the same (small) amount of memory, no matter the size of the range it represents (as it only stores the start, stop and step values, calculating individual items and subranges as needed).
No, what the docs say is that range is a generator. It never stores the entire list of values, but it does iterate through all the numbers, spitting them out one by one (hence it uses O(1) memory, but O(n) computation).
Equivalent pseudocode:
function in_range(x, a, b):
for i=a; i<b; i++:
if x == i return true
return false
That... has nothing to do with nemo1618's wish. The python statement 2 <= x < 4 is not a statement about x being within a particular range; it's just as valid to say 2 <= x > 4.
Nobody would ever purposefully write 2 <= x > 4 … it's a bug. Maybe if the bounds on the example were variable.
But the point of being able to collapse a < b and b < c into a < b < c is there to make ranges easier to notate/read. That's seems to be nemo's wish. (Though perhaps he wishes the range to be completely separate, e.g., in the psuedosyntax `b in [1, 3)`.)
I don't think I've ever seen it actually used for anything else, and I would in advocate against it, in code review.
> I don't think I've ever seen it actually used for anything else, and I would in advocate against it, in code review.
Yes, this would be a terrible practice. But that's what Python offers. The desire to express that a variable's value lies within a range is very common, and is presumably the reason for Python's bad choice. But that doesn't make Python's syntax a good response to the desire. The syntax expresses a conceptual mess; you're relying on people only using a tiny subset of what's there.
Contrast lisp, where you actually can express the concept of a range, as (< lowBound variable highBound). Unfortunately, that won't allow you to mix soft bounds with strict bounds. But it's vastly better than Python's approach.
Contrast Ruby, which offers almost every convenience in ranges, including literal notations, that you could ask for.
$ swift
Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance.
1> let x = 3
x: Int = 3
2> if x in 2...4 {}
error: repl.swift:2:6: error: expected '{' after 'if' condition
if x in 2...4 {}
^
Yes, if you use the pattern matching operator I suggested to the original comment's author:
$ swift
Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance.
1> let x = 3
x: Int = 3
2> let y = 3.0
y: Double = 3
3> 2...4 ~= x
$R0: Bool = true
4> 2...4 ~= y
$R1: Bool = true
Another article along the lines of "I personally prefer to use a syntax in a certain case, therefore everybody should use the same syntax in every case, and really I do not understand why the language creators even allowed for the other syntax".
No, your are not smarter than everybody else. You just have different tastes, and you are not even covering all possible use cases (I would say that most people find "x > 0" more legible than "0 < x").
A lot of "Don't do" or "X considered harmful" article writers should really be a bit more careful before generalizing from "I like" to "everybody should" so quickly.
as a CS major im sure this has academic value. as someone who is just learning python outside of a trade job as an engine mechanic, this idea makes me want to glass someone and im not sure why.
(5 < x && x < 10)
if we're talking about X, whats wrong with defining the parameters of its constraints in terms of X instead of dancing around the numbers? 5 < X makes it sound like im setting constraints on the number 5.
Actually this has zero academic value. The entire point is as a working programmer to compensate for ambiguous pitfalls in a language.
You don't need this specific trick in python (as others have pointed out, `5 < x < 10` works), but in general python holds to a similar philosophy of using standardized idioms to make reading code easier. It's called "being pythonic".
The number line representation is incorrect. (5 < x && x < 10) represents x has possible values of 6,7,8,9 (assuming x is int), whereas the number line shows that 5 and 10 are inclusive, but that's not the case as per the provided example.
Because all of the author's number line representations are consistent, I think you can consider them placing an implicit "open circle" on the bounds of all those ranges on the number line.
Let's say that I want to check that something is between 5 and 10.
...you did not specify explicitly whether the ends are inclusive/exclusive, and IMHO that (and the off-by-one errors it causes) is far more important.
Related: I've more than once had to ask someone whether "I will be away from 23 to 27" was inclusive or exclusive for the 27, because e.g. "meeting from 10 to 11" usually is exclusive at the upper end.
But you have to know if the boundaries are inclusive or exclusive, which leaves you with four different possibilities. You and everyone who reads your code needs to know this.
Ruby is my main language and I would have to look up the boundaries of this function.
Your "explicit" statement is also so much worse than using `x < 5.0` or `x <= 5.0`, depending on what you want. This is terrible advice imho.
A somewhat stupid way to solve this issue (of what is likely poorly-designed API, given what you're trying to do here; optional Arrays are generally a code smell) is to abuse the nil coalescing operator:
Well sure, except if the array is optional (and I agree it's code smell, but that's what you get when you use other peoples' libraries, I guess) that statement doesn't unwrap the array for me to use; I'll either need to do it manually on a second line (waste of effort) or every time I try accessing that variable. If I access it a lot, this is inefficient duplication.
Plus, I don't like abusing the nil coalescing operator. Once you're abusing anything, you're adding signal to noise and making the intent of a statement less clear than necessarily, I feel.
+1 for isEmpty, though. According to the docs, count iterates over collections that don't conform to RandomAccessCollection, so best to avoid unnecessary overhead by adopting good practice! Thanks for that.
In your specific example, it didn't look like you wanted to use that array, so I thought I could save you a variable. If you are planning to use it, then by all means bind it to a variable for reuse.
It could be changed to that, but what am I really asking? "Is zero lower than the length of my array" is a bizarre way to word the question, as opposed to "is the length of my array greater than zero".
I believe in self-documenting and obvious code, and I think if statements should read as much like a human sentence as possible.
Only if I _want_ the array to be empty, otherwise I have to put an ! in front of the that — which in Swift also needs brackets — which is just adding noise to the signal, really, which really defeats the purpose of avoiding the greater than symbol here.
For normal scalars any are fine and I can see the number line merit of the post. Where I find much greater value is when dealing with points in time. Write x.isBefore(y) rather than y.isAfter(x) especially in compound contions.
is there really a naming distinction between ‘>’ and ‘<‘? Is only one really the ‘greater’ than sign? Interesting if so! I always assumed it was context dependent (i.e x < 10 could be said 10 is greater than x, so it’s still acting as a greater than sign - but I see why I’m probably wrong here). I was interested in seeing an arguement like another poster made, where notation be like x = [0,1] might be proposed.
aloud, you must read it as "Pull the lever when x is less than zero." Thus, "<" is "less than", and ">" is "greater than", for that reason specifically.
Also, Unicode calls it U+003C LESS-THAN SIGN and U+003E GREATER-THAN SIGN.
At least, that's the terms that the article is using, and I think there's sufficient context to identify that, and go along w/ it.
Well, and I don’t mean to be strictly pebdabtic, but you could read it as “when 0 is greater than x”, but of course it takes more overhead and I see why I was wrong. Thanks, it’s getting late today so I’m glad I managed to learn something before the days up.
> is there really a distinction between ‘>’ and ‘<‘? Is only one really the ‘greater’ than sign?
The convention I've always seen is that `>` is "greater than" and `<` is "less than". Reading from left to right `x > 2` is "x is greater than 2" and `2 < x` is "2 is less than x". Functionally the same, yes, but with a distinction in the way the comparison is done (reading left to right). So with a preferred/dominant reading direction I would consider them different. This would be important if reading/describing a line of code to someone where it might be read/written left to right.
I don't know if the names are reversed in languages that are read right to left?
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.
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.
If we were optimizing for readability and predictability, we'd standardize on the most commonly used format.
``if (x > 5 && x < 10)``
Putting a rule that variables should always be on the left hand side of a comparison also gives you only 2 ways to write any conditional, so it's just as good as getting rid of ``>``. It also has the advantage of being by far the most widespread way that people already write conditionals, so you don't need to hold a team meeting where you explain to a bunch of grumpy senior programmers why even though they think their coding style is easier to read it actually isn't.
But by far the best option is to not have a meeting at all and to not care about things like this. In the absence of real, tangible data that conditional styles are causing bugs, these kinds of debates are very often a pre-optimization, and pre-optimization should be avoided.
When I put the effort into tracking and ordering the root causes of the majority of bugs in my software (both in personal projects and in large corporate environments) I am often surprised at the results. Very rarely are they consistent with the causes I would have predicted.
That's why I call things like this bikeshedding. In a large organization, it is probably more productive for you to hold another meeting about encapsulation and code reviews than it is for you to start up a Slack discussion about what style people use on their conditionals.