3 ms·
It's purely cultural. "char* foo" or "char * foo" does make more sense than "char *foo". But culture is a very strong and useful thing; if it "looks weird", th
by eqvinox 2y ago
It's purely cultural. "char* foo" or "char * foo" does make more sense than "char *foo". But culture is a very strong and useful thing; if it "looks weird", that will create issues in people's brain when thinking about the code.
Also, case in point: how do you format "char * const foo"?
- cb321 2y agoRedundant cues are also strong. So, for example, C is largely whitespace-insensitive and operator precedence can matter a lot. Consider "x+y*z". If you always spaced this "x+y * z" it would be the same to the parser but less clear to a human than spacing it "x + y*z" where you have used whitespace as a redundant cue to operator precedence. Similarly, what makes C type declarators tricky for many is their "inverse nature" - "char *foo" means, applying the operator "*" to the identifier "foo" yields a base type "char". So, the "char* foo" form is literally creating a cue in the opposite direction of operator precedence just like "x+y * z" would. For just one indirection it's no big deal, but for things like "char *foo[]" and beyond it becomes more important. So, the "mis"-spacing "char* foo" sets people up for later conceptual failure. This is in addition to the above point by @onre about multiple identifiers and @anacrolix's initial rather, ahem, pithy take. There is also another "where would ()s be redundant/unneeded" rationale (though this largely recapitulates the 2nd paragraph here). If you are looking for a catchphrase then maybe it could be "Don't space-against-syntax".
- uecker 2y agoI do not think this analysis is correct. "char *foo" is not a cue in the wrong direction, it indicates that in "char *foo, bar" only foo is a pointer. Whether the syntax for declarations in C is a good or idea or not is a different question, but it is not misleading in the same way "x+y * z" is.
- cb321 2y agoYou seem to have misinterpreted my comment since we agree that the "no-space-before 'foo' way" is truer to the syntax, and to repeat myself, I had said "char* foo" is the bad cue and even mentioned @onre's multiple identifiers supporting point (which you reiterate). It can be hard to see whitespace on HN comments, though unless you do the 4space indents to get a monospaced font. You can in-page search, though. The only difference with the spacing against syntax in "x+y * z" is that there are fewer type-relevant operators (e.g. '+' does not work in a type expression). One does NOT hear people advocating for more space around '*' than '+' (though I have sometimes heard "equal space"). Your non-disagreement has not persuaded me that this is a bad way to explain the problem, although I agree I could cut down on the double negatives. :-) { Even grade school kids have some sense of precedence of '+' & '*' which is so broadly adopted that even hand calculators do it. } "How misleading" spacing against syntax can be is admittedly more subjective. I think whitespace can really matter to human readers. There are many other examples. gcc added -Wmisleading-indentation a while back. Off-side rule languages like Python embrace things that sometimes prevent that problem. The Nim compiler was once sensitive to exactly this kind of operator spacing where it would parse "x+y * z" { space around '*' } as "(x+y)*z" in an attempt to have the compiler "Do what I mean".
- uecker 2y agoAh sorry, I then I have indeed misread your comment.
- tobyhinloopen 2y agoI always get confused with `const` so I avoid using it hah. But If I had to, I'd either use `const char * foo`, `char * const foo` or `const char * const foo`.