Improving Code Consistency and Standards Compliance with Eclipse Preferences, Page 3
Preferences Add More Standards for Less Confusion
A Formatter profile can (and probably should) be maintained at an enterprise level. At a project level, there are many other Eclipse configurations that can be standardized for a smoother development process.
You may have noticed when navigating to the Formatter preferences (refer to Figure 1) that there are several additional options available under the Code Style section. I think one of the most advantageous options are the Code Templates, which are used when generating new code. The dialogs provide the use of built-in variables making for easy configuration.
Click here for a larger image.
Figure 8: Adding Variables to Templates Made Easy
At a more project-specific level, classpath variables are handy for consistent references to legacy libraries. These can be set under the Build Path preference.
Figure 9: Classpath Variables
Unlike the Formatter options, these other options do not have a single export. Instead, they can be shared as a group by exporting preferences. When using preferences, you do not need to export your Formatter profile separately; it will be included in the exported preferences.
The preferences export, being at a more global level, is accessed from the global File\Export command.
Figure 10: Exporting Preferences
You may want to edit the exported file for localized paths to common variables, such as the JRE location:
The above line should be removed because every installation will have a JRE path and it can be annoying to have run-time errors dues to an invalid path. Alternatively, you could have standards for installation paths, and not need change these.
Localized paths for classpath variables should be preserved even if they will cause compile-time errors. These errors are easily identified in the Problems panel. Once located at a project level, the next step is to go to the project preferences dialog, locate the clearly marked error under the Build Path panel, and edit the value to match your local installation. Because the original path and file name are part of the invalid path, it should make it much easier to find the correct path in your local environment. Obviously, this approach requires that preferences be shared only once through the import process.
Almost every technical lead wants to maintain code quality and is frequently frustrated by tightening timelines to have the time to enforce code quality as part of the mentoring process. By using Eclipse preferences as part of a standard developer set, the reduced time available for code review can be put to better use by making the code easier to read, thus faster to review. Sharing Eclipse preferences also makes it easier to on-board new developers to a project.
About the Author
Scott Nelson is an optimization consultant with over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. For information on how he can help with your web applications, please visit http://www.fywservices.com/ He also blogs all of the humorous emails forwarded to him at Frequently Unasked Questions.
Page 3 of 3