|
| 1 | +# Coding Style Guide |
| 2 | + |
| 3 | +_Revision 6_ _2024-10-28_ |
| 4 | + |
| 5 | +This guide provides a small set of code guidelines used in the SDK. This guide |
| 6 | +reflects the currently accepted style practices for the SDK and is subject to |
| 7 | +change. |
| 8 | + |
| 9 | +The SDK was seeded from multiple different projects and contains contributions |
| 10 | +from many different companies and the SDK code therefore uses several different |
| 11 | +coding styles throughout the code base. Stylistically, code should attempt to |
| 12 | +conform to the dominant style of the code being modified, while also adhering to |
| 13 | +the guidelines below. |
| 14 | + |
| 15 | +## Language standard |
| 16 | + |
| 17 | +Code in the SDK conforms to the following standards. Changes to the C++ standard |
| 18 | +happen relatively infrequently. Changes to the Python version are more frequent. |
| 19 | + |
| 20 | +| Language | Version | |
| 21 | +| -------- | ------- | |
| 22 | +| C++ | C++17 | |
| 23 | +| Python | 3.10 | |
| 24 | + |
| 25 | +Product-specific software may elect to use later standards in their own work. |
| 26 | + |
| 27 | +## Coding Guidelines |
| 28 | + |
| 29 | +### Common |
| 30 | + |
| 31 | +#### When in Rome |
| 32 | + |
| 33 | +The most important convention and practice in the Matter SDK repo is "_When in |
| 34 | +Rome..._", per the quote below. |
| 35 | + |
| 36 | +[quote, St. Ambrose] |
| 37 | + |
| 38 | +--- |
| 39 | + |
| 40 | +If you should be in Rome, live in the Roman manner; if you should be elsewhere, |
| 41 | +live as they do there. |
| 42 | + |
| 43 | +--- |
| 44 | + |
| 45 | +Your extensions or fixes to existing code should match the prevailing style of |
| 46 | +the original code. |
| 47 | + |
| 48 | +If you find the conventions so foreign or otherwise confusing, it may be best to |
| 49 | +let whoever owns the file make the necessary changes or seek the counsel of |
| 50 | +others in the group to find out what the right thing to do is. Never just start |
| 51 | +changing code wholesale for personal reasons without consulting others first. |
| 52 | + |
| 53 | +#### Commenting Out or Disabling Code |
| 54 | + |
| 55 | +Unused code shall not be disabled by commenting it out with C- or C++-style |
| 56 | +comments or with preprocessor `#if 0 ... #endif` semantics. Unused code should |
| 57 | +be removed. |
| 58 | + |
| 59 | +#### Auto-formatters |
| 60 | + |
| 61 | +We use the following auto-formatters on code: |
| 62 | + |
| 63 | +| Language | Formatter | Style File | |
| 64 | +| ----------- | ------------------ | ------------------------------------------------------------------------------------------ | |
| 65 | +| C++ | clang-format | [.clang-format](https://github.com/project-chip/connectedhomeip/blob/master/.clang-format) | |
| 66 | +| Objective-C | clang-format | [.clang-format](https://github.com/project-chip/connectedhomeip/blob/master/.clang-format) | |
| 67 | +| java | google-java-format | N/A | |
| 68 | +| Python | pep8, isort, ruff | [.restyled.yaml][restyle_link] (command line), [isort][isort_link], [ruff][ruff_link] | |
| 69 | +| YAML | prettier | None | |
| 70 | +| JSON | prettier | None | |
| 71 | +| markdown | prettier | None | |
| 72 | + |
| 73 | +[restyle_link]: |
| 74 | + https://github.com/project-chip/connectedhomeip/blob/master/.restyled.yaml |
| 75 | +[isort_link]: |
| 76 | + https://github.com/project-chip/connectedhomeip/blob/master/.isort.cfg |
| 77 | +[ruff_link]: |
| 78 | + https://github.com/project-chip/connectedhomeip/blob/master/ruff.toml |
| 79 | + |
| 80 | +All pull requests run formatting checks using these tools before merge is |
| 81 | +allowed. Generated code is not run through restyle. |
| 82 | + |
| 83 | +### C++ |
| 84 | + |
| 85 | +#### Use C++ _cstdint_ for Plain Old Data Types |
| 86 | + |
| 87 | +Standard, scalar data types defined in _cstdint_ should be used for basic signed |
| 88 | +and unsigned integer types, especially when size and serialization to |
| 89 | +non-volatile storage or across a network is concerned. |
| 90 | + |
| 91 | +Examples of these are: `uint8_t`, `int8_t`, etc. |
| 92 | + |
| 93 | +#### Avoid top-level `using namespace` Statements in Headers |
| 94 | + |
| 95 | +By doing this, you are effectively forcing every other module that includes the |
| 96 | +header to also be using the namespace. This causes namespace pollution and |
| 97 | +generally defeats the purposes of namespaces. Fully-qualified symbols or |
| 98 | +namespace blocks should be used instead. |
| 99 | + |
| 100 | +#### Classes / objects not exposed in a header should be in an anonymous namespace |
| 101 | + |
| 102 | +If a cpp class defines a class or instantiates a static object, it should be |
| 103 | +enclosed in an anonymous namespace. |
| 104 | + |
| 105 | +``` |
| 106 | +namespace { |
| 107 | + // CPP internal defines go here |
| 108 | +} // namespace |
| 109 | +``` |
| 110 | + |
| 111 | +#### Singleton use |
| 112 | + |
| 113 | +The decision to use a singleton class should be considered with care. Do not |
| 114 | +default to using a singleton for ease of writing code. |
| 115 | + |
| 116 | +If the class truly should be a singleton (ex. if it is controlling access to a |
| 117 | +hardware resource) |
| 118 | + |
| 119 | +- The standard function name for accessing an SDK singleton is GetInstance(). |
| 120 | +- Singleton classes should delete copy and move constructors |
| 121 | + |
| 122 | +#### Avoid Heap-based Resource Allocation and auto-resizing std containers |
| 123 | + |
| 124 | +Heap-based resource allocation should be avoided in the core SDK for common code |
| 125 | +that may run on constrained embedded devices. This includes any container |
| 126 | +element in std that automatically re-sizes itself at runtime (ex. vector, string |
| 127 | +etc.) as these re-size operations are often large and can lead to memory |
| 128 | +exhaustion and fragmentation on embedded systems. |
| 129 | + |
| 130 | +Heap-based allocation is allowed for controller code and is at the discretion of |
| 131 | +platform vendors for platform-specific code. |
| 132 | + |
| 133 | +##### Alternatives |
| 134 | + |
| 135 | +In either case, recommended resource allocation alternatives are: |
| 136 | + |
| 137 | +- In-place allocation and initialization |
| 138 | +- Pool-based allocators |
| 139 | +- Platform-defined and -assigned allocators |
| 140 | + |
| 141 | +[CHIPMem.h](https://github.com/project-chip/connectedhomeip/blob/master/src/lib/support/CHIPMem.h) |
| 142 | +provides support for platform defined allocators. |
| 143 | + |
| 144 | +[Pool.h](https://github.com/project-chip/connectedhomeip/blob/master/src/lib/support/Pool.h) |
| 145 | +is the Matter SDK pool allocator implementation. |
| 146 | + |
| 147 | +#### Prefer CopySpanToMutableSpan over memcpy when using spans |
| 148 | + |
| 149 | +See |
| 150 | +[Span.h](https://github.com/project-chip/connectedhomeip/blob/master/src/lib/support/Span.h) |
| 151 | + |
| 152 | +#### Prefer std::optional to CHIP implementation in newer code |
| 153 | + |
| 154 | +The Matter SDK Optional.h was implemented when the Matter SDK was C++14, but |
| 155 | +newer code can use std::optional, which offers some benefits over the Matter SDK |
| 156 | +implementation (ex. std::optional is trivially destructible if the underlying |
| 157 | +type is also trivially destructible) |
| 158 | + |
| 159 | +### Python |
| 160 | + |
| 161 | +#### Type hints |
| 162 | + |
| 163 | +Use type hints on function definitions for public APIs. |
| 164 | + |
| 165 | +#### Docstrings |
| 166 | + |
| 167 | +Docstrings should be included for all public APIs. |
| 168 | + |
| 169 | +#### mypy |
| 170 | + |
| 171 | +The current python code does not yet pass mypy checks, but we are working |
| 172 | +towards this goal. The more compliant new code is to mypy, the better. |
0 commit comments