Space around operators? a=b/2; or a = b / 2; What are the arguments?

Question

Personally I prefer space around operators. For me it makes the code much more readable. What are the arguments not have space around them? Line length?

An example from the Python style guide (I agree with this):

Yes:

  i = i + 1
  submitted += 1
  x = x * 2 - 1
  hypot2 = x * x + y * y
  c = (a + b) * (a - b)

No:

  i=i+1
  submitted +=1
  x = x*2 - 1
  hypot2 = x*x + y*y
  c = (a+b) * (a-b)

Answer 1

I must confess I like the with the combination according to precedence.

1. x*x + y*y immediately know what's going on
2. (x * x) + (y * y) spaces are okay, too, but then make it obvious
3. x * x + y * y okay but I spend more time looking at it than in the above example
4. x*x+y*y urghs

Answer 2

Spaces rock. I like to imagine that people who prefer no spaces live in very cramped, very crowded cubicles.

Answer 3

Let me put it this way:

P u t t i n g s p a c e s e v e r y w h e r e d o e s n ' t r e a l l y h e l p.

Use whitespaces to visually support the structure of your code.

But understand: The clearness of your codes structure is not proportional to the amount of whitespace you use. So don't overdo it. Personally, I often code on my laptop and I can tell you, putting two new lines after each block doesn't increase readability, because it prevents me from seeing a whole unit of code at once. But then again, these are my personal constraints.

Adding whitespaces between operators is not cannonically better. Any mathematician will tell you that 4ab is more readable than 4 * a * b. It's a matter of culture and habit.

What you really should do is sit down with your team and try to get a feeling for how much whitespace is too little and how much is too much and then stick to that. Because ultimately, you don't do this to please some higher power (or some style committee that acts as if it were one), but for the people who have to maintain that code.

Answer 4

Proper syntax highlighting, which is a must-have for every IDE, makes spaces less useful. Highlighting makes names of variables visually distinguishable from math operations and assignment operators. This just means that how to set spaces is not a very important question.

I usually select a pattern depending on a language. If a language is abundant in spaces (such as OCaml or Haskell, where Space is a delimiter of function arguments), I use more of them:

let filtered = List.filter (fun x -> (x * 2) + 5 > a) list in
if ((List.length filtered) > 0) then ...

But if spaces aren't used as valuable syntactic constructs (C, C++, Perl), I tend to avoid them:

int decision=calculate(x*2,5,a) || (y*3<100);
if (decision){
  ...

Syntax highlighting (which seems to be turned off here) makes the latter example less of a mess.

Answer 5

Spaces give some room for breath and make the code a lot more readable.

Answer 6

Readability is more important. So go for the 1st method.

Answer 7

I like spaces. But fortunately they have invented code formatters so you can format the code he way you like.

Answer 8

All coding standards I've ever used (in Java, C and C++) required spaces around most/all binary operators. For me, if the coding standard says so, that is good enough reason.

Some people would argue that coding standards are fascist, cramp their style, make them less efficient programmers, etc. But these arguments miss the point. Coding standards are about making your code readable and maintainable by other people.

Answer 9

Space in code is like a fresh air breath. Always go with spacing between operators, if you want to highlight something just use parenthesis.

Answer 10

My personal preference used to be to not go with the spaces: when writing C / C++ code I never used them around operators.

But since moving into the C# space, with Visual Studio automatically formatting my code with spaces around the operators, I realized that I actually didn't care. I'm perfectly happy with the spaces just as I used to be perfectly happy without them.

Answer 11

I always do the spaces more because I like the way it makes my code look as a whole, instead of any readability when figuring out what expressions do. I don't see a difference either way as far as that goes, but something about having those spaces between everything makes the code feel much less cramped and more pleasing to me.

Answer 12

Spaces help in separating and therefore parsing the code. Where does a token end, and where does another one start?

In Pavels example:

int decision=calculate(x*2,5,a) || (y*3<100);

there is an ambiguity between european number formatting, which leads me to think for a very short time about

calculate (x * 2,5, a)

as in

calculate (x * 2.5, a)

• of course just for the fraction of a second, but many short annoyances and distractions will make you tired after hours. If it is intermixed with output, where you write

  print ("calculate (x * 2, 5, a)")

and have to avoid ambiguity, which isn't in the expression from the programming languages perspective, you don't wan't to use different standards there.

You might have an editor, which highlights the commas, the ciphers and the variable name in different colors, but when posting it here or in email, the highlightening might get lost/will be lost.

I'm not sure how editors decide, what to mark for copy actions if you double click or triple click on an expression. Blanks could be helpful for reasonable decisions there.

Answer 13

Depends on if you are writing or reading the code. Being a solo coder I have found that my coding (ahem) standards have layers to them. When I am writing the function, or it is in progress, I just use basics, but when the function or module has jelled I will often put in the most OCD of coding style -- so I can tell when I am in a 'pristine' or finished function (or various stages thereof).

Answer 14

Consider that someone with aging eyes might need to read your code. Spaces around operators make code physically easier to read.

Answer 15

We have a couple of hundred years of prior art typesetting mathematics. I can't think of any reason not to follow that practice. Put spaces around operators, but not around '(' and ')'. I would also not put spaces around an exponentiation operator, especially if it is the circumflex (^). I am in some agreement with posters who suggested using spacing to match operator precedence.