Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. By default it supports the Google Java Style Guide and Sun Code Conventions, but is highly configurable. It can be invoked with an ANT task and a command line program.
pbludov on issue-7309-fix-tc-inspections
Issue #7309: fix teamcity inspe… (compare)
pbludov on issue-7309-fix-tc-inspections
Issue #7309: fix teamcity inspe… (compare)
pbludov on issue-7309-fix-tc-inspections
Issue #7309: fix teamcity inspe… (compare)
pbludov on issue-6916-checks-ann
Revert "config: disable functio… config: fix issue with shippabl… infra: add cat after grep to co… and 4 more (compare)
pbludov on issue-6916-checks-ann
Issue #6916: migrate tests to j… (compare)
pbludov on issue-6916-checks-ann
Issue #7117: fix package info j… config: update 'verify-no-excep… Issue #6916: migrate tests to j… (compare)
pbludov on issue-6916-checks-ann
Issue #7299: remove build for o… Issue #6916: migrate integratio… Issue #6916: migrate tests to j… (compare)
pbludov on issue-6916-junit5
pbludov on issue-7129-ja-lang
pbludov on issue-7144-avoid-star
pbludov on issue-6316
pbludov on issue-7185-header
pbludov on issue-6724-summary-loc
pbludov on issue-6724-content-loc
pbludov on issue-7281-jdk13
pbludov on issue-7299-drop-jdk9-10
pbludov on issue-6916-junit5
Issue #6916: migrate integratio… (compare)
pbludov on issue-6916-junit5
Issue #6916: migrate integratio… (compare)
pbludov on issue-7299-drop-jdk9-10
Issue #7299: remove build for o… (compare)
pbludov on master
Issue #7281: set up jdk-13 buil… (compare)
bug pattern
it sounds like you just want descriptions of properties and/or checks? The only way to retrieve them is by looking at our xdocs, which isn't attached to any JAR as far as I know. You could automate pulling them in like we do validating their existence and types. See https://github.com/checkstyle/checkstyle/blob/master/src/test/java/com/puppycrawl/tools/checkstyle/internal/XdocsPagesTest.java .
baseDir
in the Checker configuration.${propertyName}
.
-f xml
?
@romani - yeah, that's basically what we're doing, with just a bit more of a manual process. We are checking in the violations and then any updates to that file result in a change in SCM, and we call it out on PRs and things like that.
Setting up a file to be a suppression would be a great idea, but I wonder if it's feasible since changing code around something would cause the lines where the violations that occur to be changed.
interesting. So you could have a build that produces the "suppression" file that could then be fed back into future builds.
I think this would work well. The only thing that I would say that would beneficial with this is to have some way of notifying if there was an unnecessary suppression. It would help to identify situations where an issue has been fixed but the suppression file wasn't updated.