8 |
|
|
9 |
Source code style: |
Source code style: |
10 |
|
|
11 |
- indentation is two spaces per level, no tabs. |
- do not use tabs. |
12 |
|
- indentation is two spaces per level. |
13 |
- end debug messages with a trailing newline (\n). |
- end debug messages with a trailing newline (\n). |
|
- no space between function and opening bracket. |
|
14 |
- one space between keyword and opening bracket. |
- one space between keyword and opening bracket. |
15 |
- one space and no newline before opening curly braces. |
- no space between function and opening bracket. |
16 |
|
- one space and no newline before opening curly braces of a block. |
17 |
- spaces surrounding assignment and comparisons. |
- spaces surrounding assignment and comparisons. |
18 |
- use current source code style as further reference. |
- use current source code style as further reference. |
19 |
|
|
20 |
Source code self documentation style: |
Source code documentation style: |
21 |
|
|
22 |
- JavaDoc compliant and Doxygen compatible. |
- JavaDoc compliant and Doxygen compatible. |
23 |
- Function documentation above functions in .c files, not .h files. |
- Function documentation above functions in .c files, not .h files. |
24 |
|
(This forces you to synchronize documentation and behaviour.) |
25 |
- Use current documentation style as further reference. |
- Use current documentation style as further reference. |
26 |
|
|
27 |
Bug reports and patches: |
Bug reports and patches: |
28 |
|
|
29 |
- Make sure you are reporting bugs or send patches against the latest sources.That usually means code in CVS |
- Make sure you are reporting bugs or send patches against the latest |
30 |
- If you think you found a bug make sure it's not already filed in the bugtracker at savannah |
sources. (From the latest release and/or the current CVS sources.) |
31 |
- If you have a fix put the patch on Savannah. If it's a patch that affects both core and arch specific |
- If you think you found a bug make sure it's not already filed in the |
32 |
stuff please separate them so that the core can be applied separately while leaving the other patch 'open' |
bugtracker at Savannah. |
33 |
The prefered way is to NOT touch archs you can't test and let maintainers take care of them. This is a good |
- If you have a fix put the patch on Savannah. If it is a patch that affects |
34 |
way to see if they are used at all - the same goes for unix netifs except tapif. |
both core and arch specific stuff please separate them so that the core can |
35 |
- Do not file a bug and post a fix to it to the patch area. Either a bug report or a patch will be enough. |
be applied separately while leaving the other patch 'open'. The prefered way |
36 |
|
is to NOT touch archs you can't test and let maintainers take care of them. |
37 |
|
This is a good way to see if they are used at all - the same goes for unix |
38 |
|
netifs except tapif. |
39 |
|
- Do not file a bug and post a fix to it to the patch area. Either a bug report |
40 |
|
or a patch will be enough. |
41 |
If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area. |
If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area. |
42 |
- Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two) |
- Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two) |
43 |
can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded |
can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded |