Results of the Sun Checks on my code
CheckStyle – Enforcing a coding style: part 1

CheckStyle – Enforcing a coding style: part 1

This entry is part 1 of 4 in the series Implementing a Java code style with CheckStyle

Implementing a Java code style with CheckStyle

The easy way – Using someone else’s rules.

As my little tutorial project was going along, I started to realise that I really wasn’t doing a very good job of getting consistency in my code. Whilst I don’t have to worry about reviewers struggling through pull requests littered with formatting changes, I do care about the quality of my work. A while back I sent the following tweet:

 

And I still hold to this. I aim to keep my code above the standard of my development team. Given my lack of experience as a developer, that means using every tool in the automation armoury to help me achieve this.

So even though this is being written late at night when everyone else is asleep, no excuses here either. Time to sort out and enforce a code style. If Google have their own official java code style so should I.

There are a number of questions around this of course in a project.

  1. What code style should I use? Adopt a published scheme – or make my own.
  2. In a team of course you have to get buy in and somehow get a group of developers to agree to one.
  3. Then you just have to configure a tool to enforce your codestyle.

Coding in the java world, number 3 at least has an easy choice. CheckStyle is actively developed, well supported on Intellij IDEA, Eclipse and NetBeans as well as having plugins to work in Gradle, Maven and Ant.

In a real project, especially one that has been running for sometime and has a large code base with no agreed standard, number 2 really is the tricky one. You have to first of all get buy in from the development team on the idea, and then you have to actually reach an agreement between the team on what rules to apply. Of course the pain doesn’t stop there, as you then have to work out how to fix the probably very large number of issues without grinding all other development to a halt!

Most plugins come with a couple of useful code styles out of the box:

  • Sun checks: The somewhat dated (1999), but still current ‘official’ java language conventions.
  • Google checks: need I say more.

So the simplest approach would be to pick one and run with it, so I started out by installing the Checkstyle-IDEA plugin in IntelliJ IDEA.

CheckStyle-IDEA plugin

Then just restart IntelliJ IDEA and go to configure the plugin.

First thing to note here: Recently produced rules files will not load if the CheckStyle version is set below v8.1, So first of all, set this to 8.4 (The current version) and click apply before attempting to set a new configuration file.

Easy as you like. So what does it make of my code with the Google Checks?

Results of the Google checks
Results of the Google checks

281 problems to fix. That’s quite a lot for a small project, but that’s not my problem with it. I see that they have indentation level rules. I think I’ll pass on that. So what about the Sun Checks?

Results of the Sun checks
Results of the Sun checks

OK, 109 problems. That looks more like it. Note how this gives the problems as errors (red) rather than the warnings that the Google Checks produce. It doesn’t make any difference here, but it can do if I start running the checks as part of my build. Much as I dislike writing Javadoc, I guess as this project is in the public for anyone to use, I guess I should document it properly. I suspect that there are other things that I might prefer to control too.

There is a third rule set within the CheckStyle code base; the one they use themselves. This also acts as an exemplar of how to configure your own rules. I did try setting this one up in the plugin too, but it requires you to set 6 properties of other configuration files.

CheckStyle Checks required properties
CheckStyle Checks required properties

I could have copied over their default values, but I think I’ll leave that for now. It does give you some idea however of how flexible and powerful CheckStyle is.

Progress made:

  • CheckStyle-IDEA plugin configured and my code checked against Sun and Google checks.

Lessons learnt:

  • I don’t like the indentation rules in the Google checks.
  • The Sun Checks look like a good starting point, but I think I want to add some more.
  • I am likely to have a couple of hundred or so fixes to make in my code.
  • As CheckStyle’s own rules show, there are clearly a lot of configuration options available

Next time I will be writing my own rule set and configuring Gradle to enforce it on build. How hard can it be?

Series NavigationCheckStyle – Enforcing a coding style: part 2 >>

One thought on “CheckStyle – Enforcing a coding style: part 1”

  1. Pingback: CheckStyle – Enforcing a coding style: part 2 – Alexander on Testing

Comments are closed.

Comments are closed.