-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flexibility of operator spacing / mixing of precedence #160
Comments
Or if you wanted to make it more specific, it could just be "writing fractions without spaces is also ok". |
I'm pretty sure I prefer |
I would argue that it is only harder to read for someone already used to writing in that way. Spaces generally enhance readability. The specific topic on numeric fractions (1/12 vs. 1 / 12) is just arithmetic thinking bias, treating fractions as a single entity and not an operation. |
I agree with your preference, and it's consistent with my point I think. There,
I think I think most readers know intuitively that
It's clearer that
I think the issue is even clearer in expressions with more operators:
Since the Google C++ guide was referenced elsewhere, I'll note that's in line with their recommendation: https://google.github.io/styleguide/cppguide.html#Horizontal_Whitespace |
If I carefully think about it, I can understand your point about high vs low precedence operators, but it's something I'd need to think about every time, so we'd need to figure out a simpler way of framing it in order to include in the style guide. |
I'm not sure how to capture the issue precisely, but I think the current wording of the style guide around operator spacing can lead to some hard-to-read code:
is IMO pretty hard to read vs
I think what's going on here is
+
is lower precedence than/
, but they have equal spacing. Removing the spacing around/
is a visual cue about operator precedence.The logic breaks down when we use more complicated expressions with more than two levels of operator precedence:
Perhaps the recommendation in this case could be to use parentheses to limit any sub-expression to at most 2 levels of operator precedence. Maybe overkill.
In any case, I think a simple case where
+ | -
and* | /
are mixed could be spelled out pretty easily.The text was updated successfully, but these errors were encountered: