> I would like to remove this altogether from tests and ban it too in a week or > two. Don't think we had clear consensus here.
On Sun, Jan 5, 2025, at 5:42 PM, Štefan Miklošovič wrote: > I would like to remove this altogether from tests and ban it too in a week or > two. > > I see that Berenguer and Ariel are against that completely and Maxim as well. > > I was waiting for some time to see if the usage of this takes place so we do > not ban that for people who might use that prematurely but I just don't see > that happening. > > On Tue, Nov 5, 2024 at 11:25 AM Maxim Muzafarov <mmu...@apache.org> wrote: >> To me, this sounds like the style consistency throughout the project, >> so if we just allowed having the "var" keyword we would have a mix of >> new and old styles without any distant prospect of a unified style. >> >> We should evolve the code style from one unified form to another, thus >> either we use it everywhere and fix all the places where it's >> applicable, or forbid it, avoid having "mixed" styles. If everyone >> coded the way they liked, it would be a mess. >> >> I would vote -0.5 to allow it, and +1 to forbid it everywhere. >> >> On Tue, 5 Nov 2024 at 00:02, Štefan Miklošovič <smikloso...@apache.org> >> wrote: >> > >> > People who are OK with vars in tests - are you also the ones who are going >> > to write vars from now on yourself or you just do not mind if you >> > encounter it? >> > >> > There is a difference between >> > >> > "keep it in tests, I am going to use this, this is actually a good idea" >> > >> > and >> > >> > "keep it in tests if people are going to use it, I do not mind but I am >> > not going to change my style". >> > >> > If the latter is the case, then who is actually going to write tests on a >> > daily basis with vars? If one or two people then I guess it does not make >> > a lot of sense to keep it around. >> > >> > On Mon, Nov 4, 2024 at 11:10 PM Ariel Weisberg <ar...@weisberg.ws> wrote: >> >> >> >> Hi, >> >> >> >> I don’t like `var` anywhere. Even if IntelliJ could automatically insert >> >> the concrete type it would still be a problem in the GH compare view. GH >> >> compare view is a real problem, because any time something is >> >> sufficiently obfuscated I have to bounce back and forth with an IDE, >> >> check out the code etc or just proceed with a weaker mental model of what >> >> is going on. >> >> >> >> I have finite mental energy to expend every day and I don’t want to spend >> >> it hunting down and then recalling what each instance of var means >> >> repeatedly. It uses almost no energy to read past extra type information >> >> (formatting means I don’t even need to parse it) or do a little extra >> >> typing/autocomplete >> >> >> >> Ariel >> >> >> >> On Tue, Oct 29, 2024, at 1:13 PM, Štefan Miklošovič wrote: >> >> >> >> Hello, >> >> >> >> this should give you an idea >> >> >> >> grep --include '*.java' -r 'var ' src/ test/ >> >> >> >> I think this is a new concept here which was introduced recently with >> >> support of Java 11 / Java 17 after we dropped 8. >> >> >> >> What is your opinion? Are we free to use it wherever we want? I am quite >> >> conservative in this area and I will most probably still use types as we >> >> know them but maybe in tests we might relax it a little bit? Or >> >> production code with "var" is totally fine too without any concerns? I >> >> think this should be covered by the code style. >> >> >> >> Regards >> >> >> >>
