Gus: When it comes to actually removing the necessity of suppresswarnings IntelliJ makes a lot of this much easier. The issue is that it’s too much work for any one person to have a hope of doing in any reasonable period without introducing errors.
There are just too many warnings for one person to have a hope of thinking carefully about all of them, so my strategy is to stop adding to the problem, raise awareness when it happens etc. I think to remove the necessity for SuppressWarnings will require extensive work, best approached over time, not in a huge wodge. Best, Erick > On May 11, 2020, at 9:25 AM, Gus Heck <gus.h...@gmail.com> wrote: > > I typically battle warnings by conquering one file/directory at a time... And > letting Intellij take me from warning to warning with F2 key really really > really speeds things up. This is a wider set than compiler warnings, but you > can customize it, and many of the additional warnings are auto-solvable > (things like redundant initializers for variables that are already assigned > before use), so the extra work is more than paid for by the reduction in > transition time. The key one to think carefully about is the one that wants > to minimize access, which is great for new classes, dangerous for released > classes. Perhaps turn that warning off in intellij... > > On Mon, May 11, 2020 at 8:14 AM Atri Sharma <a...@apache.org> wrote: > +1 to Erick’s proposal. > > I hate the number of warnings we get — we should still be formulating some > sort of a strategy to fix them. > > Atri > > On Mon, 11 May 2020 at 17:09, Erick Erickson <erickerick...@gmail.com> wrote: > Just disabling the warning globally nothing to prevent more being added. Take > raw types. They’re a compromise allowed by the java compiler explicitly to be > able to continue to use older binaries written before (or without) generics. > But take a look at SolrQueryResponse for instance. We explicitly declare: > > protected NamedList<Object> values = new SimpleOrderedMap<>(); > > but then declare a method: > > public NamedList getValues() { return values; } > > This is just bad practice. > > I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing that > I fix what’s easy, and suppress the rest. > > It might have been clearer if I’d said “Then start failing builds on any new > warnings of these types”. > > Oh, and I’m also thinking of changing my BadApple report to flag when new > SuppressWarnings are introduced and then nag people about new ones. > > > > > On May 10, 2020, at 11:43 PM, David Smiley <david.w.smi...@gmail.com> wrote: > > > > Can't we customize the linting to disregard entire categories of certain > > warnings for now? This makes your task manageable. > > https://discuss.gradle.org/t/recompile-with-xlint-parameters/25279 > > > > ~ David > > > > > > On Sun, May 10, 2020 at 10:41 PM Erick Erickson <erickerick...@gmail.com> > > wrote: > > I’m really struggling with what to do with compiler warnings, particularly > > all the rawtypes and unchecked warnings. > > > > On the one hand, the simple mechanical thing to do would be to > > SuppressWarnings on each one that exists presently. Frankly that feels > > pretty useless; that would preserve poor code forever. > > > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is going to > > be time consuming and error-prone. Especially since I don’t really > > understand all the nuances yet and learning them one by one will introduce > > serious errors without doubt. > > > > So here’s what I propose. Even though it feels useless, just > > SuppressWarnings on anything that’s not a simple fix. Then start failing > > builds on these warnings to catch any that come in in future. At least that > > way there’ll be some incentive to keep the code from getting _worse_, > > although people will still be able to just add SuppressWarnings to the mix > > I suppose. > > > > The number of raw NamedList member variables we have is overwhelming all by > > itself…. > > > > Comments? > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- > Regards, > > Atri > Apache Concerted > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org