Hi *,

this rule is usefull in the case where you use common names for
attributes (such as x, or y), and accidentially "overwrite" them as
parameters. This again comes back to the point of readability.

The same variable name should ALWAYS refer to the same variable / value.

For setters and constructors this makes sense -> after all, in each of
these you have a simple assignment, and both variables will carry the
same value.

But in most other methods, the parameter you pass is NOT assigned to the
internal variable, so they actually refer to a different thing, and
thats where the confusion starts.

I know modern IDEs can show you which variable you actually refer to,
but this usually requires selecting the variable or hovering over it,
which you will not do if you are just reading the code trying to
understand it.

However, since we cannot agree to keep the rule, I'll have to be content
with removing it (which is already done).

Max

Alexander Kiel schrieb:
> Hi Max,
> 
>>> Speaking of that, there’s a rule that I would suggest to disable: the
>>> HiddenFieldCheck. I don’t really see its benefit. It forces to find
>>> somewhat artificial names for variables, where the field name is exactly
>>> what I want. Sometimes a method doesn’t have a name following the
>>> setField pattern, yet still acts as a setter for Field. This rule would
>>> make sense if we were using a Hungarian-like notation for variables
>>> (mMember, pParam, etc.), but that’s not the case in FOP.
>>> WDYT?
>> I like the rule, BUT I am ok with an exception for setters and
>> constructors (this is IMO a new option in checkstyle 5):
>> http://checkstyle.sourceforge.net/config_coding.html#HiddenField
> 
> The exclusion of constructors an setters is important. Otherwise we
> would be forced to use some Hungarian-like scope notation.
> 
> But why do you think, that this rule is useful at all?
> 
> Best Regards
> Alex


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to