Conversation
nhjschulz
left a comment
nhjschulz
left a comment
There was a problem hiding this comment.
Some comments, mostly subjective as this is style guide related. Feel free to reject if you disagree.
doc/CodingGuideline.md
Outdated
| | Private member variable | `m_` prefix + camelCase | `m_isActive`, `m_duration` | | ||
| | Constant / `static const` member | `UPPER_SNAKE_CASE` | `MIN_BATTERY_LEVEL`, `SEND_WAYPOINT_TIMER_INTERVAL` | | ||
| | File-scope static variable | `g` prefix + camelCase | `gLogSinkSerial` | | ||
| | Macro parameter | double-underscore prefix | `SIMPLE_TIMER_SECONDS(__timeInS)` | |
There was a problem hiding this comment.
Is this already used ? Dunder prefix is reserved to compiler/runtime.
| | Macro parameter | double-underscore prefix | `SIMPLE_TIMER_SECONDS(__timeInS)` | | ||
| | Enum value | `UPPER_SNAKE_CASE` | `CMD_GET_MAX_SPEED`, `CMD_NONE` | | ||
|
|
||
| Use `uint8_t`, `uint16_t`, `uint32_t` etc. for sized integer types. Append `U` to unsigned integer literals (`50U`, `1000U`). |
There was a problem hiding this comment.
Wouldn't it simpler to refer to stdint.h base type usage.
|
|
||
| --- | ||
|
|
||
| ## Headers |
There was a problem hiding this comment.
That should better move up to appear right after (or before) cpp skeleton.
| Include order (within a file): | ||
| 1. Own header (`"App.h"`) | ||
| 2. Project headers (`<Board.h>`, `<Logging.h>`) | ||
| 3. Third-party / Arduino headers (`<ArduinoJson.h>`) |
|
|
||
| Template/header-only implementations use `.hpp`, all others use `.h` / `.cpp`. | ||
|
|
||
| Include order (within a file): |
There was a problem hiding this comment.
It may make sense to distinguish header and cpp usages here.
i.e a header should only include the minimum to allow compilation, not everything its module needs in implementation.
|
|
||
| --- | ||
|
|
||
| ## Patterns |
There was a problem hiding this comment.
for me such patterns are not desirable in a style guide. A singleton pattern has a lot more dependencies and quirks than style.
I also don't get the fous for "final" for concrete states. Better would be a rule when to apply final (and when not).
|
|
||
| ## Parameters | ||
|
|
||
| Pass non-trivial input arguments as `const` reference; output arguments as non-const reference: |
There was a problem hiding this comment.
Any rule regarding pointer passing ? References are not working if a i nput/output is optional, i.e. may be a nullptr.
Format table. Remove closing header guard in example.
3 participants
#186