Add a task which checks for format compliance

[nedtwigg]

The format task applies the format, which is great.

It would be awesome if there was a checkFormat task, which was added as a dependency to the check task, but only threw errors / warnings without actually applying those changes.

The license-gradle-plugin works this way. If you want to tinker with it on a super-simple example project, it is used here.

This makes it easy for someone to see that they have a formatting problem when they run gradlew build, and gives them a chance to commit their changes before running the format, which might make changes they'd like to disable with a pair of @formatter:off/on tags.

I think this could be achieved by looking at the value of the TextEdit which is generated by the formatter.

[youribonnaffe]

I agree it would make sense (the format is actually not executed by default in our build to avoid this kind of problems with commit changes).
So a task checkFormat that would fail if changes should be applied.
Do you think it should produce the formatted files somewhere in build/ folder (to help diff with the actual code maybe) ?

I did not get your point about @Formatter tags, would you mind to explain it into more details please?

[nedtwigg]

If you have a block of code with weird spacing that violates your format, but you'd like to preserve it (maybe as ASCII art comment), you can add // @formatter:off before the special spacing, and then // @formatter:on after the spacing to disable and then re-enable the Eclipse code formatter for that one little chunk.

Personally, I always make a commit before I run the formatter. Then I run the formatter, and look at the diff. If there's a piece I don't like, I restore that part and wrap it in formatter tags.

I think the biggest usage of the checkFormat task will be enforcing coding styles for pull requests and continuous integration setups. I'm not sure what the performance penalty of applying the edit and saving a copy to the build folder would be, but I imagine it's not trivial for a large project.

The most common format enforcer people are using these days is checkstyle, which hooks into the check task. It's a pain for contributors though, because you've got to fix violations manually.

Your plugin is great for contributors because they can fix violations automatically, but it's pain for library maintainers because there isn't an easy way to check for compliance.

With this feature, I think your plugin would be the undeniable best option.