" Rename this field “MY_STRING” to match the regular expression ‘[1][a-zA-Z0-9]*$’."
for the following code.
public class C
{
public static String MY_STRING = "foo";
}
this is not exactly a FP, but rather reports the wrong thing. The mistake here is, that the field should be final, or is missing the final modifier.
The rule should either try to find out, if a complete uppercase field could be final in the current scope or at least suggest to “rename the field… or make it final.”
Thanks for reaching out and raising your concern with us. I think there may be a misunderstanding regarding the intent of rule S3008. The intent of this rule is to check that static non-final field names should follow a naming convention.
What you are suggesting is basically the inverse implication: to determine if a field should be final or not based on its name and the convention in place. Unfortunately, this is not in the scope of the rule, although it could be a nice idea for a new rule.
yes, I know. And I understood the rule as you suggest. But I think, it doesn’t make much sense for this rule to suggest something, that obviously wasn’t intended by the developer.
I think, the rule should be worked over to not stubbornly suggset to follow the naming scheme, if it can be clearly seen, that the naming was intended, but just the final modifer got forgotten.
Having a static variable with all uppercase is very unlikely to miss the naming convention. And if you can statically see, that the member could be final in it’s scope, there should be no rule to suggest to change the name, but to do, what was intended: add the missing final.
And having the rule to check both sides, it should also suggest to either follow the naming scheme OR to add the possibly missing final (if currently all uppercase), if it cannot clearly tell, whether the member could be final.
Hi @mfroehlich, I raised a discussion about having a new rule based on your suggestion. I will update you once a final decision is taken.
Regarding the rule S3008 I think its intent is clear and specific: enforcing a naming convention given the syntax. This rule is safe and strong because it reminds the user of applying the naming convention in place, without requesting any alteration in the code behavior!
The suggestion to enforce the syntax given the naming convention is less strong and safe, and it relies on the assumption that the user knows the naming convention. The problem here is that such a rule would suggest a code change may not be intended by the user, leading to incorrect behavior. It is reasonable enough that the user is not aware of the naming convention, for example, a junior developer or a student.
I hope you understand better the implications that such a rule may bring, and for such a reason we might not implement it.
Of course I do understand that. And it might especially seem odd to have a rule about naming conventions next to other naming convention rules, that behaves not the same as the others.
On the other hand these rules should not be made to nag the user and just say something about the line of code, but to try its best to guess or tell, what is wrong there and suggest the right thing. And I am convinced, that my suggestion does a better job in this regard. No offence, of course!