What are some examples of where using parentheses in a program lowers readability?

Question

I always thought that parentheses improved readability, but in my textbook there is a statement that the use of parentheses dramatically reduces the readability of a program. Does anyone have any examples?

Answer 1

If a method doesn't take parameters why require an empty () to call method()? I believe in groovy you don't need to do this.

Answer 2

Apparently, your textbook is written by someone who hate Lisp.

Any way, it's a matter of taste, there is no single truth for everyone.

Answer 3

I think that parentheses is not a best way to improve readability of your code. You can use new line to underline for example conditions in if statement. I don't use parentheses if it is not required.

Answer 4

Well, consider something like this:

Result = (x * y + p * q - 1) % t and

Result = (((x * y) + (p * q)) - 1) % t

Personally I prefer the former (but that's just me), because the latter makes me think the parantheses are there to change the actual order of operations, when in fact they aren't doing that. Your textbook might also refer to when you can split your calculations in multiple variables. For example, you'll probably have something like this when solving a quadratic ax^2+bx+c=0:

x1 = (-b + sqrt(b*b - 4*a*c)) / (2*a)

Which does look kind of ugly. This looks better in my opinion:

SqrtDelta = sqrt(b*b - 4*a*c);
x1 = (-b + SqrtDelta) / (2*a);

And this is just one simple example, when you work with algorithms that involve a lot of computations, things can get really ugly, so splitting the computations up into multiple parts will help readability more than parantheses will.

Answer 5

I can find plenty of counterexamples where the lack of parentheses lowered the readability, but the only example I can think of for what the author may have meant is something like this:

if(((a == null) || (!(a.isSomething()))) && ((b == null) || (!(b.isSomething()))))
{
   // do some stuff
}

In the above case, the ( ) around the method calls is unnecessary, and this kind of code may benefit from factoring out of terms into variables. With all of those close parens in the middle of the condition, it's hard to see exactly what is grouped with what.

boolean aIsNotSomething = (a == null) || !a.isSomething();  // parens for readability
boolean bIsNotSomething = (b == null) || !b.isSomething();  // ditto
if(aIsNotSomething && bIsNotSomething)
{
   // do some stuff
}

I think the above is more readable, but that's a personal opinion. That may be what the author was talking about.

Some good uses of parens:

• to distinguish between order of operation when behavior changes without the parens
• to distinguish between order of operation when behavior is unaffected, but someone who doesn't know the binding rules well enough is going to read your code. The good citizen rule.
• to indicate that an expression within the parens should be evaluated before used in a larger expression: System.out.println("The answer is " + (a + b));

Possibly confusing use of parens:

• in places where it can't possibly have another meaning, like in front of a.isSomething() above. In Java, if a is an Object, !a by itself is an error, so clearly !a.isSomething() must negate the return value of the method call.
• to link together a large number of conditions or expressions that would be clearer if broken up. As in the code example up above, breaking up the large paranthetical statement into smaller chunks can allow for the code to be stepped through in a debugger more straightforwardly, and if the conditions/values are needed later in the code, you don't end up repeating expressions and doing the work twice. This is subjective, though, and obviously meaningless if you only use the expressions in 1 place and your debugger shows you intermediate evaluated expressions anyway.

Answer 6

Anything taken to an extreme and/or overused can make code unreadable. It wouldn't be to hard to make the same claim with comments. If you have ever looked at code that had a comment for virtually every line of code would tell you that it was difficult to read. Or you could have whitespace around every line of code which would make each line easy to read but normally most people want similar related lines (that don't warrant a breakout method) to be grouped together.

Answer 7

You have to go way over the top with them to really damage readability, but as a matter of personal taste, I have always found;

return (x + 1);

and similar in C and C++ code to be very irritating.