Return to coding.txt CVS log

Up to [HATARI the Atari ST Emulator] / hatari / doc

Annotation of hatari/doc/coding.txt, revision 1.1.1.1

1.1       root        1: 
                      2:        Hatari coding guidelines
                      3:        ========================
                      4: 
                      5: Before writing new code or changing existing files, please read through these
                      6: coding guidelines to make sure that your changes are in harmony with the
                      7: existing source code.
                      8: 
                      9: - all source text files have to use Unix Line ending convention (line-feed only)
                     10:   (exception: Code like cart_asm.s which has to be compiled from the Atari TOS
                     11:   side should have DOS line endings (CR-LF) instead).
                     12: 
                     13: - Avoid non-ASCII characters in source code. Use UTF-8 encoding for non-english
                     14:   documentation files if necessary.
                     15: 
                     16: - Use TABs for indentation at the beginning of a line. Default TAB width is 8,
                     17:   but your source code should also look fine with other TAB width (e.g. 4).
                     18: 
                     19: - Use doxygen-style comments to document what each function is doing.
                     20: 
                     21: - No "magic" variable values.  Use either defines or enums to name the
                     22:   values and document what they mean if it's not obvious.
                     23: 
                     24: - Hatari uses code from many projects, e.g. the UAE CPU files, which
                     25:   use another coding style than the main source code. We keep the
                     26:   original coding style there for compatibility with the origin. So
                     27:   always try to adapt to the coding style of the file that you're
                     28:   currently editing.
                     29: 
                     30: - For new files, pick one of the existing coding styles, don't add a new one.
                     31: 
                     32: - Try to avoid including a header file from within another header file.
                     33:   Include all necessary header files in the right order in the *.c files
                     34:   instead. Including a header file from within another header file easily leads
                     35:   to a dependency hell which can become very painful when one of the header
                     36:   files clashes with a system header for example and must only be included
                     37:   in certain .c files only.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.