#1349 VariableNamingConventions : underscore in final but at first position ?

[Denis SEMMAU]

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 ?

[Andreas Dangel]

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:

• static and final: violation if not fully UPPER case
• not final: violation if "_" is used in the name or if first character is a upper case character

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?

[Denis SEMMAU]

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,