Preventing worst practices in Java, the hard way

Question

Given that the concept of "best" and "worst" practices can be different in different environments, our company introduced a standard set of internal "best" practices that are continuously violated by our developers. I want to share two in particular:

• Never handle exceptions with ex.printStackTrace(), instead log them
• Never use System.out in a web application for debugging purposes, better use debug log

These two are fairly simple to detect as a simple Search command can display each violation.

I'd like to ask if anything can be done to prevent the coder from using these prohibited methods in his projects. Forcefully deprecating the System.out object or the printStackTrace method from out of the standard JVM would be a great idea as provides evidence of the mistake in the form of a warning.

Since we don't implement a human code review mechanism (code is reviewed only when issue arise, or a new developer takes charge of a module), I'm seeking for automated ways of preventing such common mistakes, including breaking the compilation itself. I'm thinking about something like a Java plugin in which I can configure special rules for what that is not an error in Java syntax to be considered as an error. ReSharper plugin for Visual Studio, for example, does a similar thing when dealing with naming and coding conventions.

Answer 1

The rules you have provided well known good Java coding practices. There are already available tools that can check your code and make sure these rules are not violated.

PMD has the rules you are looking for:

• Never handle exceptions with ex.printStackTrace(), instead log them - AvoidPrintStackTrace

• Never use System.out in a web application for debugging purposes, better use debug log - SystemPrintln

Answer 2

You could use checkstyle's regexp checks to fail anything containing System.out, or printStackTrace. There are some unlikely corner cases where it could produce false positives/negatives (e.g. if there were other types with a printStackTrace method).

Answer 3

You can use PMD and especially the rule AvoidPrintStackTrace to solve your specific problem.

PMD can be configured with your Sonar or Jenkins together with a bunch of other good rules/restrictions.

Answer 4

You could write a custom detector in FindBug and integrate it with your build. I found a link to write custom detector in FindBug

Answer 5

There are various style and bug checkers that can be tailored to detect custom style violations. Some can even be integrated with your company's preferred IDE.

But that doesn't solve your problem. If people are wilfully ignoring style rules, then politely asking them to run a style checker from their IDE isn't going to work.

I can think of two approaches that may work for you:

• Set up a continuous integration (CI) server, configure Sonar analysis and reporting, and include your style checks.

• Configure your version control system to run the style checker as a check-in hook. Get it to reject check-ins that increase the number of style violations.

The first approach can still be ignored by recalcitrant developers, but the evidence of the violation of company standards will be plain to see.

The second approach borders on "fascist" ... but if that is what it takes to get people to toe the line, then all you need is rock solid management support and a thick skin :-)

---

The other way to look at this is that this is a problem for developer team management, or higher up the food chain. If there is no culture of quality among your developers, this is a problem that management needs to address. And if they won't address it, then you need to step carefully with your co-workers.