LVTI Style Guide

Remi Forax forax at univ-mlv.fr
Fri Mar 23 17:02:18 UTC 2018


Hi Tagir,
there is also a notion of block of code,
alternating var definition and non-var definition make the code not really readable.

Rémi

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> À: "Stuart Marks" <stuart.marks at oracle.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Vendredi 23 Mars 2018 09:51:25
> Objet: Re: LVTI Style Guide

> Hello!
> 
> Thank you for this post. I was thinking about tuning our IntelliJ IDEA
> inspection "Local variable type can be omitted". Initially we enabled it,
> so every local variable type which can be replaced with 'var' was grayed
> out. Then Brian asked us not to do this, as many people just blindly apply
> the quick-fixes the IDE suggests. Now by default we display no
> highlighting, but quick-fix can be invoked from the drop-down menu. Still I
> think that we may have some intermediate solution when 'var' is suggested
> by default only in some places where it's applicable. My current thought is
> to limit default suggestions to these cases:
> 
> * when the variable initializer is a new expression.
> * when the variable initializer is a static method, and its containing
> class is the same as the return value erased type.
> * when the variable initializer is an instance method and its name is
> "getXyz" where "Xyz" is the simple class name of the return value erased
> type.
> * when the variable initializer is a String/char/boolean constant.
> 
> More questionable:
> * when the variable initializer is a String/boolean expression
> * when the variable initializer is a conditional operator and both branches
> are satisfied by any of these rules
> 
> Even more questionable (too much magic):
> * when the variable initializer is a method which name is "getFoos" where
> "Foos" is the plural form (according to English grammar rules) of the
> declared variable name "foo" and type is either "Foo[]" or inheritor of
> "Iterable<Foo>"
> 
> Of course, this list is preliminary. If you have suggestions what to add or
> what to remove here, feel free to comment.
> 
> The main concern we have is that the default behavior might look confusing
> for users: why var is suggested in one place, but not suggested in the
> other. So we probably should not make this feature too magical. Instead it
> should follow a clear list of rules which could be documented. Also there
> are open questions, whether we should have three modes ("never suggest
> var", "suggest var in some cases", "suggest var everywhere where possible")
> or more fine-grained setting like additional levels to include questionable
> cases or even set of checkboxes.
> 
> Please share your opinions on this! Probably there should be an official
> recommendation from JDK team to IDE authors (not only IntelliJ) on whether
> the 'var' suggestion is considered a good style.
> 
> Thank you,
> With best regards,
> Tagir Valeev.
> 
> On Fri, Mar 23, 2018 at 1:15 PM, Stuart Marks <stuart.marks at oracle.com>
> wrote:
> 
>> Hi all,
>>
>> I've posted a style guide for LVTI:
>>
>>     http://openjdk.java.net/projects/amber/LVTIstyle.html
>>
>> There has been quite a bit of chatter about LVTI surrounding the Java 10
>> release. This has tended to obscure thoughtful conversations that
>> programmers need to have regarding when and how to use `var` effectively on
>> their projects. This document is an attempt to provide a head start in
>> those conversations.
>>
>> Enjoy,
>>
>> s'marks
>>


More information about the amber-dev mailing list