C language, Yoda beats myC in preventing incorrect "if statement"

[0xdeadbeef]

I agree that this "trick" is something that I avoid at all costs and always found questionable at least.
The proper solution would have been to implement a real boolean type in C and allow only Boolean expressions in if statements like Java does this.
This being said, the lack of real Boolean type a general problem especially when fighting with over-protective static code analyzers trying to implement MISRA with all of its crap like "essential types" and the like.

As a side note, there is another, even more obscure old "trick" like this still used by some people today. Actually, I worked for a project in the last months where a very few somewhat unexperienced people tried to create a coding guideline which was very thin, lacking all important things, but mentioned this "trick" as good practice (and they didn't even explain why they thought so):

Code: [Select]

#define FOO(x) do { foo(x); bar(x); } while (0)
Similar to the "value == variable" idea, this is just a silly idea which makes the code much less readable while gaining an advantage in one singular case that would never occur if using a more sensible coding guideline. Like either forbidding function like defines like this (and use inline functions instead) and/or to forbidding if/else statements without parentheses.

[eutectique]

99.997% based on what? Sample size of N=1 (you)? Of people of your age and in your culture? Let’s not fall into a trap of using ourselves as a measuring stick for the entire planet.

"If 10€ is less than or equal the amount in my pocket, I'll have two beers".

Hmmm.. Sounds natural.

[golden_labels]

The FOO(x) code is wrong, but not because it doesn’t conform to 0xdeadbeef’s taste. It may lead to x being evaluated twice. This is a common beginner’s mistake in using C preprocessor. It should be:

Code: [Select]

#define FOO(x) do {auto x_ = (x); foo(x_); bar(x_);} while (0)
Where possible, function calls⁽¹⁾ are a better option. But they’re not always possible in C. When a macro has to be used, this is not “a trick.” It’s a well-established and tested way of ensuring compatibility with code that uses such a macro and preventing bugs.

Why would project’s coding style be adjusted to not break some fragile macro invocation, instead of writing a macro that is not fragile and can be used without such restrictions? To me that sounds like postulating a style with a function arguments wrapped in parethenses, just in case some macro doesn’t use “a trick” of surrounding expansions with parethenses.

⁽¹⁾ Just functions. Not inline functions.

[TheCalligrapher]

As a side note, there is another, even more obscure old "trick" like this still used by some people today. Actually, I worked for a project in the last months where a very few somewhat unexperienced people tried to create a coding guideline which was very thin, lacking all important things, but mentioned this "trick" as good practice (and they didn't even explain why they thought so):

Code: [Select]

#define FOO(x) do { foo(x); bar(x); } while (0)
Similar to the "value == variable" idea, this is just a silly idea which makes the code much less readable while gaining an advantage in one singular case that would never occur if using a more sensible coding guideline. Like either forbidding function like defines like this (and use inline functions instead) and/or to forbidding if/else statements without parentheses.

There's nothing similar to the "value == variable" idea here. The key difference is that "value == variable" is supposed to be plastered all over the code at all levels, i.e. every time one needs a comparison of this kind. It is a client-code level trick.

Meanwhile, the `do/while(0)` is a library-code level trick - something you use hide internally, as an implementation detail in a macro. To the client code that macro is a black box (with usual caveats). The client code does not need to know what tricks were employed internally in implementing that macro. Nobody expects (or encourages) the client code to use similar tricks or even know about them.

Because of that, the `do/while(0)` qualifies as an extremely useful idiom, as opposed to the pesky "value == variable" idea.

---

If you open the source code of some C standard library implementation, you'll see a lot of horrendously looking trickery being used there. The code is virtually unreadable and can only be understood by a specialist specializing in standard library implementations. But the users of the library don't need to expose themselves any of that. And, of course, they are not expected to use similar techniques in their code (at least on a regular basis). The `do/while(0)` idiom is just a milder version of that.

[5U4GB]

"If 10€ is less than or equal the amount in my pocket, I'll have two beers".

"If today is not Wednesday then it is not a public holiday. Today is not a public holiday".

Is today not Wednesday?  No conferring.

[paulca]

The dark arts are to remove the IF entirely and just use a lazy boolean expression.

DEBUG && printf("Hello\n");

Some languages try and fight you more than others over this.

[DiTBho]

I agree that this "trick" is something that I avoid at all costs and always found questionable at least.
The proper solution would have been to implement a real boolean type in C and allow only Boolean expressions in if statements like Java does this.
This being said, the lack of real Boolean type a general problem especially when fighting with over-protective static code analyzers trying to implement MISRA with all of its crap like "essential types" and the like.

that's what I did in myC v3

• boolean_t is a built-in type
• { if(x), while(x), loop(x), .. }, x is (boolean_restricted_expression of boolean_t)