Improving Code Consistency and Standards Compliance with Eclipse Preferences
There are a few themes that recur frequently when discussing software development projects. Money, quality, budget, performance, expense, maintenance, cost.... Okay, some themes recur more often than others. In fact, cost is both the key driver and largest obstacle to project success. Although most people agree that code quality processes reduce the cost of software development and maintenance, these processes are usually the first to be scaled back when deadlines begin to loom and progress is almost invariably less than originally planned. Even though I can go on and on about the cause of these plan versus reality deltas (and I have in the past), today I'll focus on how you can best survive the reduction in time available to review code by making code easier to review.
Consistent Formatting is the Key to Code Quality
The average developer will tell you that formatting has nothing to do with quality. Of course, you are an above-average developer because you are reading articles on Developer.com rather than looking for three-sentence solutions in a blog entry by someone with no verifiable expertise.
Formatting is critical to quality in two main areas. The first is the ability to review code quickly. Consistent formatting allows a code reviewer to quickly skim through code they have never seen before. Anomalies jump out to the practiced eye much faster if the distraction of inconsistent use of white space, brackets, and alignment are removed from the process.
The second area where standardization of code formatting improves quality is when different developers must work on the same class. Whether it is part of an Agile process of parallel development or because one member has left the team, standard formatting makes it very easy for one developer to read another developer's code and instantly follow what the code is doing. It also makes it simpler to write better-performing code because consistent formatting greatly reduces the likelihood of creating redundant objects or managing object lifecycles poorly.
Setting and Sharing Formatting Standards
For Java (the only language I will cover here), formatting preferences can be found under Window\Preferences to access the Preferences dialog, and then Java\Code Style\Formatter. Here you will find some common formatting standards pre-installed.
Figure 1: Pre-Installed Formatting Options
If your team happens to follow any of these standards as-is, all you need to do is communicate to your team which one to choose. You also can share the preferred pre-installed option through Preferences; this will be covered in the next section.
Although I can live with these if they are accepted by a team as the standard, I have my own personal preferences I prefer to use when I am the one making the choice, so I usually go to the next step, which is to create my own formatting profile.
Figure 2: Custom Profile Dialog
The custom profile will be based off of an existing profile. Once you have a custom profile, you can extend it by creating a new profile based on your custom profile if you want. Having created your profile, you will be sent to the Edit screen (accessible in the future from the Edit button shown in Figure 1). My personal preference pet-peeve is conveniently the first setting available, which is the tab policy.
Figure 3: Formatting Profile Editing Screen