Introduction
This document contains guidelines (some stricter than others) so we can be consistent and spend more time solving the bigger and more interesting issues.
...
To help future-proof the code (avoiding libraries that may be deprecated in the near future), avoid assertions from the org.assertj.core.api.Java6Assertions
class. Java6 in the name is a concerning signal
...
Miscellaneous
...
private static final Logger LOG = getLogger();
- Ternary operators are acceptable when they make the code clearer but should never be nested
- Avoid TODO comments. Log a ticket instead
- Specify Gradle dependency versions in
versions.gradle
- Don't use two or more blank lines in a row (although this should be handled by spotless)
Logging
Logging is important for understanding what Besu is doing at any given time (for example, progress while synchronizing) and investigating defects. During development, add logging to aid in these cases.
- When creating loggers it should be the first declaration in the class, for example:
private static final Logger LOG = LoggerFactory.getLogger(MergeCoordinator.class);
Log Messages
Make log messages:
...
- Trace - Extremely detailed view showing the execution flow. Likely only useful to developers
- Debug - Information that is diagnostically helpful to a wider group than just developers (for example, sysadmins)
- Info - Generally useful information to log (for example, service start/stop, configuration assumptions). Default logging level
- Warn - Anything that can potentially cause application oddities but from which Besu automatically recovers
- Error - Any error which is fatal to the operation, but not Besu itself (for example, missing data)
- Fatal - An error that forces a shutdown of Besu
INFO Principles
- Aimed at users
- Should indicate any relevant progress for example sync, peering, worldstate download
- Should not present errors or warnings that require no intervention
DEBUG Principles
- Aimed at both end users and developers
- Should lead to resolution of common problems, whilst not spamming
- Should not contain logs that take up more than one terminal screen, e.g. raw data, including RLP
...
- Aimed at developers
- Expectation is everything is there and it's spammy
- Only useful when targeting certain packages/classes
For any log level past INFO, you will see in the code this pattern which is used to avoid unnecessary runtime processing.
LOG.atDebug()
.setMessage(
"disconnecting peer {}. Waiting for better peers. Current {} of max {}")
.addArgument(peer::getLoggableId)
.addArgument(this::peerCount)
.addArgument(this::getMaxPeers)
.log();