Skip to main content
search
Blog

JavaOne – Day 2 – Code quality: Getting Started

By 27 oktober 2015januari 30th, 2017No Comments

Bad Source Code[7]During my years of developing Java applications I’ve become more and more aware of the quality of code and tools than can assist in creating better code. I always try to attend session concerning this topic. On day 2 of JavaOne there was one session on this subject. “Stop the Rot: A Discussion on Maintaining Java Software Quality”, which was a discussion on code rot and how to prevent it.

For me personally this session was kicking in open doors. But as code rot is always a hot topic, sessions like these are important. There are always developers which need pointers, help and advice on how to prevent code rot.

Technical debt versus code rot

One of the important aspects that the discussion tried to difference between is code rot and technical debt. There are people who interchange these two while they are indeed totally different concept. I try to explain my personal vision on both of them to set the differences.

Technical debt

Technical debt is a consequence of system design, software architecture or software development within a code base. The latter contributes to code rot, but we will talk about that in a little. Technical debt is something that can be done before a job is marked as “completed” or “proper”. Technical debt makes it difficult for code the be maintained in a later stage. Technical is not necessary a bad thing, technical debt is often required to move a project forward. Debt with changes in the code base is created then you have to fix an issue in a certain part of the application. This change then requires you to make undocumented changes in other parts. Each change adds “interest”.

Causes of technical debt:

  • Pressure from the business (or stakeholders) to deliver on time.
  • Lack of knowledge
  • Delayed refactoring
  • Lack of documentation

Code rot

Code rot is something that slowly creeps into the software. It has a strong connection to Technical debt. The slow deterioration of the code can have major impact on the application, often leading to faulty software, unstable software and performance issues. The code is then often called “legacy” and people want to “upgrade” (replace) the software altogether.

Causes of code rot:

  • Changing environment. Unanticipated changes. For example being CPU clock speed bound.
  • Onceability. Users not being able to restore the application into working state.
  • Unused code. Portions of code that were once used, but because of changes no longer is.

Tools to prevent code rot and technical debt

Preventing both is a difficult task. It requires a lot of effort from the developer to take care of the code. In some instances it is not only the developer, but the entire team that contributes to both. A low-hanging fruit to prevention is the use-age of several tools that can analyse your code. Even with these tools it can be hard to prevent both. You need time to put effort into fixing issues that are present. Below is a set of different tools which can be used to prevent technical debt and code rot.

FindBugs

FindBugs is a static code analysis tool which detects possible bugs in Java programs. FindBugs does not scan the source code, but rather the bytecode. FindBugs is wildly supported on different platforms through plugins. There are also plugins for build servers like Jenkins. FindBugs ranks bugs in 4 categories. From top to bottom the ranks could be stated as “Fix this immediately” to “take a look at it and decide for yourself”.

  • Scariest (I)
  • Scary (II)
  • Troubling (III)
  • Of concern (IV)

Level I and II issues are most often noted as errors within your IDE, while level III and IV are noted as warnings. You can, of course, modify the severity level of each individual level. FindBugs often gives additional help or pointers on how to avoid the issue found. For example inferring string equals.

CheckStyle

Checkstyle is probably not a tool to directly prevent bugs. It helps creating consistent source code by validating it to a set of rules. When a piece of code does not apply to the rule a warning will be shown. Each warning should be evaluated and fixed, as you do not comply to it and possible the coding standard set for the entire company. Having consistent code formats helps other developers maintain the code, as it is easily readable. Besides finding coding style issues, checkstyle can also find duplicate codes and extremely complex pieces of code.

PMD

PMD is a same type of tool as FindBugs. The difference is that PMD checks in the source code and is able to find a lot of other errors, like violation of naming conventions, missing curly braces, unnecessary constructors, missing breaks in a switch. PMD and FindBugs can be used next to each other as they often find different bugs.

Conclusion

These tools are great fo reducing code rot and technical depth. However, what is perhaps more important in the long run for software quality is better understanding of the technology (eg. Java, API’s and frameworks). To create this understanding you need to research a lot, exchange knowledge with expirience engineers and have in-depth experiments with code.  In other words: improving your software craftmanship!

Code Quality by XKCD

Sources getting you started in creating better code:

The tools:

Sources:

 

Terug naar overzicht