Coding style means nothing to a compiler; it will happily accept any legal code, no matter how badly formatted. Not so for us humans. Our ability to read and understand a program written by another is extremely sensitive to format. Imagine trying to read this article if every letter was in a different font and each line randomly aligned. Clearly, format affects readability, and it is just as true for reading programs as for text.

A consistent style also leads to lower maintenance costs by making it easier to debug and enhance the code. This is especially true for teams of programmers working on the same project, who must often read and edit each other's code. In this case, it is important that each team member follow not only a consistent style, but the same style. A common style also enables the development of automated tools to assist in program development, such as formatting tools and editor macros.

In spite of these benefits, some developers are reluctant to adopt a common style. One reason might be a belief that it requires too much effort. It is true that it takes a bit of time initially to learn the new rules (and unlearn old bad habits). However, once learned, they become automatic, and it takes no more effort to write code in a good style than in a poor style. In fact, it probably saves time by allowing programmers to concentrate on the semantics of the program, instead of consciously worry about the right format for each statement.

A larger reason for lack of a consistent style, however, is the lack of widely available, comprehensive and well thought out coding standards. This article is one attempt at improving this situation.

Space does not permit the presentation of an entire coding standard here. Rather, this article gives a selected set of the most important coding style rules, in somewhat condensed form. Listing 1 shows a code example demonstrating most of these style rules.

Indentation
One of the most important rules addresses the horizontal alignment of source lines.Line indentation is always four spaces per indentation level. [This is a difference from the predominant indentation style of eight spaces used in C programs; it is an acknowledgment that typical Java programs tend to have more levels of nesting than typical C programs.] The construction of the indentation may include tabs as well as spaces in order to reduce the file size; however, do not change the hard tab settings of your editor to accomplish this. Hard tabs must be set every 8 spaces. Soft tabs may be set every 4 spaces if your editor supports them.

Line Length
Lines should be limited to 80 columns. Longer lines should be broken into one or more continuation lines, as needed. All the continuation lines should be aligned and indented from the first line of the statement. The amount of the indentation depends on the type of statement.

If the statement must be broken in the middle of a parenthesized expression, such as for the parameter list in a method invocation or declaration, the next line should be aligned with the first character to the right of the first unmatched left parenthesis in the previous line. In all other cases, the continuation lines should be indented by a full standard indentation (4 spaces).

Braces Style
The preferred style for placement of braces in compound statements is the style commonly referred to as the "K&R" style. [Named after Brian Kernighan and Dennis Ritchie, authors of the first book on the C language.] Unlike C, in Java this style is used in all cases, including class and instance initializers and array initializers. This style is specified as follows:
1. The opening left brace "{" is at the end of the line beginning the statement.
2. The closing right brace "}" is alone on a line, indented to the same column as the first line of the statement.
3. The statements inside the enclosed braces are indented one more level than in the statement.

Naming Conventions
Another aspect of coding style that makes a big difference is consistency of naming. Package names should use only lower-case letters and digits, and no underscore. If the package will be publicly distributed, prepend a unique prefix to the package by using the Internet domain name components in reverse order (e.g., com.sun, graphics.util).

All class and interface names should use the InfixCaps style. Start with an upper case letter and capitalize the first letter of any subsequent word in the name. All other characters in the names are lower case. Do not use underscores to separate words. Class names should be nouns or noun phrases. Interface names depend on the purpose of the interface. If it is primarily to endow an object with a particular capability, then the name should be an adjective that describes the capability (e.g., Searchable, Sortable). Otherwise, use nouns or noun phrases.

Variables (except static final types, see below) use the infixCaps style. Start with a lower case letter and capitalize the first letter of any subsequent word in the name, as well as any letters that are part of an acronym. all other characters in the name are lower case. Do not use underscores to separate words. Variable names should be nouns or noun phrases (e.g., numberOfPoints).

Static final primitive types being used as constants should be all upper case, with underscores separating words (e.g., MAX_BUFFER_SIZE).

Method names also use the infixCaps style. Method names should be verbs or verb phrases (e.g., drawCircle()).

White Space Usage
Blank lines can improve readability by grouping sections of the code that are logically related. A blank line should also be used:

Avoid putting any information into comments that is likely to become out-of-date.

Published Mar. 1, 1998— Reads 10,202
Copyright © 1998 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Source Code

About Achut Reddy
Achut Reddy is a staff engineer at Sun Microsystems in the authoring and development tools group, which is currently working on Java performance issues.