[danShumway]

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.

[userbinator]

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.

[cmroanirgo]

Agreed.

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'):

if (x>=1 && x<=10)...

[danShumway]

> This article reads like someone who doesn't understand inequalities

Not really the point I was getting at. I don't think the author is stupid, and I don't think their style is hazardous. I think it doesn't matter.

[saagarjha]

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

[2muchcoffeeman]

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

[danShumway]

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:

``if(10 > x && 5 < x)``

[tabs_masterrace]

> more productive for you to hold another meeting

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.

[BurningFrog]

The article was about programming style. You write about team meetings. There is a disconnect.

[danShumway]

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.

[BurningFrog]

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

[btschaegg]

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.

[BurningFrog]

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.