They use it to *precisely* encode the type, if it is a const pointer
to an unsigned short you can tell it from the prefix...
Well, the problem is that anything that is a "killer argument" against
it for me, for example, quite likely might not work as a killer argument
for those who establish these rules in your case. Simply because they
might not (care to) see things the way I or you do.
I believe that the code is supposed to be as abstracted as possible form
the concrete types of the variables it operates on (with the exception
of the most low-level platform-specific one). The obvious example of the
need for such abstraction is template code, and it was mentioned here
more than once already, but in fact this applies in no lesser degree to
"regular" (non-template) code as well. Encoding the exact variable type
in the variable name is breaking this abstraction.
That would make a "killer argument" for me. YMMV.
On the other hand, encoding the algorithm-specific variable semantics in
the variable name is not breaking the aforementioned abstraction.
Forcing people to classify every variable as an ordinal or quantity or
whatever is less useful, imho, and if a variable is a pointer it is
usually obvious from the -> which follow it.
I'd say that in my opinion in this case you got it a bit backwards. It
is the variable semantics (which can be encoded in the name) that is
supposed to suggest the proper uses for that variable, not the other way
around.
For example, in my code an integral variable prefixed with 'bf_...' is
supposed to be used as an ad-hoc bit-field used with bitwise operations.
Using '<' or '+' on such variable would be an immediately obvious error.
Note, BTW, that in cases like that most programmers do naturally feel
the urgent need to encode this property in the variable name by
including "keywords" like 'flags' or 'modes' in the variable name. I use
the 'bf_' prefix for the very same purpose and try to avoid redundancy
(i.e. if it is 'bf_...' there's no need to additionally describe it as
'..._flags').