Community
Participate
Working Groups
When a function is auto-completed, the parameter values are filled with variables from the context. More often than not, the choice of which variable to use is incorrect. This is a productivity killer, but more importantly, could end up in inadvertent bugs unless the developer is extra careful to check that the parameters are correct. In earlier versions, the values were filled with the actual function parameter names. Would be good to go back to that behavior.
Moving to JDT core Please provide a sample case that exhibits the problem.
Created attachment 286167 [details] Shows that the autofill arguments can be counter productive This screenshot shows how counter productive the variable inference is. Earlier, it used to just suggest the actual argument names (example, astring1, astring2.. etc. in this case). That had a much better change of getting it right because developers tend to use consistent naming for variables within their own code.
Bumping this issue. I ran through into this issue several times in the last few weeks where I almost missed the fact that Eclipse randomly chose parameters which match the type.
This got introduced between I20200916-0410 and : I20200930-1800
sample code public class mainclass { private static String random = "ABC"; public static void main(String[] args) { manyArg } public static void manyArg(final String s1, final String s2, final String s3) { } }
Created attachment 286514 [details] You can change this option and try
(In reply to Vikas Chandra from comment #6) > Created attachment 286514 [details] > You can change this option and try Please change this option and try. See option.png attached
Lars, insert best guessed argument leads to error prone code. Do you think we should revert it? ( bug 433121 )
(In reply to Vikas Chandra from comment #8) > Lars, insert best guessed argument leads to error prone code. Do you think > we should revert it? ( bug 433121 ) Changing the component to text to reflect this.
(In reply to Vikas Chandra from comment #8) > Lars, insert best guessed argument leads to error prone code. Do you think > we should revert it? ( bug 433121 ) I have no strong opinion on that anymore. Maybe send an email to eclipse-dev asking for feedback?
(In reply to Vikas Chandra from comment #7) > (In reply to Vikas Chandra from comment #6) > > Created attachment 286514 [details] > > You can change this option and try > > Please change this option and try. See option.png attached This preference can be changed to get back the old behavior. We will keep this bug open to get more user feedback. Based on that, we can revert it later if required.
We switched from parameter arguments to parameter guessing in Bug 433121. I found this feature quite useful. I think we really need some kind of poll to figure out how many people find it useful vs. a pain. If the only issue with this feature is that it it's annoying in certain cases, is there a way to fix it ? Maybe don't consider static "basic" types in the guessing logic ? I was less convinced about Bug 423642, but many others seemed to indicate it was their preference.
(In reply to Roland Grunberg from comment #12) > If the only issue with this feature is that it it's annoying in certain > cases, is there a way to fix it ? Fixing specific issues sounds good. > I was less convinced about Bug 423642 +1. I find it more error-prone than helpful while coding.
(In reply to Vikas Chandra from comment #7) > (In reply to Vikas Chandra from comment #6) > > Created attachment 286514 [details] > > You can change this option and try > > Please change this option and try. See option.png attached Yes, that option works, thank you. Given that there is an option to make this work, I would bump this issue down to "annoyance". I still think the default should be "Insert parameter names".
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
