1
0
Fork 0
mirror of https://git.rwth-aachen.de/acs/public/villas/node/ synced 2025-03-09 00:00:00 +01:00

Update contribution guide

Signed-off-by: Steffen Vogel <steffen.vogel@opal-rt.com>
This commit is contained in:
Steffen Vogel 2023-09-07 13:23:13 +02:00
parent 20e2f7275f
commit 9e34ffaadd

View file

@ -1,171 +1,21 @@
# Contribution guidelines
## Coding style
<!--
SPDX-FileCopyrightText: 2014-2023 Institute for Automation of Complex Power Systems, RWTH Aachen University
SPDX-License-Identifier: Apache-2.0
-->
### Naming
## Coding standards
Variables should use lower case names with underscores.
There are now special visibility or type prefixes.
Structure members should not use abbreviated names:
Good
```
struct A {
char *message;
int length;
}
```
Bad:
```
struct A {
char *msg;
int len;
}
```
### Placement of spaces
In variable declarations (including in function parameters) we place the asterisk next to the variable name.
Good:
```c
int *number;
```
Bad:
```c
int * number;
int* number;
```
In function return values we place the asterisk between spaces
Good:
```c
void * my_thread()
{
}
```
Bad:
```c
void *mythread()
{
}
void * mythread()
{
}
```
In expressions we place spaces between most elements but not between parantheses:
Good:
```
int a = ((5 * 10) + 10 ) % 22;
```
Bad:
```
int a = ((5*10)+10)%22;
```
We also put spaces infront / after most keywords such as `if`, `while`, ...
Good:
```c
for (int a = 0; a < 1; a++) {
...
}
```
Bad:
```c
for(int a = 0; a < 1; a++) {
...
}
```
### Line length
Try to limit line length to about 160 characters.
### Indention
We use tabs for indention which should be displayed as 8 spaces by your editor.
### Brace placement
For everything except functions we place the opening brace in the same line:
Good:
```c
struct A {
enum {
A,
B
} choice;
}
if (true) {
}
```
Bad:
```
struct A
{
enum
{
A,
B
} choice;
}
if (true)
{
}
```
However, in functions we place the brace in a new line:
```
void main()
{
}
```
### #define and Macro Names
Are always written UPPERCASE.
Good:
```c
#define HUGEPAGESIZE (1 << 22)
#define MAX(a, b) (a > b ? a ? b)
```
Bad:
```c
#define max(a, b) (a > b ? a ? b)
```
We are following the [LLVM C++ Coding Standards](https://llvm.org/docs/CodingStandards.html).
## Always work on feature branches
Please branch from `develop` to create a new _feature_ branch.
Please branch from `master` to create a new _feature_ branch.
Please create a new _feature_ branch for every new feature or fix.
## Do not commit directly to `master` or `develop`.
## Do not commit directly to `master`.
Use your _feature_ branch.
@ -174,8 +24,3 @@ Please rebase your work against the `develop` before submitting a merge reqeuest
## Make the CI happy :-)
Only branches which pass the CI can be merged.
## License
- SPDX-FileCopyrightText: 2014-2023 Institute for Automation of Complex Power Systems, RWTH Aachen University
- SPDX-License-Identifier: Apache-2.0