Hotspot Coding Style

The Top Ten List for Writing Good HotSpot Code

1. Encapsulate code within classes, factor the code, and make it easy to understand.
2. Use public accessor functions for instance variables accessed outside the class.
3. Use arrays with abstraction supporting range checks.
4. Always enumerate all cases in a switch statement or specify default case. It is ok to have an empty default with comment.
5. Use assert(...), guarantee(...), ShouldNotReachHere(), Unimplemented() and comments wherever needed. (Performance is almost never a reason to omit asserts.)
6. Use single inheritance, no operator overloading, no C++ exception handling, no templates, and no goto statements.
7. Assign names to constant literals and use the names instead. Use enum to name integer constants inside class definitions
8. Use bool for booleans (not int), use true & false (not 1 & 0); use NULL for pointers (not 0).
9. Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.
10. Ifdefs should only be used for:

• #ifdef ASSERT
• #ifdef CORE
• #ifdef PRODUCT

(Draft of 10/12/1998 by Lars Bak and Robert Griesemer.)

Lesser rules and practices of long standing.

• +Verbose is used to provide additional output for another flag, but does not enable output by itself.
• Do not use ints or pointers as booleans with &&, ||, if, while. Instead, compare explicitly != 0 or != NULL, etc. (See #8 above.)
• Personal names are discouraged in the source code, which is a team product.
• Clearly comment subtle fixes, and include bugtraq numbers.
• Always use SCCS comments, and include bugtraq numbers.
• Conform new code to style conventions. Avoid unnecessary "esthetic" variations, which are distracting.
• More about names:
• Type names and global names are mixed-case (FooBar).
• Local names and function names are lower-case (foo_bar).
• Constant names in upper-case or mixed-case are tolerated, according to historical necessity.
• Constant names should follow an existing pattern, and must have a distinct appearance from other names in related APIs.
• Class and type names are noun phrases. Consider an "er" suffix for a class that represents an action.
• Getter accessor names are noun phrases, with no "get" noise word. Boolean getters can also begin with "is_" or "has_".
• Setter accessor names prepend "set_" to the getter name.
• Other method names are verb phrases, as if commands to the receiver.
• Code layout and whitespace:
• Use spaces around operators, especially comparisons and assignments. (Relaxable for boolean expressions and high-precedence operators in classic math-style formulas.)
• Use extra parentheses in expressions whenever operator precedence seems doubtful. Always use parentheses in shift/mask expressions (<<, &, |, ~).
• Use functions from globalDefinitions.hpp when performing bitwise operations on integers. Do not code directly as C operators, unless they are extremely simple. (Examples: round_to, is_power_of_2, exact_log2.)
• Use more spaces and blank lines between larger constructs, such as classes or function definitions.
• Indentation levels are two columns.
• There is no hard line length limit.
• Tabs are not allowed in code. Set your editor accordingly. (Emacs: (setq-default indent-tabs-mode nil).)
• Use braces around substatements. (Relaxable for extremely simple substatements on the same line.)
• Use good taste to break lines and align corresponding tokens on adjacent lines.
• Otherwise, use normal conventions for whitespace in C.
• More suggestions on factoring.

(Collected 7/2002 by John Rose, based on observation and old docs.)

Why Care About Style?

Some programmers seem to have lexers and even C preprocessors installed directly behind their eyeballs. The rest of us require code that is not only functionally correct but also easy to read. More than that, since there is no one style for easy-to-read code, and since a mashup of many styles is just as confusing as no style at all, it is important for coders to be conscious of the many implicit stylistic choices that historically have gone into the Hotspot code base.

Nearly all of the guidelines mentioned below have many counter-examples in the Hotspot code base. Finding a counterexample is not sufficient justification for new code to follow the counterexample as a precedent, since readers of your code will rightfully expect your code to follow the greater bulk of precedents documented here. For more on counterexamples, see the section at the bottom of this page.

Whitespace

Naming

Grouping

Patterns

Counterexamples

Occasionally a guideline mentioned here may be just out of synch with the actual Hotspot code base. That's why we're using a wiki to document the guidelines. If you find that a guideline is consistently contradicted by a large number of counterexamples, please mention it here, to assist the rest of us coders with making an informed decision about coding style. The architectural rule, of course, is "When in Rome do as the Romans". Sometimes in the suburbs of Rome the rules are a little different; these differences can be pointed out here.

There may also be corrections needed. Please correct in a cautious and incremental fashion, because other Hotspot coders have been using these guidelines for years.