Community
Participate
Working Groups
In many cases, assigning back to a parameter is a mistake. For example: public void foo(String name) { name = "Eclipse"; } Or perhaps even: public void setName(String name) { name = name; // Should have said, this.name = name } Please could this be added as a compiler error/warning/ignore preference.
moving to JDT Core
I actually tend to like this code pattern. An optional warning may make sense however. Will queue post 2.0.
To avoid any confusion, I wish to clarify that the following code SHOULD NOT cause a warning: public void setName(String name) { this.name = name; // This is OK. }
Reopening
Clearing resolution
Simon, would you actually want to see no-op assignments flagged or just assignments to arguments ? It seems you were mostly annoyed by "name = name" assignments. I could imagine similar annoyance with field/local variable. Or would you rather want to see flagged any assignment on arguments: e.g. void iterate(int count){ while (count-- > 0) doSomething(); }
Philippe, I think there are two issues here. Firstly there should be the ability to optionally flag assignments to parameters. While assigning to parameters is perfectly legal in Java, some people choose not to do this as a personal style. Typically people learn not to do this having used languages that disallow it, such as Smalltalk. I could imagine a corporate coding standard that states that assigning back to a parameter is not allowed since it contributes to more confusing code and errir prone code. Granted, Java does allow the programmer to create "final" parameters (that cannot be assigned back to), but I have never seen anyone use this in real code. Secondly, my PR was originally trying to find a way to flag a common mistake where the a parameter/local hides a field and forgetting to qualify the field reference with "this." results in devestating results at runtime. On a number of occassions I've made this mistake myself and been suprised that a field is still null even after it seems to have been initialized. The botton line here is to have optional compiler warnings that make it easier to write accurate code. In my experience you rarely need to assign back to parameters and extra care is needed when creating parameters/locals that hide fields.
+1 here (for a warning on assignments to params)
Let's try to sneak it for M4
Given we know detect assignments having no effect (see bug 25092) from build 20021112 on (2.1 stream), is it ok to close this one ? You can always force a variable to not be assigned by using the final modifier (even on arguments).
Sounds good to me. Yes, final can, but rarely is, used on parameters. With the functionaly provided by bug 25092 I think this bug can be considered RESOLVED/FIXED.
Closing as duplicate of bug 25092 *** This bug has been marked as a duplicate of 25092 ***
