This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: Help Improve your Coding Standards
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
I have recently started using the CheckStyle plugin for eclipse. When I initially installed it, nothing happened. I was slightly surprised I thought the code would have flagged a few areas for improvement.
aha, I then found out you that you had to turn it on, I wonder why they would code it like that. I turned it on and baam, yellow highlighter everywhere and I mean every where, practically on every line. Now I understand why you have to turn CheckStyle on.
CheckStyle to people who don't know, it is an open source (free) tool that helps coders to write code to certain standards and also stick to various best practices. For companies who have a number of developers working on the same code, standards can be a vital area, particularly if individual developers all code to different standards.
I often had a disagreement at work with the placement of brackets on if statements
I use to like this style
if (true)
{
//some code here
}
else
{
//the else code here
}
In the end we settled the dispute by going with the Java coding standard, I still think the code above is easier to read because the brackets match up. Still before we came to a truce and the second style was chosen I wrote code with brackets seen in the first version. Now when I come to check the code I have written the first thing I notice is the brackets are all in the wrong place. This is just one trivial problem but if you have many different coding standards and styles then when you have to fix a bug in another developers code you can waste a lot of time just trying to decipher the strange looking code (compared to your style) and merely trying to understand what is actually happening before you can even work on diagnosing the problem.
This is where CheckStyle comes in. When you are writing new code it warns you to put a JavaDoc comment in, it gives you warnings about naming conventions and placement of brackets and numerous other rules. The result is if everyone in your team used CheckStyle then you would end up with similar looking code and written to meet certain standards. I can certainly see the benefits if you work somewhere where people leave and join frequently.
Some of the rules and standards in CheckStyle might be a bit to strict or you may disagree with them. I am currently removing the rules which I don't think are relevant or are a bit over the top and hopefully I will end up a set of rules which I can get the other developers to use.
As I mentioned early using CheckStyle with legacy code can be a bit of a nightmare because it will flag up hundreds of warnings. It is a similar situation to when you start thinking about implementing unit tests, you look at your legacy code and think where do I start and then think there is so much unit tests to write is it worth (is it possible). Using CheckStyle with Legacy code can be almost impossible. My advice is to turn it on and then slowly change a few lines to conform to the rules and just do a bit at a time but don't spend all morning trying to get your code up to the Check Style standards. You could implement a limited set of rules for legacy code so that it is up to a certain level. I do think its worth changing the code and setting it in the right direction, you will feel the benefit later on where you see code that all looks the same and you can just concentrate on the logic not the syntax.
Finally there are some of the rules that make you write good code. Here are some of the features I like
Checking for duplicate code
warning if variables aren't used
making incoming parameters final
checking for magic numbers
making sure brackets are placed in the correct position
making me write JavaDocs (so I don't have to do them all at the end)
making sure you code adheres to sun naming conventions
There are many more but it certainly makes you think when you are coding and I have found that I am now wanting to write code that passes all the tests and I probably wouldn't write code that met such standards if I didn't have CheckStyle nagging me to change it.
If you are interested in CheckStyle here is a link to the eclipse plugin
Previous Topic
