+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
