Page History

This page is obsolete.  It is replaced by the updated HotSpot Style Guide.

Hotspot Coding Style

...

1. #Classes

   Anchor
   Classes Classes

   Encapsulate code within classes, factor the code, and make it easy to understand.
2. #Accessors

   Anchor
   Accessors Accessors

   Use public accessor functions for instance variables accessed outside the class.
3. #Arrays

   Anchor
   Arrays Arrays

   Use arrays with abstraction supporting range checks.
4. #Switches

   Anchor
   Switches Switches

   Always enumerate all cases in a switch statement or specify default case. It is ok to have an empty default with comment.
5. #Asserts

   Anchor
   Asserts Asserts

   Use assert(...), guarantee(...), ShouldNotReachHere(), Unimplemented() and comments wherever needed. (Performance is almost never a reason to omit asserts.)
6. #SimpleC

   Anchor
   SimpleC SimpleC

   Use single inheritance, no operator overloading, no C++ exception handling, and no goto statements. (There are a few uses of operator overloading, but these should be rare cases.) Be sparing with templates. Use only C++ features which will work correctly on all of our platforms.
7. #NamedCons

   Anchor
   NamedCons NamedCons

   Assign names to constant literals and use the names instead. Use enum to name integer constants inside class definitions.
8. #Booleans

   Anchor
   Booleans Booleans

   Use bool for booleans (not int), use true & false (not 1 & 0); use NULL for pointers (not 0).
9. #Names

   Anchor
   Names Names

   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

    Anchor
    Ifdefs Ifdefs

    Ifdefs should not be used to introduce platform-specific code into shared code (except for LP64). They must be used to manage header files, in the pattern found at the top of every source file. They should be used mainly for major build features, including PRODUCT, ASSERT, _LP64, SERIALGC, COMPILER1, etc.

...

• Type names and global names are mixed-case (FooBar).
• Local names (fields, variables) and function names are lower-case (foo_bar). (For these, avoid mixing in upper case letters.)
• 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.
  • Inside class definitions, integer constants can be defined with "static const".  (Historically, enums have been also been used.)
• 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.
• Avoid leading underscores (as "_oop") except in cases required above. (Names with leading underscores can cause portability problems.)

...

• Conform new code to style conventions. Avoid unnecessary "esthetic" variations, which are distracting.
• Use the C++ RAII design pattern to manage bracketed critical sections. See class ResourceMark for an example.
• +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.)
• 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.)
• Naming JTreg tests
• More suggestions on factoring.

• Test Development Guidelines

Files

Anchor
Files Files

• Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.
• .inline.hpp files should only be included in .cpp or .inline.hpp files.
• All .cpp files include precompiled.hpp as the first include line.
• precompiled.hpp is just a build time optimization, so don't rely on it to resolve include problems.
• Keep the include lines sorted.
• Put conditional inclusions (#if ...) at the end of the include list.

...