aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJon Atack <jon@atack.com>2022-05-09 17:35:15 +0200
committerJon Atack <jon@atack.com>2022-05-10 14:57:50 +0200
commite66b321fd1ddfffd9bfc59d407ad8f03490b873c (patch)
tree8ba8cb5c8f0760f7c78734b0a3e285237e13fe30 /doc
parent5fca70f5b16fee4a732a1d7fd3fb1c7e775decdf (diff)
Add C++ functions and methods section to developer notes
Credit for some parts to the Google C++ Style Guide "Inputs and Outputs" section at https://google.github.io/styleguide/cppguide.html#Inputs_and_Outputs Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
Diffstat (limited to 'doc')
-rw-r--r--doc/developer-notes.md43
1 files changed, 26 insertions, 17 deletions
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index ab2a899dd7..ef40265818 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -141,6 +141,27 @@ public:
} // namespace foo
```
+Coding Style (C++ functions and methods)
+--------------------
+
+- When ordering function parameters, place input parameters first, then any
+ in-out parameters, followed by any output parameters.
+
+- *Rationale*: API consistency.
+
+- Prefer returning values directly to using in-out or output parameters. Use
+ `std::optional` where helpful for returning values.
+
+- *Rationale*: Less error-prone (no need for assumptions about what the output
+ is initialized to on failure), easier to read, and often the same or better
+ performance.
+
+- Generally, use `std::optional` to represent optional by-value inputs (and
+ instead of a magic default value, if there is no real default). Non-optional
+ input parameters should usually be values or const references, while
+ non-optional in-out and output parameters should usually be references, as
+ they cannot be null.
+
Coding Style (C++ named arguments)
------------------------------
@@ -1390,22 +1411,9 @@ communication:
virtual boost::signals2::scoped_connection connectTipChanged(TipChangedFn fn) = 0;
```
-- For consistency and friendliness to code generation tools, interface method
- input and in-out parameters should be ordered first and output parameters
- should come last.
+- Interface methods should not be overloaded.
- Example:
-
- ```c++
- // Good: error output param is last
- virtual bool broadcastTransaction(const CTransactionRef& tx, CAmount max_fee, std::string& error) = 0;
-
- // Bad: error output param is between input params
- virtual bool broadcastTransaction(const CTransactionRef& tx, std::string& error, CAmount max_fee) = 0;
- ```
-
-- For friendliness to code generation tools, interface methods should not be
- overloaded:
+ *Rationale*: consistency and friendliness to code generation tools.
Example:
@@ -1421,10 +1429,11 @@ communication:
### Internal interface naming style
-- For consistency and friendliness to code generation tools, interface method
- names should be `lowerCamelCase` and standalone function names should be
+- Interface method names should be `lowerCamelCase` and standalone function names should be
`UpperCamelCase`.
+ *Rationale*: consistency and friendliness to code generation tools.
+
Examples:
```c++