VariableNamingConventions : underscore in final but at first position ?
A source code analyzer
Brought to you by:
adangel,
juansotuyo
private final String _projection;
private final String _projectionID;
=> These attributes are not in error with VariableNamingConventions as they are final.
It can be confusing as the underscore is in first position (due to private probably), and not in UPPER case.
=> final should be in UPPER case ?
These attributes don't raise a violation. Are you suggesting, that they should?
In terms of forcing final to be UPPER case - that's probably not a good idea - it would flag for existing code many, many violations.
In your example the attributes are not static - only static final attributes are checked for being UPPER case.
So, currently, the rule works as follows:
Essentially, any final attributes are ignored by this rule...
However, we can extend the rule and add an additional parameter, to also check "final" parameters and apply the same rules as for non-final one. Would this be useful for you?
Well, actually the main problem is that _ should be used to separate words.
In this case, the developer put an _ at the beginning (or at the end) of a variable name, because the variable is set as private, and not at all because the variable is static or final.
So I think it would be a good idea to raise a bug if an undescore is in first or last position of a variable name. What do you think about that ?
Well, it was mainly a suggestion, maybe it's not pertinent ...
Regards,