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

Reply via email to