PageRenderTime 20ms CodeModel.GetById 11ms app.highlight 3ms RepoModel.GetById 1ms app.codeStats 0ms

/src/FreeImage/Source/LibJPEG/coderules.txt

https://bitbucket.org/cabalistic/ogredeps/
Plain Text | 118 lines | 95 code | 23 blank | 0 comment | 0 complexity | 498236f15a36b3e768af8233efb65c7c MD5 | raw file
  1IJG JPEG LIBRARY:  CODING RULES
  2
  3Copyright (C) 1991-1996, Thomas G. Lane.
  4This file is part of the Independent JPEG Group's software.
  5For conditions of distribution and use, see the accompanying README file.
  6
  7
  8Since numerous people will be contributing code and bug fixes, it's important
  9to establish a common coding style.  The goal of using similar coding styles
 10is much more important than the details of just what that style is.
 11
 12In general we follow the recommendations of "Recommended C Style and Coding
 13Standards" revision 6.1 (Cannon et al. as modified by Spencer, Keppel and
 14Brader).  This document is available in the IJG FTP archive (see
 15jpeg/doc/cstyle.ms.tbl.Z, or cstyle.txt.Z for those without nroff/tbl).
 16
 17Block comments should be laid out thusly:
 18
 19/*
 20 *  Block comments in this style.
 21 */
 22
 23We indent statements in K&R style, e.g.,
 24	if (test) {
 25	  then-part;
 26	} else {
 27	  else-part;
 28	}
 29with two spaces per indentation level.  (This indentation convention is
 30handled automatically by GNU Emacs and many other text editors.)
 31
 32Multi-word names should be written in lower case with underscores, e.g.,
 33multi_word_name (not multiWordName).  Preprocessor symbols and enum constants
 34are similar but upper case (MULTI_WORD_NAME).  Names should be unique within
 35the first fifteen characters.  (On some older systems, global names must be
 36unique within six characters.  We accommodate this without cluttering the
 37source code by using macros to substitute shorter names.)
 38
 39We use function prototypes everywhere; we rely on automatic source code
 40transformation to feed prototype-less C compilers.  Transformation is done
 41by the simple and portable tool 'ansi2knr.c' (courtesy of Ghostscript).
 42ansi2knr is not very bright, so it imposes a format requirement on function
 43declarations: the function name MUST BEGIN IN COLUMN 1.  Thus all functions
 44should be written in the following style:
 45
 46LOCAL(int *)
 47function_name (int a, char *b)
 48{
 49    code...
 50}
 51
 52Note that each function definition must begin with GLOBAL(type), LOCAL(type),
 53or METHODDEF(type).  These macros expand to "static type" or just "type" as
 54appropriate.  They provide a readable indication of the routine's usage and
 55can readily be changed for special needs.  (For instance, special linkage
 56keywords can be inserted for use in Windows DLLs.)
 57
 58ansi2knr does not transform method declarations (function pointers in
 59structs).  We handle these with a macro JMETHOD, defined as
 60	#ifdef HAVE_PROTOTYPES
 61	#define JMETHOD(type,methodname,arglist)  type (*methodname) arglist
 62	#else
 63	#define JMETHOD(type,methodname,arglist)  type (*methodname) ()
 64	#endif
 65which is used like this:
 66	struct function_pointers {
 67	  JMETHOD(void, init_entropy_encoder, (int somearg, jparms *jp));
 68	  JMETHOD(void, term_entropy_encoder, (void));
 69	};
 70Note the set of parentheses surrounding the parameter list.
 71
 72A similar solution is used for forward and external function declarations
 73(see the EXTERN and JPP macros).
 74
 75If the code is to work on non-ANSI compilers, we cannot rely on a prototype
 76declaration to coerce actual parameters into the right types.  Therefore, use
 77explicit casts on actual parameters whenever the actual parameter type is not
 78identical to the formal parameter.  Beware of implicit conversions to "int".
 79
 80It seems there are some non-ANSI compilers in which the sizeof() operator
 81is defined to return int, yet size_t is defined as long.  Needless to say,
 82this is brain-damaged.  Always use the SIZEOF() macro in place of sizeof(),
 83so that the result is guaranteed to be of type size_t.
 84
 85
 86The JPEG library is intended to be used within larger programs.  Furthermore,
 87we want it to be reentrant so that it can be used by applications that process
 88multiple images concurrently.  The following rules support these requirements:
 89
 901. Avoid direct use of file I/O, "malloc", error report printouts, etc;
 91pass these through the common routines provided.
 92
 932. Minimize global namespace pollution.  Functions should be declared static
 94wherever possible.  (Note that our method-based calling conventions help this
 95a lot: in many modules only the initialization function will ever need to be
 96called directly, so only that function need be externally visible.)  All
 97global function names should begin with "jpeg_", and should have an
 98abbreviated name (unique in the first six characters) substituted by macro
 99when NEED_SHORT_EXTERNAL_NAMES is set.
100
1013. Don't use global variables; anything that must be used in another module
102should be in the common data structures.
103
1044. Don't use static variables except for read-only constant tables.  Variables
105that should be private to a module can be placed into private structures (see
106the system architecture document, structure.txt).
107
1085. Source file names should begin with "j" for files that are part of the
109library proper; source files that are not part of the library, such as cjpeg.c
110and djpeg.c, do not begin with "j".  Keep source file names to eight
111characters (plus ".c" or ".h", etc) to make life easy for MS-DOSers.  Keep
112compression and decompression code in separate source files --- some
113applications may want only one half of the library.
114
115Note: these rules (particularly #4) are not followed religiously in the
116modules that are used in cjpeg/djpeg but are not part of the JPEG library
117proper.  Those modules are not really intended to be used in other
118applications.