(sorry for the double-post) Jeremy Hanna kicked this link to a style guideline re: inference my way. Interesting read for those that are curious: https://openjdk.org/projects/amber/guides/lvti-style-guide
On Tue, Oct 29, 2024, at 2:47 PM, Josh McKenzie wrote: > To illustrate my position from above: > > Good usage: >> Collection<String> names = new ArrayList<>(); > becomes >> var names = new ArrayList<String>(); > > Bad usage: >> Collection<String> names = myObject.getNames(); > becomes >> var names = myObject.getNames(); > > Effectively, anything that's not clearly redundant in assignment shouldn't > use inference IMO. Thinking more deeply on this as well, I think part of what > I haven't loved is the effective splitting of type information when > constructing generics: > >> Map<InetAddressAndPort, RequestFailureReason> failureReasonsbyEndpoint = new >> ConcurrentHashMap<>(); > vs. >> var failureReasonsByEndpoint = new ConcurrentHashMap<InetAddressAndPort, >> RequestFailureReason>(); > > I strongly agree that we should optimize for readability, and I think using > type inference to the extreme of every case where it's allowable would be the > opposite of that. That said, I do believe there's cases where judicious use > of type inference make a codebase *more* readable rather than less. > > All that said, accommodating nuance is hard when it comes to style > guidelines. A clean simple policy of "don't use type inference outside of > testing code" is probably more likely to hold up over time for us than having > more nuanced guidelines. > > On Tue, Oct 29, 2024, at 2:19 PM, Štefan Miklošovič wrote: >> Yes, for now it is pretty much just in SAI. I wanted to know if this is a >> thing from now on or where we are at with that ... >> >> I am afraid that if we don't make this "right" then we will end up with a >> codebase with inconsistent usage of that and it will be even worse to >> navigate in it in the long term. >> >> I would either ban its usage or allow it only in strictly enumerated >> situations. However, that is just hard to check upon reviews with 100% >> accuracy and I don't think there is some "checker" to check allowed usages >> for us. That being said and to be on the safe side of things I would just >> ban it completely. >> >> Sometimes I am just reading the code from GitHub and it might be also tricky >> to review PRs. Not absolutely every PR is reviewed in IDE, some reviews are >> given without automatically checking it in IDE too and it would just make >> life harder for reviewers if they had to figure out what the types are etc >> ... >> >> On Tue, Oct 29, 2024 at 7:10 PM Brandon Williams <dri...@gmail.com> wrote: >>> On Tue, Oct 29, 2024 at 12:15 PM Štefan Miklošovič >>> <smikloso...@apache.org> wrote: >>> > I think this is a new concept here which was introduced recently with >>> > support of Java 11 / Java 17 after we dropped 8. >>> >>> To put a finer point on that, 4.1 has 3 hits, none of which are valid, >>> while 5.0 has 172. If 'sai' is added to the 5.0 grep, 85% of them are >>> retained. >>> >>> Kind Regards, >>> Brandon >
