I converted some Fortran code to C. I was wondering if someone could help me solve the following problem:
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
I know this warning is caused by syntax like this:
A || B && C
Which should be written as:
A || (B && C)
My compiler is able to compile the code since && has a higher priority than || so it just imagines the parentheses.
The problem is that this warning occurs about 30.000 times since I'm working on a large project.
Is there any tool that is able to insert the parenthesis around all the && automatically?
As others have said do it manually, also you can disable this warning using -Wno-parentheses, even though that's pretty dangerous
Turn off stupid warnings. A || B && C does not need parentheses, any more than A + B * C does. Unless you haven't bothered to learn how logical expressions work...
Related
I have stumbled upon an if statement where the condition is actually an assignment and I don't really understand what it does. Now, I found a similar Question with extensive answers but I still don't quite understand, what my snippet does:
if ((x = !x))
/* some code */
The similar question I found is this one: https://unix.stackexchange.com/questions/306111/what-is-the-difference-between-the-bash-operators-vs-vs-vs
One user states, that
((…)) double parentheses surround an arithmetic instruction, that is, a computation on integers, with a syntax resembling other programming languages. This syntax is mostly used for assignments and in conditionals. This only exists in ksh/bash/zsh, not in plain sh.
What does that mean? Is the value of x toggled now and nothing else happened? In what case does this condition return false?
It does the same thing as if(x = !x) does. However, because it is very easy to accidentally use = in place of ==, compilers will warn you when you're using an assignment inside of an if statement. That warning doesn't get displayed if the assignment expression is inside of a second set of parenthesis.
So that's the point of the extra parens: to tell the compiler/reader that the writer really meant to use assignment rather than equality testing.
I would like to catch cases like this:
if(a == 2 && b == 3)
and convert them to:
if((a == 2) && (b == 3))
I didn't see anything that sounded like this here - is there a way to enable this?
There is no clang-tidy check that would do this transformation. The reason probably being that there is nothing wrong with the code you want to transform.
I don't even think that this transformation is something clang-tidy is intended for since this is just a question of coding style. Nowhere did I find a guideline that would prefer the first style over the second or vice versa.
You can write your own check but I don't think it's worth it. The only thing you can gain here is readability but even that is debatable at best.
This question already has answers here:
Uses of C comma operator [duplicate]
(20 answers)
Closed 9 years ago.
Good day, everyone.
I've come across a peculiar piece of code today, which I don't quite understand.
I don't even know how to search for this particular problem.
In this code, which works, a variable assignment is done like this:
if(condition) {
Var1 = false, Var2 = false;
}
Now, I was under the impression, that ALL commands need to be terminated by a semicolon instead of a comma. I am familiar with the syntax
Var1 = Var2 = false;
but not with the one posted above. The compiler (g++) doesn't even throw me a warning or anything...am I missing something from the specification here?
Or is the compiler generous with me and just replaces the , with a ; internally? If so, shouldn't he at least throw a warning?
Thank you for your time.
am I missing something from the specification here?
Yes, it's the "comma operator", specified by C++11 5.18. It evaluates the sub-expression to the left, then the one to the right, and the overall result is that of the right-hand one.
In this case, it's equivalent to two expression statements separated by ;
It's useful in places like if/while/for where you're only allowed one expression, but might want to do more than one thing:
while (++i, --j != 0)
and also if you like to jam multiple statements together to make life difficult for whoever has to read your code.
In the C and C++ programming languages, the comma operator (represented by the token ,) is a binary operator that evaluates its first operand and discards the result, and then evaluates the second operand and returns this value (and type). (read more)
As Alexandru Barbarosie pointed out, there's quite a thorough explanation on what's happening at https://stackoverflow.com/questions/1613230/uses-of-c-comma-operator
To quickly summarize it for whomever stumbles across this post: When used outside of for loops and stuff, the , actually has the same effect as the ;.
For more information, please visit the link.
This question already has answers here:
What is the difference between these (bCondition == NULL) and (NULL==bCondition)? [duplicate]
(6 answers)
Closed 9 years ago.
I have received code from someone working earlier on it, and it contains a lot of lines like
while(false==find && false == err && k<kmax)
if(true==refract(ep1,ep2,n1,RI_blood, RI_collagen))
and my favorite line is
if(false == (ret_s<0))
The other code is done really well, documented just fine, but these lines with these odd conditions are throwing me off, and I wonder why they are done that way.
Especially that false==(ret_s<0) is completely confusing, and you kind of need to read that line like three times to understand what they want there.
Is this a common programming style, don't I understand the reasoning for that, or is that just bad style?
Edit: I don't feel this is similar to if(object==NULL) vs if(NULL==object), since this isn't about accidental assigning but about obfuscated if clauses...
Is this a common programming style?
No.
don't I understand the reasoning for that?
Some people like to explicitly compare booleans with true or false, even though the result is exactly the same boolean value. The logic is presumably that, by making the code harder to read and more surprising, people will think harder about it and make fewer assumptions about its behaviour. Or perhaps just that code should be hard to maintain, since it was hard to write.
Others like to write comparisons with constants backwards, which prevents mistakes like if (x = 5) when you meant if (x == 5). Any modern compiler will warn you about this mistake, so again its only real purpose is to make the code harder to read.
Combining these two behaviours gives the bizarre code you posted.
Or is that just bad style?
It's a style. I'm no judge of style, but if you like to keep maintainence programmers on their toes, it certainly does that. Personally, I like my code to be readable, but that's just me.
my favorite line is
I once encountered return a && !b implemented in about ten lines of code. The first line was switch(a).
Yoda Conditions
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it's like saying "if blue is the sky" or "if tall is the man".
Its a safe guard against assignment in C++.
In C++ it is perfectly legal to do this
if (foo = true) ....
In this case the single = is an assignment and would replace the value of foo.
This is not legal and will generate a compiler error
if (true = foo) ....
Constants and literals are often put on the left because it prevents accidental assignments. Consider typing:
if(foo == bar)
as:
if(foo = bar)
The second might appear to work... but silently clobber foo. If foo is a constant, this error is not longer possible.
It's a self-protection technique that prevents you from accidentally typing an assignment operator (=) instead of equality operator (==), which can introduce strange bugs. Putting the constant value on the left hand side will introduce a compiler error, while putting a variable on the LHS will just silently compile.
Perhaps the original programmer thought that explicit comparison to true or false was clearler than if(condition) or if(!condition) and coded things in that way. I haven't seen this particular style before however.
It's quite subjective but I find while(!find && !err && k<kmax) easier to read.
The code could have been written for a shop where there is a site standard that every conditional statement must include a comparison operator, in order to avoid accidentally leaving out part of the comparison. (Maybe that's a stretch, but you did say that the rest of the code was very good.) That, coupled with a standard or habit of putting the constant on the left to avoid accidentally using = instead of == would give pretty much the code you showed. It doesn't explain the use of 'false' instead of the more natural 'true', though. Maybe it's a (misguided on multiple levels) attempt to gain microefficiency by comparing to zero instead of 1 at the machine level.
for my is only bad style,
if(false == (ret_s<0))
is equals to in C#
if(!(ret_s<0))
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to check for equals? (0 == i) or (i == 0)
Is there a difference between i==0 and 0==i?
I have seen many a times that people use the if(condition) as if(0==x) instead of if(x==0). It is said to be a good practice but can someone explain why so? What difference does it make ? Rather it decreases the readability in my opinion.
The fact that it decreases readability is purely subjective. (I feel the same way though, but that's because I've been dealing with x==0 more than the other way around, so I got used to it).
It's done to prevent accidental assignment:
if(0=x)
will yield a compiler error,
if(x=0)
won't.
Personally, i don't prefer this practice. but it became popular because of following reason:
To differentiate between assignment operator and boolean condition.
if(x = 0)
This lines serves two purpsose:
Assigns 0 to x.
makes the condition false cause it is equivalent to if(0)
To avoid these mistakes, some people prefer if(0 = x) which will result in compile time error.
It simply avoids a typing mistake where you would type if (a = 0) instead of if (a == 0). Using the Yoda style you'd get a compile error if you wrote if (0 = a) instead of if (0 == a).
On the other hand, it doesn't prevent cases of if (b = a) and b is another variable. No silver bullet.
Better is to use -Wall -Wextra when compiling. Add -Werror if you want to be paranoid and treat all warnings as errors (it is better to do this)
Yes, it less readable (imho), but this allow to avoid common mistake with assign instead of checking its ==
if( 0 = variable ) { // Fail 0 is constant
Fun fact: some calling this "Yoda conditions"
No, It's just your habit to read the things like variable name in left and constants in right.
But actually it will give you exact code that if you leave
if (0=x)
instead of
if(0==x)
by mistake then it will throw you an error which you can easily modify but if in reverse case its very difficult to debug