Posted Tuesday, December 18th, 2012 at 3:41 pm under programming, python.

Omit needless parens

The famous 17th commandment in The Elements of Style is “Omit needless words”.

There should be an equivalent in programming, but for parentheses. Every time I see needless parens in a program I want to rip them out (unless they’re obviously there for formatting/readability reasons).

Community service message: Omit needless parens. When in doubt whether parens are needed, look up the precedence rules for the operators involved and only use parens if the default isn’t what you want.

Here’s why you shouldn’t use needless parens:

  • The #1 reason is that you’re making your code more difficult to read for people who know the language better than you do. A more experienced programmer will see a red flag and look at your code more carefully than necessary because they will be trying to figure out why you used the extra parens and if there’s something non-obvious going on. When I come across code like that, I usually conclude that whoever wrote the code doesn’t know the language that well. My opinion of the code goes down. My reading speed goes down too because the needless parens, in my estimation, indicate an increased likelihood that programmer has done other (worse) things elsewhere.
  • You don’t want to appear incompetent or lazy, or to slow down or put off people reading your code, right? (See above.)
  • Putting in needless parens is heading down a slippery slope. How many levels of extra parens should you stop at? The only clear cut rule that makes sense is to stop at zero.
  • If you pause to look up the precedence rules, you’ll make yourself a better programmer in the language in question. You’ll be able to read other people’s needless-parenthesis-free code with no problem. You can pen lofty holier-than-thou blog posts like this one.

Back in about 1985 I wrote a tiny shell script to print out operator precedence and associativity rules for C. When I started programming in Perl, I wrote one for it. Then one for Python and later one for Javascript. For your convenience, and as a reward for reading, I just stuck the 4 scripts up on Github.

  • http://twitter.com/tunixman @tunixman

    Maybe if someone with more experience than me with a language (hahah not likely) is confused or distracted by parentheses that person isn’t really all that good and should practice a bit more language basics.

  • http://blogs.fluidinfo.com/terry terrycojones

    Hi John – I’m old enough to be pretty sure what language that is :-)

  • Robert Brewer

    Classic case of confusing busy people with lazy people.

  • John Gill

    I’m actually in favour of parens in expressions such as this:

    a = b + (c * d)

    Without them I have to ask, “is the code doing what the programmer intended?” In other words, I have to assume the programmer knows the order of precedence.

    I think it is more important to help the inexperienced programmer who may not know order of precedence than to worry about the expert.

    My opinion might be influenced by the fact that for a number of years I worked with a language where all operators had equal precedence and right to left associativity: it was just too easy to write code that did not do what you intended.

  • Anonymous

    I also find annoying things like: a = b + (c * d) . Mainly because it is pretty obvious.

    But when mixing non common algebraic operator (bit displacement operators, logic operators) I usually add the parenthesis even when they are not needed. I suppose is a matter of determining what is “readable” and what is “trash” (like the previous line parens).

    Hopefully, (many) Python programmers take readability seriously, and do not mix strange operations in long lines.

    Also, Python is a lot friendlier and simpler than other languages when it comes to operators. Outside Phython, your are free to write really dark lines of code. Consider this beautiful line in plain C:

    die = j+++i-++a*b-c–;

  • Anonymous

    You think too much about “more experience”, “my opinion of the code”, “appear incompetent” and stuff. After you leave your company to work for Google, they will hire a student to maintain your code — that’s what you should worry about.

  • http://blogs.fluidinfo.com/terry terrycojones

    I just changed “formatting” to “formatting/readability”. Thanks for commenting!

  • http://blogs.fluidinfo.com/terry terrycojones

    Hi anon. Yes, I should have been clearer in the 2nd para where I said “unless they’re obviously there for formatting reasons”, by which I meant physical formatting (e.g., to stay under 80 char lines) and also readability. I think it’s fine for readability, though I guess I’d just as often leave them out and hope people just get more familiar with precedence.

  • Anonymous

    Um. What about parenthesis for the sake of readability?

    IMHO, sometimes is better to help the code reader using a parenthesis pair… Looks like you do not approve them unless absolutely necessary. Readability counts!