Hotspot Coding Style
How will my new code best fit in with the Hotspot code base? Here are some guidelines.
The Top Ten List for Writing Good HotSpot Code
- 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.
- Use spaces around operators, especially comparisons and assignments. (Relaxable for boolean expressions and high-precedence operators in classic math-style formulas.)
- Put spaces on both sides of control flow keywords
switch, etc. * Use extra parentheses in expressions whenever operator precedence seems doubtful. Always use parentheses in shift/mask expressions (
- Use more spaces and blank lines between larger constructs, such as classes or function definitions.
- If the surrounding code has any sort of vertical organization, adjust new lines horizontally to be consistent with that organization. (E.g., trailing backslashes on long macro definitions often align.)
- Otherwise, use normal conventions for whitespace in C.
- Try not to change whitespace unless it improves readability or consistency. (Different editors indent differently, and spurious indentation changes will just make integrations more difficult.)
- Type names and global names are mixed-case (
- 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.
- 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 "
- 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.)
- Clearly comment subtle fixes.
- Clearly comment tricky classes and functions.
- If you have to choose between commenting code and writing wiki content, comment the code. Link from the wiki to the source file if it makes sense.
- As a general rule don't add bug numbers to comments (they would soon overwhelm the code). But if the bug report contains significant information that can't reasonably be added as a comment, then refer to the bug report.
- Personal names are discouraged in the source code, which is a team product.