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

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

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 4

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 5

Parentheses reduce readability when they are obviously redundant. The reader expects them to be there for a reason, but there is no reason. Hence, a cognitive hiccough.

What do I mean by "obviously" redundant?

• Parentheses are redundant when they can be removed without changing the meaning of the program.

• Parentheses that are used to disambiguate infix operators are not "obviously redundant", even when they are redundant, except perhaps in the very special case of multiplication and addition operators. Reason: many languages have between 10–15 levels of precedence, many people work in multiple languages, and nobody can be expected to remember all the rules. It is often better to disambiguate, even if parentheses are redundant.

• All other redundant parentheses are obviously redundant.

Redundant parentheses are often found in code written by someone who is learning a new language; perhaps uncertainty about the new syntax leads to defensive parenthesizing. Expunge them!

---

You asked for examples. Here are three examples I see repeatedly in ML code and Haskell code written by beginners:

• Parentheses between if (...) then are always redundant and distracting. They make the author look like a C programmer. Just write if ... then.

• Parentheses around a variable are silly, as in print(x). Parentheses are never necessary around a variable; the function application should be written print x.

• Parentheses around a function application are redundant if that application is an operand in an infix expression. For example,

  (length xs) + 1
  

  should always be written

  length xs + 1
  

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.

Answer 8

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.