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
|
Hatari coding guidelines
========================
Before writing new code or changing existing files, please read through these
coding guidelines to make sure that your changes are in harmony with the
existing source code.
- all source text files have to use Unix Line ending convention (line-feed only)
(exception: Code like cart_asm.s which has to be compiled from the Atari TOS
side should have DOS line endings (CR-LF) instead).
- Avoid non-ASCII characters in source code. Use UTF-8 encoding for non-english
documentation files if necessary.
- Use TABs for indentation at the beginning of a line. Default TAB width is 8,
but your source code should also look fine with other TAB width (e.g. 4).
- Use doxygen-style comments to document what each function is doing.
- No "magic" variable values. Use either defines or enums to name the
values and document what they mean if it's not obvious.
- Hatari uses code from many projects, e.g. the UAE CPU files, which
use another coding style than the main source code. We keep the
original coding style there for compatibility with the origin. So
always try to adapt to the coding style of the file that you're
currently editing.
- For new files, use the main Hatari coding style (see the various *.c file
in the main src/ folder) for files that are specific to Hatari. Don't add
a new one coding style, unless the new files are shared with other projects
and need to be synchronized from time to time.
- Try to avoid including a header file from within another header file.
Include all necessary header files in the right order in the *.c files
instead. Including a header file from within another header file easily leads
to a dependency hell which can become very painful when one of the header
files clashes with a system header for example and must only be included
in certain .c files only.
|
