I agree with Elliotte and his example with parenthesis. I do not
consider "unnecessary parenthesis" as a violation, since they sometime
improve code readability. The last time that I used PMD in a big project
(years ago), we had thousands of warnings reported as "violations" that
we considered as false positives. We abandoned the use of PMD because
the filtering of the false positives was too much effort. We could have
keep PMD for a few major rules for which violations are almost always
real errors, but those PMD rules are not so numerous and many of them
are already covered by javac warnings.
It does not mean that PMD is bad. I have nothing against PMD if someone
is willing to maintain its use. But I suspect that the 500 PMD
violations may include a lot of false positives, so fixing all
violations should not necessarily be a goal.
Martin
Le 2025-05-21 à 00 h 06, Elliotte Rusty Harold a écrit :
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
