I'd break this up by lines, every time.

  int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT))
  if (result != 0)

Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.

Yeah but that's also just a ridiculously long line which will be hard to read regardless ;)

I find this quote very powerful. I'm thinking I could re-use it. Is it yours or if it's sourced from somewhere could you share the source?

It’s traditional to build these kinds of loops in C, e.g.:

    int c;
    while((c = getopt(argc, argv, argstr)) >= 0) {...}

I’d say it’s acceptable, and Python is adding syntax so it can mix assignments and checks.

> Leave a comment there explaining the assignment.

Please don't. This is a perfectly understandable idiom in C. Don't explain the language in your comments; that's the job of a text book, which should be read by anyone before they read your code.

That's perfectly fine and arguably even better than the alternatives. The `a = b = c = 0;` format is also good.

But enabling it on the language level brings a large amount of risk and complexity just for what amounts to a micro-optimization.

This would achieve the same but is far more readable:

   while(status != SUCCESS) {
      status = syscall(...);
      // do something with status
   }

Exactly. All code I write must pass -Wall -Werror -Wextra and there's always a debugging phase once you have written the code since there are syntax errors and whatnot, a lot.

Not all languages allows chained assignment (a=b=c) like c++ does, which is why we have this problem (and probably does not automatically cast them to bool either)

Oh no, I'm not young. I just find this particular argument makes less sense than all the other types of arguments like this. Bracket placement in some languages is necessary to not have unintended effect. Tabs vs spaces can cause problems with certain ides/editors. I can somewhat understand most justifications as to why people have a certain reason for formatting code in their particular way. You want me to indent 3 spaces instead of 2 in Delphi, because that's the way you've done it, fine. I don't care. But this particular one, I don't get it. I never have. The amount of time that this one particular trick saved me in terms of time and frustration is huge. When you spend 45 minutes tracking down a problem because you assigned 5 (or something) to variable by accident, it almost always leads to a mouse throwing event. When someone comes back and says that seeing 42 == x is too difficult to read even though it can save countless hours, I just don't understand. (not every project has the benefit of having a linter or a compiler that will catch things like this.)

Just wait until people realize proportional fonts are actually easier to read than mono-spaced fonts.

> so it makes sense to put the important information

Both sides of the equality check are equally important.

> If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator

Code is for humans, not computers. The order I choose when writing an expression is driven by what I want to convey to the next person reading my code.

`if (button.state == .enabled)` suggests to the reader that the button’s state is the thing we’re interested in in this particular piece of code. Reversing the operands is confusing not because I don’t understand the communicative property, it’s confusing because it puts the emphasis on the wrong thing: I’m not checking if the enabled state matches an expectation, I’m checking if the button’s state matches an expectation. And I want the reader to understand that.

There are two perfectly valid ways of reading

   x == y

aloud as an English statement:

> X equals Y

> X and Y are equal

The first sentence uses active voice - the second passive. Active voice ascribes agency to X; It makes a subject/object distinction between X and Y. Passive voice makes them both objects.

When reading code, it makes more sense to ascribe agency to variables than to constants, which is why people are more comfortable reading x == 0 than 0 == x. Zero can’t change, so it can’t do anything to make itself equal something. X can change, so it is capable of equaling things.

If you’re equally comfortable with either formulation, maybe you just prefer the passive reading of the sentence.

But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i < length to length > i...

> Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it".

What? No. De '=' sign is very simple: what's written to the left of it is equal to what's written on its right.

I don't have a problem with 'equals' being commutative. My programming language does.

A second to realize what you did there it took me.

Look, I'm trying to humanly argue against the statement "Yoda conditions are unnatural". Nature has no boolean conditions. That statement should instead say "Yoda conditions are unfamiliar (to me)" -- at which point it's way easier to see the statement's applicability limits, and dramatically narrow down its consequences.

On the contrary; there're many common contexts where Yoda comparisons looks more "natural", meaning they avoid breaking the surrounding code flow, and bring the important part (the constant) up-front. I even brought up a real-world example. Having read `assert "403 Forbidden" == ` and remembering the context, can't you already guess the RHS (and just skim over it)? Sure you can. Non-yoda loses here.

Be aware: you don't have to take a "for/against" side in this debate, as our buggy brains try to in every flame war. Both sides have a point. Familiarize yourself, and decide on case-by-case basis.

While we're at it: self.assertEqual() is super-ugly and unnatural, in my judgement. Why am I forced to use _thrice_ as much words to express the simple single-word concept of an assert? Why can't I spare the extra pair of parens, and spell == directly? I see nothing wrong with bytecode rewriting; it's amazing they can do it, and I appreciate the effort.

Even with them, I do find it Yoda-like that you are supposed to make the expected value be the first argument

> Probably treating the cause's cause's cause's cause is something like “just use Excel for everything, why are you using these other languages?”

It's be harder to get things done, but we'd be more certain about them

I was also not allowed to use the C# ?? null-coalesce operator. So something like

  if( nullableBooleanVariable ?? false )

was also forbidden.