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     ! 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.