You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The language of this project is **C++**, and all new code must be written in C++. (Modern) C++ provides a lot of useful tools and functionalities that are beneficial for embedded software development like `constexpr`, `template` and anything that provides zero-cost abstraction.
6
+
7
+
C code is accepted if it comes from another library like FreeRTOS, NimBLE, LVGL or the NRF-SDK.
8
+
9
+
## Coding style
10
+
11
+
The most important rule to follow is to try to keep the code as easy to read and maintain as possible.
12
+
13
+
Using an autoformatter is highly recommended, but make sure it's configured properly.
14
+
15
+
There are preconfigured autoformatter rules for:
16
+
17
+
* CLion (IntelliJ) in [.idea/codeStyles/Project.xml](/.idea/codeStyles/Project.xml)
18
+
*`clang-format`
19
+
20
+
Also use `clang-tidy` to check the code for other issues.
21
+
22
+
If there are no preconfigured rules for your IDE, you can use one of the existing ones to configure your IDE.
23
+
24
+
-**Indentation** : 2 spaces, no tabulation
25
+
-**Opening brace** at the end of the line
26
+
-**Naming** : Choose self-describing variable name
27
+
-**class** : PascalCase
28
+
-**namespace** : PascalCase
29
+
-**variable** : camelCase, **no** prefix/suffix ('_', 'm_',...) for class members
- files from the project : `#include "relative/path/to/the/file.h"`
33
+
- external files and std : `#include <file.h>`
34
+
- Only use [primary spellings for operators and tokens](https://en.cppreference.com/w/cpp/language/operator_alternative)
35
+
- Use auto sparingly. Don't use auto for [fundamental/built-in types](https://en.cppreference.com/w/cpp/language/types) and [fixed width integer types](https://en.cppreference.com/w/cpp/types/integer), except when initializing with a cast to avoid duplicating the type name.
Copy file name to clipboardExpand all lines: doc/contribute.md
+8-50Lines changed: 8 additions & 50 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,18 +14,14 @@ As the documentation is part of the source code, you can submit your improvement
14
14
15
15
You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*.
16
16
17
-
## Spread the word
18
-
19
-
The Pinetime is a cool open source project that deserves to be known. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open source firmware for a smartwatch!
20
-
21
17
# How to submit a pull request?
22
18
23
19
## TL;DR
24
20
25
21
- Create a branch from develop
26
22
- Work on a single subject in this branch. Create multiple branches/pulls-requests if you want to work on multiple subjects (bugs, features,...)
27
23
- Test your modifications on the actual hardware
28
-
- Check the code formatting against our coding conventions and [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy)
24
+
- Check your code against the [coding conventions](/doc/coding-convention.md) and [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy)
29
25
- Clean your code and remove files that are not needed
30
26
- Write documentation related to your new feature if applicable
31
27
- Create a pull request and write a great description about it: what does your PR do, why, how,... Add pictures and video if possible
@@ -38,9 +34,9 @@ If you want to fix a bug, add functionality or improve the code, you'll first ne
38
34
39
35
When your feature branch is ready, **make sure it actually works** and **do not forget to write documentation** about it if it's relevant.
40
36
41
-
**Creating a pull request containing modifications that haven't been tested is strongly discouraged.** If, for any reason, you cannot test your modifications but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedback about your code.
37
+
**Creating a pull request containing modifications that haven't been tested is strongly discouraged.** If for any reason you cannot test your modifications, but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedback about your code.
42
38
43
-
Also, before submitting your PR, check the coding style of your code against the **coding conventions** detailed below. This project also provides [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy) configuration files. You can use them to ensure correct formatting of your code.
39
+
Before submitting a PR, check your code against our [coding conventions](/doc/coding-convention.md). This project also provides [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy) configuration files. You should use them to ensure correct formatting of your code.
44
40
45
41
Don't forget to check the files you are going to commit and remove those which aren't necessary (config files from your IDE, for example). Remove old comments, commented code,...
46
42
@@ -52,52 +48,14 @@ Once the pull request is reviewed and accepted, it'll be merged into **develop**
52
48
53
49
## Why all these rules?
54
50
55
-
Reviewing pull requests is a **very time consuming task** for the creator of this project ([JF002](https://github.com/JF002)) and for other contributors who take the time to review them. Everything you do to make reviewing easier will **get your PR merged faster**.
51
+
Reviewing pull requests is a **very time consuming task**. Everything you do to make reviewing easier will **get your PR merged faster**.
56
52
57
-
When reviewing PRs, the author and contributors will first look at the **description**. If it's easy to understand what the PR does, why the modification is needed or interesting and how it's done, a good part of the work is already done : we understand the PR and its context.
53
+
Reviewers will first look at the **description**. If it's easy to understand what the PR does, why the modification is needed or interesting and how it's done, a good part of the work is already done : we understand the PR and its context.
58
54
59
-
Then, reviewing **a few files that were modified for a single purpose** is a lot more easier than to review 30 files modified for many reasons (bug fix, UI improvements, typos in doc,...), even if all these changes make sense. Also, it's possible that we agree on some modification but not on some other, so we won't be able to merge the PR because of the changes that are not accepted.
55
+
Reviewing **a few files that were modified for a single purpose** is a lot easier than reviewing 30 files modified for many reasons (bug fix, UI improvements, typos in doc,...), even if all the changes make sense. Also, it's possible that we agree on some modification but not on another, so we won't be able to merge the PR because of the changes that are not accepted.
60
56
61
-
We do our best to keep the code as consistent as possible. If the formatting of the code in your PR is not consistent with our code base, we'll ask you to review it, which will take more time.
57
+
We do our best to keep the code as consistent as possible. If the formatting of your code is not consistent with our code base, we'll ask you to review it.
62
58
63
-
The last step of the review consists of **testing** the modification. If it doesn't work out of the box, we'll ask your to review your code and to ensure that it works as expected.
59
+
Lastly the changes are tested. If it doesn't work out of the box, we'll ask your to review your code and to ensure that it works as expected.
64
60
65
61
It's totally normal for a PR to need some more work even after it was created, that's why we review them. But every round trip takes time, so it's good practice to try to reduce them as much as possible by following those simple rules.
66
-
67
-
# Coding convention
68
-
69
-
## Language
70
-
71
-
The language of this project is **C++**, and all new code must be written in C++. (Modern) C++ provides a lot of useful tools and functionalities that are beneficial for embedded software development like `constexpr`, `template` and anything that provides zero-cost abstraction.
72
-
73
-
C code is accepted if it comes from another library like FreeRTOS, NimBLE, LVGL or the NRF-SDK.
74
-
75
-
## Coding style
76
-
77
-
The most important rule to follow is to try to keep the code as easy to read and maintain as possible.
78
-
79
-
Using an autoformatter is highly recommended, but make sure it's configured properly.
80
-
81
-
There are preconfigured autoformatter rules for:
82
-
83
-
* CLion (IntelliJ) in .idea/codeStyles/Project.xml
84
-
85
-
If there are no preconfigured rules for your IDE, you can use one of the existing ones to configure your IDE.
86
-
87
-
-**Indentation** : 2 spaces, no tabulation
88
-
-**Opening brace** at the end of the line
89
-
-**Naming** : Choose self-describing variable name
90
-
-**class** : PascalCase
91
-
-**namespace** : PascalCase
92
-
-**variable** : camelCase, **no** prefix/suffix ('_', 'm_',...) for class members
- files from the project : `#include "relative/path/to/the/file.h"`
96
-
- external files and std : `#include <file.h>`
97
-
- Only use [primary spellings for operators and tokens](https://en.cppreference.com/w/cpp/language/operator_alternative)
98
-
- Use auto sparingly. Don't use auto for [fundamental/built-in types](https://en.cppreference.com/w/cpp/language/types) and [fixed width integer types](https://en.cppreference.com/w/cpp/types/integer), except when initializing with a cast to avoid duplicating the type name.
0 commit comments