Maintaining coding guidelines: naming convention vs syntax highlighting

Egor Malyshev

Naming conventions were subject to many local corporate wars, and probably any developer heard phrases like “These underscores before private field names just look ugly!” One more problem with naming conventions is constant changes in the code (if you convert a local variable to a field, will you rename it?). And of course, developers often simply forget about all these conventions and cannot remember whether it is necessary to use upper or lower case first letter for a constant.
However, it is necessary to make the code readable by different team members. And of course, it is always useful to be able to quickly distinguish local variables from fields, classes from abstract classes and interfaces, static methods from non-static ones; and so on.
With IntelliJ IDEA, the solution for all these problems is code highlighting. If you still think that code highlighting only makes keywords bold, just look at IntelliJ IDEA highlighting settings (Settings | Colors and Fonts | Java).

Here you can define the color schema for:

• Class
• Abstract Class
• Interface
• Local Variable
• Parameter
• Instance field
• Static field
• Method call
• Static Method call
• And more

So, you can easily understand the code of your team mates even if no naming convention is used within the team. All you need is to adjust your color schema!
In fact, syntax highlighting can be an even more powerful tool for code analysis than naming convention. For example, in IntelliJ IDEA you can highlight unused symbols, so you can easily find the potential dead code. One more useful trick is to highlight reassigned parameters to see whether parameters change their values within the method body (that is often considered as “bad coding style”). Also you can highlight reassigned local variables.
Well, suppose you still think that naming convention is a must for your team (let’s say you have different IDEs in your team and not all of them have so flexible syntax highlighting). And while you consider violation of the naming convention a serious coding error, the compiler doesn’t. So everybody keeps violating them without a notice.
A good IDE should not force you to use naming convention, but of course it should help you with following the convention if you choose one. In IntelliJ IDEA, there is a set of code inspections that allows you to define naming patterns and then check whether the code violates them. You can configure naming convention settings in the Settings | Errors dialog.

If you set the constant naming conventions as shown on the screenshot above, when incorrectly named constants will be highlighted right in the editor.

The yellow light bulb shows that IntelliJ IDEA can help you with solving the problem. Just press Alt + Enter, and select to rename the symbol. All the usages of this symbol in the code will be also renamed. This way you can quickly make the code to follow the necessary convention.
Of course, IntelliJ IDEA inspections can help your not only with naming conventions, but also with other coding guidelines (comments, annotations, parenthesis, and more) and static code analysis. But this can be a subject of a separate topic.
So, now before establishing naming convetions in your team, think whether you really need one. And if it’s true, you can at least make its maintenance easier.

Note   This tip&trick was originally posted at www.javalobby.org.

Subscribe to IntelliJ IDEA Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!