Community
Participate
Working Groups
The parameter name mining is especially useful when dealing with method calls with a lot of parameters. But personally I would prefer not to have it enabled when the parameter count is lower than (and perhaps even equal to) 3. I mean, a call like "Period.between(today, anotherDay)" is enough simple to be auto-explicative even if parameter names are not shown, I think. Unfortunately, this is not configurable and as of Eclipse 4.14, once mining for parameter names is enabled, they are shown for any method call with at least 2 parameters.
(In reply to Mauro Molinari from comment #0) > a call like "Period.between(today, anotherDay)" is enough simple > to be auto-explicative even if parameter names are not shown, I think. What makes the code explicative here isn't the number of parameters, but the naming. On the other hand, some calls like BigIntegerMath.binomial(input1, input2) have as many parameters, but it's not clear what's the role of which in this non-symetric operation and showing which one is `n` and which one is `k` can be useful.
Just for your information, there were several issues in JDT CodeMining with parameter name. See issues https://github.com/angelozerr/jdt-codemining/issues?q=label%3A%22Parameter+Mining%22+is%3Aclosed One of issue that I like and I started to implement is to give the capability to exclude parameter name according somes rules (like IJ does). See https://github.com/angelozerr/jdt-codemining/issues/61#issuecomment-408381861
(In reply to Mickael Istria from comment #1) > What makes the code explicative here isn't the number of parameters, but the > naming. On the other hand, some calls like BigIntegerMath.binomial(input1, > input2) have as many parameters, but it's not clear what's the role of which > in this non-symetric operation and showing which one is `n` and which one is > `k` can be useful. IMHO code mining here is especially useful, as I said, when there are calls with many parameters and you need to know which parameter is what, rather than to document the contract of the call. In your BigIntegerMath example, if I want to know which is 'n' and which is 'k' I can look at the Javadoc. On the other hand, if I know the contract, it's not that useful for me to see code mining showing parameter names all around my code whenever I invoke BigIntegerMath.binomial(), because I do now what input1 and input2 are. And honestly, how often do you encounter cases like BigIntegerMath.binomial() in which you don't know what is what? Much different is the case when you have something like: MyClass.myMethod(int input1, int input2, String input3, boolean input4, Date input5, Date input6) and you start to have calls like: mc.mymethod(foo, bar, foobar, flag, meh, blah) perhaps even split on different lines: here it's easy to lose track of what "meh" is, for example (I usually go after the first "(" and type Ctrl+Space and then move with cursor through parameters to see which one becomes bold...). I know that having methods with so many parameters isn't best practice, but it happens. So, I think we're looking at this feature (parameter name code mining) from two different point of views. From mine, having the ability to set the minimum number of parameters after which the mining is shown would be useful, because when the number of parameters is 1, 2 or even 3, my code in the editor starts to look a bit crowded with low benefit.
> I mean, a call like "Period.between(today, anotherDay)" is enough simple to be auto-explicative even if parameter names are not shown, I think. I agree and one feature provided by JDT CodeMining is that codemining parameter name can be configured with "Show parameter only for literal" preferences. You can see a demo in: https://github.com/angelozerr/jdt-codemining/issues/45#issuecomment-402699202
