File: coding_style.md

package info (click to toggle)
openssl-ibmca 1.4.0-1
  • links: PTS
  • area: main
  • in suites: bookworm, bullseye, buster, forky, sid, trixie
  • size: 416 kB
  • sloc: ansic: 3,525; makefile: 21; sh: 14
file content (194 lines) | stat: -rw-r--r-- 3,856 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
# Coding Style

This document describes the preferred coding style for the openssl-ibmca
project. It is based on the OpenCryptoki coding style.

Coding style is always of personal taste, but defining one coding style makes
the maintenance of the project easier and gives a standard face for the source
code.

The inspiration and formatting of this document came from the Linux Kernel
coding style document, but make no assumption as the coding style differ from
each other on some aspects.


## 1. Indentation

Tabs are 4 space characters, differently from many projects that define it as 8
characters. The main idea behind this is that 4 characters should give you a
clear idea about where a block of control starts and ends.


## 2. Line length

To keep the code readable and maintainable, the limit on the length of lines is
80 columns and this is a strongly preferred limit.


## 3. Placing Braces and Spaces

Here we follow Kernighan and Ritchie teachings. An opening brace is put last on
the line, and put the closing brace first, e.g.:

```
    if (x == 0) {
        do_y();
    }
```

This applies to all non-function statement blocks: if, switch, for, while, do.
Another example:

```
    switch (value) {
    case 1:
        return "one";
    case 2:
        return "two";
    case 3:
        return "three";
    default:
        return NULL;
    }
```

However, there is one special case, functions: their opening brace stays at the
beginning of the next line, e.g.:

```
    int func(int x)
    {
        do_something();
    }
```

Follow other examples:

```
    do {
        do_something();
    } while (condition);
```

```
    if (x == 1) {
        do_one();
    } else if (x > 1) {
        do_two();
    } else {
        do_three();
    }
```

It is not necessary to use braces when there is only a single statement, e.g.:

```
    if (x == 1)
        do_something();
```

and

```
    if (x == 1)
        do_something();
    else
        do_something_else();
```

This does not apply when only one branch in a conditional statement is a single
statement. In this, case use braces in all branches, e.g.:

```
    if (x == 1) {
        do_something();
        do_something_more();
    } else {
        do_something_else();
    }
```


### 3.1. Spaces

Always use a space after these keywords: *if, switch, case, for, do, while*.

```
    if (condition) {
        ...
    }
```

The following keywords should not have a space between them and their
parentheses: *sizeof, typeof*.

```
    s = sizeof(struct alg);
```

**Do not** add spaces around (inside) parenthesized expressions, e.g.:

```
    if ( x == 1 ) {
        ...
    }
```

When declaring a pointer or a function that returns a pointer type, the ``*``
must be put adjacent to the data name or function name, e.g.:

```
    int *ptr;
    void ptrcopy(int *dest, char *src);
    int *get_address(int *ptr);
```

Use:
 * one space on each side of the following operators:

```
    =  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
```

 * no space after unary operators:

```
    &  *  +  -  ~  !
```

 * no space before postfix/after prefix increment and decrement operators:

```
    ++  --
```

 * no space around the ``.`` and ``->`` structure member operators.

**Do not** leave trailing whitespace at the end of lines.


## 4. Naming

Avoid using CamelCase. It is preferred to name variables and functions by
including an underscore between words, e.g.:

```
    int person_counter;
```


## 5. Commenting

Comments in the code make everyone's life easier, but don't be too verbose.
Focus on **what** your function does and less on **how** it does.

The preferred style for long multi-line comments is:

```
    /*
     * This is a multi-line comment.
     *
     * A column of asterisks on the left side,
     * with beginning and ending almost-blank lines.
     */
```