Last week I introduced Checkstyle to our team. I had enough of correcting all the code that was written in a totally different style.
We already had Sonar, so the real smells as errors were found but the code did not look consistent at all.
So we sat down and made our own Checkstyle ruleset together.
After that we imported this ruleset into everyone's IDE and we put the checkstyle-plugin to the project's pom, so no one would be able to successfully finish a Maven build if there are violations.
To mention a few, we included these:
- 4 spaces instead of a tab
- Javadoc
- avoid trailing spaces
I know it was a bit harsh and the first week was a pain in the neck.
Why? We were not used to write Javadoc comments at all. Spaces were everywhere. Tabs were used.
So we decided to work on the Eclipse autoformat ruleset and when it was ready, we shared it with every team member.
It became a lot easier but it did not solve the Javadoc problem.
No worries, we made it, corrected every file, class and method.
Conventions are needed so the code at least looks consistent.
Now as the secod week started, we can see that we should make some minor modifications to refine this ruleset, but I guess it is normal.
Anyway I love this idea, and I planning to introduce similar tools for CSS, too.
So do you use Checkstyle or other syntax checking tools? Or are you planning to use one?
Latest comments (6)
yes, we’ve used php-cs-fixer when I was working with php and now Im using github.com/checkstyle/checkstyle, on an isolated project, though my new team is yet to be convinced about need of automatic code formatter/checker
C# has StyleCop, which is amazing. Visual studio will also recommend C# 7 syntax improvements by default and has a static code analysis tool built in.
Css has stylelint, which is okay.
As others have said, ESlint is great for JS. I like Typescript too - don't need to actually use TS syntax to get benefits. Webpack or another tool that expects modular code helps with devs making architectural mistakes (things that would be possible with grunt, for example).
There are some VS extensions for SQL, but the tooling isn't using roslyn, so not friendly.
Generally, editor.config is an additional option.
For javascript, eslint is a must, it also catches errors in addition to syntax issues. Recently, I hooked it up to prettier, I like it. But as coding styles are ultimately opinionated, there are some conflicts between prettier and eslint (airbnb version), but you can still use prettier for style issues, and eslint still can catch a lot of coding issues.
I use ESLint and Jetbrains IDEs to import my rules into the editor and the
Code -> Reformat Codemenu.I put the eslint command in my
package.jsonscripts so it can be run easily off the local install. This can be added as an npm run config in IntelliJ to make it just a dropdown away.I'm also really tempted to write a precommit hook at work to run
npm run eslint -- --fix e2e-tests/**just to get people to actually run the thing often 😛My rules are to extend the Google Style Guide, change a few things to be more ES5 friendly (allow var, define the version to be 5), remove the requirement for JSDocs, and add another rule to require new lines after variable declarations.
If you're talking about style checking generally, I definitely think linting and style checking is important for readability and light error checking. I use pylint for python, shellcheck+shfmt for POSIX shell scripts, and I appreciate how formatting in pretty built into Rust.
I have not found a C/C++ tool yet that I like, which is unfortunate as people can do some horrible stuff with whitespace in those languages.
I use PHP+Laravel, and
php-cs-fixeris my preferred setup. As for the rest of the stack, I just hook up Prettier and hope for the best. I'm still considering options to automatically run these for pull requests and such. Kinda tiresome to open a file, do nothing, and then see changes are being made since it didnt adhere to the standard in the first place