On Tue, 2011-11-29 at 08:36 -0500, John Dennis wrote:
On 11/28/2011 09:27 PM, Nathan Kinder wrote:
>This can lead to false assumptions when one should
> really consult the declaration to see what it truly is. The ability for
> the naming to be inconsistent with the declaration makes encoding the
> scope useless (and potentially bad) IMHO. I know I've been very
> frustrated running into variable names in C that had the type encoded
> originally, but someone changed the type in the declaration without
> changing the variable name.
Which is precisely why encoding type information into a symbol name is a
bad idea.
FWIW, it is possible to set the project formatting rules in eclipse to
require member fields to be prefixed with "m" - and to replace all
non-confirming instances automatically, as well as to flag
inconsistencies going forward. So if we choose to continue to maintain
this convention, we can be consistent. And renaming any particular
variable is trivial in eclipse.
I'm not arguing that this type of thing is a good idea in itself. But I
also think that having code that contains member variables that have
been prefixed as well as member variables that haven't been - is worse
off - because it is inconsistent and no one will know whether to trust
the "m" notation or not.
We have a very large code base that by and large follows this
convention. We can make it absolutely consistent by setting the eclipse
formatting rules if we choose to continue to follow this convention.
If we abandon the convention, we can do a few things:
1. We could try to replace all old instances all at once - which is a
monumental and error-prone process. And one which quite frankly, we do
not have the time to do.
2. We could replace variables in files as we work on them.
3. We could just leave the old variables and not use the convention in
new code.
Both 2 and 3 leave the code in an inconsistent and therefore, I would
argue, less readable state.
Ade