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)
