diff options
Diffstat (limited to 'doc/developer-notes.md')
-rw-r--r-- | doc/developer-notes.md | 41 |
1 files changed, 26 insertions, 15 deletions
diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 81bdcc9fdb..8fdae25340 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -4,7 +4,7 @@ Developer Notes Various coding styles have been used during the history of the codebase, and the result is not very consistent. However, we're now trying to converge to a single style, which is specified below. When writing patches, favor the new -style over attempting to mimick the surrounding style, except for move-only +style over attempting to mimic the surrounding style, except for move-only commits. Do not submit patches solely to modify the style of existing code. @@ -28,15 +28,17 @@ tool to clean up patches automatically before submission. required when doing so would need changes to significant pieces of existing code. - Variable and namespace names are all lowercase, and may use `_` to - separate words. + separate words (snake_case). - Class member variables have a `m_` prefix. - Global variables have a `g_` prefix. - Constant names are all uppercase, and use `_` to separate words. - - Class names, function names and method names are CamelCase. Do not prefix - class names with `C`. + - Class names, function names and method names are UpperCamelCase + (PascalCase). Do not prefix class names with `C`. - **Miscellaneous** - `++i` is preferred over `i++`. + - `nullptr` is preferred over `NULL` or `(void*)0`. + - `static_assert` is preferred over `assert` where possible. Generally; compile-time checking is preferred over run-time checking. Block style example: ```c++ @@ -275,7 +277,7 @@ Wallet - *Rationale*: In RPC code that conditionally uses the wallet (such as `validateaddress`) it is easy to forget that global pointer `pwalletMain` - can be NULL. See `test/functional/disablewallet.py` for functional tests + can be nullptr. See `test/functional/disablewallet.py` for functional tests exercising the API with `-disablewallet` - Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set @@ -330,6 +332,12 @@ C++ data structures - *Rationale*: Ensure determinism by avoiding accidental use of uninitialized values. Also, static analyzers balk about this. +- By default, declare single-argument constructors `explicit`. + + - *Rationale*: This is a precaution to avoid unintended conversions that might + arise when single-argument constructors are used as implicit conversion + functions. + - Use explicitly signed or unsigned `char`s, or even better `uint8_t` and `int8_t`. Do not use bare `char` unless it is to pass to a third-party API. This type can be signed or unsigned depending on the architecture, which can @@ -561,25 +569,23 @@ A few guidelines for introducing and reviewing new RPC interfaces: which is error prone, and it is easy to get things such as escaping wrong. JSON already supports nested data structures, no need to re-invent the wheel. - - *Exception*: AmountToValue can parse amounts as string. This was introduced because many JSON + - *Exception*: AmountFromValue can parse amounts as string. This was introduced because many JSON parsers and formatters hard-code handling decimal numbers as floating point values, resulting in potential loss of precision. This is unacceptable for - monetary values. **Always** use `AmountToValue` and `ValueToAmount` when + monetary values. **Always** use `AmountFromValue` and `ValueFromAmount` when inputting or outputting monetary values. The only exceptions to this are `prioritisetransaction` and `getblocktemplate` because their interface is specified as-is in BIP22. - Missing arguments and 'null' should be treated the same: as default values. If there is no - default value, both cases should fail in the same way. + default value, both cases should fail in the same way. The easiest way to follow this + guideline is detect unspecified arguments with `params[x].isNull()` instead of + `params.size() <= x`. The former returns true if the argument is either null or missing, + while the latter returns true if is missing, and false if it is null. - *Rationale*: Avoids surprises when switching to name-based arguments. Missing name-based arguments are passed as 'null'. - - *Exception*: Many legacy exceptions to this exist, one of the worst ones is - `getbalance` which follows a completely different code path based on the - number of arguments. We are still in the process of cleaning these up. Do not introduce - new ones. - - Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")` do different things. @@ -607,9 +613,14 @@ A few guidelines for introducing and reviewing new RPC interfaces: from there. - A RPC method must either be a wallet method or a non-wallet method. Do not - introduce new methods such as `getinfo` and `signrawtransaction` that differ - in behavior based on presence of a wallet. + introduce new methods such as `signrawtransaction` that differ in behavior + based on presence of a wallet. - *Rationale*: as well as complicating the implementation and interfering with the introduction of multi-wallet, wallet and non-wallet code should be separated to avoid introducing circular dependencies between code units. + +- Try to make the RPC response a JSON object. + + - *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if + new data in the response is needed. |