Skip to content

Commit 0e5ea62

Browse files
committed
CONTRIBUTING: add some coding and style conventions
1 parent 1a432cb commit 0e5ea62

File tree

1 file changed

+48
-3
lines changed

1 file changed

+48
-3
lines changed

CONTRIBUTING.md

Lines changed: 48 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -38,9 +38,45 @@ Chat history logs can be found at https://gnusha.org/secp256k1/.
3838

3939
## Contributor workflow & peer review
4040

41-
The Contributor Workflow & Peer Review in libsecp256k1 are similar to Bitcoin Core's workflow and review processes described in Core's [CONTRIBUTING.md](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md).
42-
43-
### Test coverage
41+
The Contributor Workflow & Peer Review in libsecp256k1 are similar to Bitcoin Core's workflow and review processes described in its [CONTRIBUTING.md](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md).
42+
43+
### Coding conventions
44+
45+
In addition, libsecp256k1 tries to maintain the following coding conventions:
46+
47+
* No runtime heap allocation (e.g., no `malloc`) unless explicitly requested by the caller (via `secp256k1_context_create` or `secp256k1_scratch_space_create`, for example). Morever, it should be possible to use the library without any heap allocations.
48+
* The tests should cover all lines and branches of the library (see [Test coverage](#coverage)).
49+
* Operations involving secret data should be tested for being constant time with respect to the secrets (see [src/ctime_tests.c](src/ctime_tests.c)).
50+
* Local variables containing secret data should be cleared explicitly to try to delete secrets from memory.
51+
* Use `secp256k1_memcmp_var` instead of `memcmp` (see [#823](https://github.com/bitcoin-core/secp256k1/issues/823)).
52+
53+
#### Style conventions
54+
55+
* Commits should be atomic and diffs should be easy to read. For this reason, do not mix any formatting fixes or code moves with actual code changes. Make sure each individual commit is hygienic: that it builds successfully on its own without warnings, errors, regressions, or test failures.
56+
* New code should adhere to the style of existing, in particular surrounding, code. Other than that, we do not enforce strict rules for code formatting.
57+
* The code conforms to C89. Most notably, that means that only `/* ... */` comments are allowed (no `//` line comments). Moreover, any declarations in a `{ ... }` block (e.g., a function) must appear at the beginning of the block before any statements. When you would like to declare a variable in the middle of a block, you can open a new block:
58+
```C
59+
void secp256k_foo(void) {
60+
unsigned int x; /* declaration */
61+
int y = 2*x; /* declaration */
62+
x = 17; /* statement */
63+
{
64+
int a, b; /* declaration */
65+
a = x + y; /* statement */
66+
secp256k_bar(x, &b); /* statement */
67+
}
68+
}
69+
```
70+
* Use `unsigned int` instead of just `unsigned`.
71+
* Use `void *ptr` instead of `void* ptr`.
72+
* Arguments of the publicly-facing API must have a specific order defined in [include/secp256k1.h](include/secp256k1.h).
73+
* User-facing comment lines in headers should be limited to 80 chars if possible.
74+
* All identifiers in file scope should start with `secp256k1_`.
75+
* Avoid trailing whitespace.
76+
77+
### Tests
78+
79+
#### Coverage
4480

4581
This library aims to have full coverage of reachable lines and branches.
4682

@@ -60,3 +96,12 @@ To create a HTML report with coloured and annotated source code:
6096

6197
$ mkdir -p coverage
6298
$ gcovr --exclude 'src/bench*' --html --html-details -o coverage/coverage.html
99+
100+
#### Exhaustive tests
101+
102+
There are tests of several functions in which a small group replaces secp256k1.
103+
These tests are *exhaustive* since they provide all elements and scalars of the small group as input arguments (see [src/tests_exhaustive.c](src/tests_exhaustive.c)).
104+
105+
### Benchmarks
106+
107+
See `src/bench*.c` for examples of benchmarks.

0 commit comments

Comments
 (0)