fix SonarCube issues "Local variables should not shadow class fields"(squid:HiddenFieldCheck)

[igor-suhorukov]

To get rid confusing to know whether the field or the local variable is being used. This pull request fix 171 issues with "local variables overriding class field names"( squid:HiddenFieldCheck)

This pull request is related issues described in ticket #11650

[wilkinsona]

Thanks for the PR but I disagree with this one. We prefix all field access with this so, IMO, there’s no confusion.

[igor-suhorukov]

@wilkinsona ok, it is my mistake maybe

[igor-suhorukov]

@wilkinsona what do you think about Utility classes should not have public constructors
and Generic wildcard types should not be used in return parameters
?

[wilkinsona]

Certainly not a mistake, but a lot of Sonar’s rules are quite subjective so we may not always agree. If we proceed with #11650, we’ll want to spend time creating a profile that team are happy with and hopefully all agree on.

[philwebb]

I'm with Andy on this one I'm afraid. We have a checkstyle rule to enforce the this. prefix so I think there's limited value in enforcing different local variable names. In fact, I often prefer the simpler names you get when you aren't forced to choose something different.

[philwebb]

what do you think about Utility classes should not have public constructors

Generally agree and we have a checkstyle rule for this. The problem with the Sonar results here is that is' picking things like CacheMeterBinderProvidersConfiguration that I don't consider utility classes. In fact, we've generally tried to avoid util classes altogether in Boot.

Generic wildcard types should not be used in return parameters

This one is very subjective as well. I generally try not to return them for public APIs, but it can be difficult to always do this without causing a lot of problems. Take this one for example. We could return a PropertySource<Object> I guess, but really what's the point? We're really saying you can return a property source of any generic here and we'll deal with it. I'm not sure always enforcing the rule makes for better code, although it may well be worth a review of some APIs.