+1 thanks huge step forward for code hygiene Maybe someday we will agree on a minimal check style enforcement too š® ... Sorry, too soon?
On Tue, Jun 23, 2020, 6:21 PM Anshum Gupta <ans...@anshumgupta.net> wrote: > Thanks, Erick! This is awesome :) > > On Tue, Jun 23, 2020 at 2:18 PM Erick Erickson <erickerick...@gmail.com> > wrote: > >> As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if >> there are any warnings in the code. See LUCENE-9411. Iāve finally finished >> suppressing over 8,000 warnings in Solr, so could check this in. Many >> thanks to Dawid for helping me with the Gradle parts. The goal now is to >> not add any _more_ SuppressWarnings if at all possible. I hope we can start >> taking the suppressions out when weāre working on code, so when working on >> code please consider removing some of them. >> >> I was hoping that we could also fail ant builds, but there are some >> tricky dependencies in third party code that werenāt easy to resolve in the >> ant world due to licensing issues, if youāre interested in details, see the >> JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail >> on warnings, neither will Ant builds on 9x. If someone wants to try working >> that out, please feel free but Iām just really tired of banging my head >> against that wall. >> >> So please, Please, PLEASE start compiling 9x with Gradle or cover your >> ears to keep from hearing me complain. And Iāve been taking lessons from my >> 3 1/2 year old grandson on doing that LOUDLY. >> >> About SuppressWarnings. There were so many of them that there was no hope >> of actually fixing the underlying causes in one go. Iāve enhanced the >> BadApples report to start reporting on the number of SuppressWarnings in >> each file week to week when they increase or decrease. Iāll be nudging >> people if the number of SuppressWarnings starts going up, starting Monday. >> I canāt help but think understanding generics will be improved by working >> through new warnings. >> >> A couple of side notes for IntelliJ users (IDK about other IDEs, but Iād >> be surprised if there werenāt similar capabilities): >> >> - When you just open the project, Gradle is automatically configured. >> Thereās no need to execute the āgradlew ideaā task. >> >> - You can execute tasks in IntelliJ _really easily_ by clicking on them >> in the gradle window, itās on the extreme right. It seems much more robust >> than trying the same thing in Ant. >> >> -- The āassembleā task will bring up a convenient window showing errors >> (including warnings) that you can click on and get right to the offending >> code. āclassesā and ātestClassesā are also very useful tasks to execute in >> this context. >> >> - The āinspectionsā in IntelliJ point out a lot of things, but not >> anything with SuppressWarnings. It may be worth coming to consensus on >> which inspections are worth enabling. And perhaps distributing a >> configuration. For instance, do we really care for inspections reporting >> āblah could be finalā? Theyāre highlighted in yellow in my setup, and Iāve >> done nothing special. Spend some time looking at those when youāre working >> on codeā¦ the number of āmethod may return nullā inspections is scary. Have >> weāve ever had the released code generate an NPE or anything like that >> <snark/>. >> >> - Please do NOT suppress the _inspections_ in IntelliJ. One of the >> choices IntelliJ offers is to suppress an inspection, and it adds a >> āsuppressInspectionā comment to the source code specific to IntelliJ. This >> is different than Javasās SuppressWarnings, and we shouldnāt include >> comments in the code specific to a particular IDE. >> >> - The motivation here is that we need all the help from the compiler we >> can get when it comes to as large and complex a code base as Lucene/Solr. >> Yes, it feels constraining. Yes, it means we wonāt feel as productive >> because we have to take time to address things weāve been ignoring. The >> leap of faith is that if we spend a bit of time up front, we can avoid >> having to spend a lot _more_ time fixing errors later in the release cycle. >> The time it takes to fix a problem goes up exponentially the farther down >> the cycle itās caught. Fixing something when developing may take T minutes. >> Some time later when test start failing, it takes T*X. And when you >> consider community-wide implications of releasing code, getting feedback >> from the field, filing a JIRA, trying to reproduce the problem, checking >> the code, and pushing a fix, the cost of fixing something after itās >> released goes up enormously. Iām not saying that addressing all the >> complaints something like IntelliJās inspections show will magically make >> it unnecessary to make point releases, but avoiding just a few is a win. >> <rant/> >> >> Erick >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > Anshum Gupta >
