Maybe. Maybe not. I don't think most of these can be simply assumed to be correct. For instance "Unnecessary parentheses" can nonetheless be extremely helpful in clarifying code. Removing them is in no way a best practice. Sometimes it's a good idea. Sometimes it's actively harmful. The same is true for a lot of other static analysis rules. Human attention is necessary.
On Mon, May 19, 2025 at 7:37 AM Vincent Potucek <vpotu...@me.com.invalid> wrote: > > Hi Devs, > > hope you doing well. > > We’re currently facing real production bugs, along with approximately 500 PMD > and 300 SpotBugs violations. This clearly exposes a gap in our current > Definition of Done, especially regarding best practices and principles like > convention over configuration, maintaining code quality, and aligning with > industry standards. > > It’s the past calling—demanding attention and refusing to be ignored until > properly addressed. > > While static code analysis isn’t new to us—we already use Checkstyle and > Spotless—these tools alone don’t cover the full range of potential issues. > Each having its own strength, chaining them together ensures broader, more > effective coverage. > > To that end, the current PoC reintroduces PMD to help enforce Java best > practices. By suppressing the existing 483 PMD violations, this change > enables us to merge the configuration without blocking ongoing > development—while still preventing new violations from being introduced: > > 🔗 Enable PMD with suppressed existing violations > <https://github.com/apache/maven/pull/2331> > The following PRs address individual violations—most of which can be easily > fixed with IDE support: > > 🔗 PR 2350: UnusedAssignment <https://github.com/apache/maven/pull/2350> > 🔗 PR 2349: UnnecessaryParentheses <https://github.com/apache/maven/pull/2349> > 🔗 PR 2348: UnnecessaryFullyQualifiedName > <https://github.com/apache/maven/pull/2348> > We increase both quantity and quality by locking in the current state and > enforcing stricter standards moving forward. This allows us to stop > regressions now and tackle legacy issues incrementally after integration. > > Please don’t think of best practices as vague recommendations—they are > settled standards embraced by a wide community. The real question is: do we > want to align with common code quality standards and industry norms? > > Exceptions will be allowed using suppressions whenever justified. > > > > Kindly request your feedback, thanks for attention. > > > > Best regards > > Vincent > > > > PS: > > In reality, you don’t notice these tools until problems arise. > > It’s like karma—silent and harmless until you break something. Then it comes > back to show its cost. > > Just want to limit this. Currently, there’s no limit, and things are going > out of control. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
