new Rule: ImmediateVariable / UseFunctionalInline

[Pankraz76]

kindly consider new rule or optional enhancement of DirectReturn to prefer inlined direct turn instead of ImmediateVariable regarding the same motivation as the original S1488 issue.

private FormatterFunc.Closeable toFunc() {
	var runner = new ProcessRunner();
	return FormatterFunc.Closeable.of(runner, this::format);
}

private FormatterFunc.Closeable toFunc() {
	return FormatterFunc.Closeable.of(new ProcessRunner(), this::format);
}

• https://docs.openrewrite.org/recipes/staticanalysis/inlinevariable
• https://sonarsource.github.io/rspec/#/rspec/S1488
• [java] New Rule: VariableCanBeInlined: Local variables should not be declared and then immediately returned or thrown pmd/pmd#5770
• Issue #16421: Local variables should not be declared and then immediately returned or thrown S1488 checkstyle/checkstyle#16488
• https://github.com/diffplug/spotless/pull/2702/files#r2486044966

[Stephan202]

Note that DirectReturn is a check provided by Error Prone Support, not Error Prone.

Looking at the linked PR, I don't think that this suggestion is an improvement in all cases. For example, here inlining would (a) increase nesting and potentially line-wrapping (not unlikely in general, considering e.g. GJF's rectangle rule) and (b) drop the descriptive variable name updateYear. The latter side-effect of inlining isn't a concern for the simple case of return varName, as one can reasonably expect that the method name clarifies what the inlined expression represents, but the same does not in general hold for subexpressions.

One could imagine a check that inlines single-use variables if that doesn't cause the resultant expression to reflow, but this (a) still suffers from the aforementioned caveat and (b) must make assumptions about the exact formatting rules in place.

Another approach could be to inline single-use variables only if their name merely conveys information also derivable from the assignment expression (as is arguably be the case here), but that requires making explicit what an uninformative variable really means, and even then the impact on formatting may be undesirable.

[graememorgan]

We have an internal check which suggests inlining variables which are immediately returned, but even that is quite opinionated and controversial. I don't think we'd want a check that suggested inlining single-use variables; even with some heuristics to try to make it seem reasonable, it would seem at best nitpicky, and there are a lot of reasons someone might want to extract a variable.