-
Notifications
You must be signed in to change notification settings - Fork 10
Code Style
We follow the Google Java Style Guide for our Java code with some small adaptation (see below). In other code, e.g. JavaScript or SQL, we also stay close to this basic style with some exceptions and additions, see sections on the specific languages below.
Here is a brief summary of the most important points from the Google Java Style Guide:
-
Pay attention to the correct order of modifiers:
public protected private abstract default static final transient volatile synchronized
- Must use one blank line between methods
- Can use blank line(s) to group fields
- Can use blank lines(s) to group statements
- Note: Don't use more than two consecutive blank lines
- Use a space between keywords and braces and before opening braces
- Use a space around binary or ternary operators
- After
,:;
(unless it's a trailing space)
Only include fields and methods that are necessary. Each class should be structured the following way:
- logger (
private static final Logger log
) - private constants (
private static final
) - public constants (
public static final
) - fields (in some logical order/grouping)
- all constructor(s)
- getters/setters/overrides/other methods
- in some logical order
- keep getters and setters together
- keep related methods together
- keep private helper methods close to the method(s) that use it (preferably below)
- overloads should never be split
-
equals
,hashCode
,toString
methods
Unless otherwise noted, please follow the parts of the java style guide that make sense in the other languages (most notably whitespace conventions).
- Use single quotes for strings
There are also a few coding conventions to ensure predictability.
Methods that retrieve an object are generally prefixed with get
. Do not include parameters names in the method name, unless the type of a parameter is ambiguous and a different name is necessary to distinguish two overloaded methods (e.g. getByProposalId(long)
and getByContestId(long)
).
In general, parameter order should be consistent across the system as much as possible. Related methods should always have their parameters in the same order.
A few guidelines:
- Parameters that belong together should be logically grouped together, e.g.
activityCategory, categoryId, userId
- Grouped parameters should be in ascending order according to specificity (get more specific from left to right), e.g.
activityCategory, categoryId
A handler method inside a Spring MVC controller should follow the following order for parameters. Parameters that are not required should be skipped and additional parameters can be added at the end.
@GetMapping("/contests/{contestYear}/{contestUrlName}")
public String showContestProposals(
// start with servlet and mvc objects injected by Spring MVC
HttpServletRequest request,
HttpServletResponse response,
Model model,
// continue with objects injected via custom resolvers
Member loggedInMember,
ProposalContext proposalContext,
// followed by path variables and request parameters
@PathVariable String contestYear,
@PathVariable String contestUrlName,
@RequestParam(required = false) long phaseId,
// lastly, add model attributes and the binding result
@Valid SortFilterPage sortFilterPage,
BindingResult bindingResult) {
// controller code
return "viewName";
}
The repository has a .editorconfig
with indentation settings that should be supported by most IDEs. If you are using IntelliJ IDEA, the config files in the .idea
directory should already configure the defaults correctly to adhere to the code style by default. You can reformat code in a file by pressing cmd + alt + L
. Be mindful of what you reformat and note that the code style purposely leaves some leeway in how exactly the files is formatted to let the developer decide what is the most readable version allowed within the code style.