LVTI Style Guide

[Zheka Kozlov]

What about this:

   - Suggest using var for generics (List<String>, Map<String, String>,
   PriorityQueue<Integer> etc).
      - When a diamond operator is used, it is replaced with an explicit
      type after refactoring.
      - Users should be able to turn off this in preferences.
   - Suggest using var for type names longer than X characters (X should be
   configured in preferences).
   - Never suggest var for primitives (they are already very short).


2018-03-23 15:51 GMT+07:00 Tagir Valeev <amaembo at gmail.com>:

> 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
> >
> >
>