So I always do char \p1. Yes, for a non-C programmer its not as intuitive, but C isn't intuitive a lot of the time (cough, char p1[] what?). But you avoid making these mistakes altogether.
Note in function declarations I use char, because you cannot do statement expansion with a comma there, and because in headers the variable name is optional anyway.
char *p;
I prefer to use char* p; as well as std::string& s; and etc. rather than attaching the type syntax to the name, since in essence that's part of the type. But yes, it's a mess that this inherited C logic doesn't treat it that way clearly. To avoid such mistakes, it's better not to use comma declarations altogether, you can perfectly avoid them.
It's a good feeling when working with new languages like Rust which avoid such mess.
The point is, though, that while in a developers mental model you attach ref or ptr to the type, the language itself does not, and writing it out like it does can easily drive newer developers who do not understand the nuance to make hard to recognize mistakes as a result of it.
Consder this:
You could erroneously think that char* is a type, and p1 and p2 are variables of that type. That's not correct however, since p1 is indeed char*, but p2 is char. Such declarations therefore should be strongly avoided for clarity.[1]: https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...