1IJG JPEG LIBRARY:  CODING RULES
2
3This file was part of the Independent JPEG Group's software:
4Copyright (C) 1991-1996, Thomas G. Lane.
5It was modified by The libjpeg-turbo Project to include only information
6relevant to libjpeg-turbo.
7For conditions of distribution and use, see the accompanying README file.
8
9
10Since numerous people will be contributing code and bug fixes, it's important
11to establish a common coding style.  The goal of using similar coding styles
12is much more important than the details of just what that style is.
13
14In general we follow the recommendations of "Recommended C Style and Coding
15Standards" revision 6.1 (Cannon et al. as modified by Spencer, Keppel and
16Brader).  This document is available in the IJG FTP archive (see
17jpeg/doc/cstyle.ms.tbl.Z, or cstyle.txt.Z for those without nroff/tbl).
18
19Block comments should be laid out thusly:
20
21/*
22 *  Block comments in this style.
23 */
24
25We indent statements in K&R style, e.g.,
26        if (test) {
27          then-part;
28        } else {
29          else-part;
30        }
31with two spaces per indentation level.  (This indentation convention is
32handled automatically by GNU Emacs and many other text editors.)
33
34Multi-word names should be written in lower case with underscores, e.g.,
35multi_word_name (not multiWordName).  Preprocessor symbols and enum constants
36are similar but upper case (MULTI_WORD_NAME).  Names should be unique within
37the first fifteen characters.
38
39Note that each function definition must begin with GLOBAL(type), LOCAL(type),
40or METHODDEF(type).  These macros expand to "static type" or just "type" as
41appropriate.  They provide a readable indication of the routine's usage and
42can readily be changed for special needs.  (For instance, special linkage
43keywords can be inserted for use in Windows DLLs.)
44
45A similar solution is used for external function declarations (see the EXTERN
46macro.)
47
48
49The JPEG library is intended to be used within larger programs.  Furthermore,
50we want it to be reentrant so that it can be used by applications that process
51multiple images concurrently.  The following rules support these requirements:
52
531. Avoid direct use of file I/O, "malloc", error report printouts, etc;
54pass these through the common routines provided.
55
562. Minimize global namespace pollution.  Functions should be declared static
57wherever possible.  (Note that our method-based calling conventions help this
58a lot: in many modules only the initialization function will ever need to be
59called directly, so only that function need be externally visible.)  All
60global function names should begin with "jpeg_".
61
623. Don't use global variables; anything that must be used in another module
63should be in the common data structures.
64
654. Don't use static variables except for read-only constant tables.  Variables
66that should be private to a module can be placed into private structures (see
67the system architecture document, structure.txt).
68
695. Source file names should begin with "j" for files that are part of the
70library proper; source files that are not part of the library, such as cjpeg.c
71and djpeg.c, do not begin with "j".  Keep compression and decompression code in
72separate source files --- some applications may want only one half of the
73library.
74
75Note: these rules (particularly #4) are not followed religiously in the
76modules that are used in cjpeg/djpeg but are not part of the JPEG library
77proper.  Those modules are not really intended to be used in other
78applications.
79