kc3-lang/libjpeg-turbo/doc/coderules.txt
Branch
-
Show log
Commit
-
Hash : e69dd40c
Author :
Date : 2024-01-23T13:26:41
Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226
-
doc/coderules.txt
-
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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
IJG JPEG LIBRARY: CODING RULES This file was part of the Independent JPEG Group's software: Copyright (C) 1991-1996, Thomas G. Lane. It was modified by The libjpeg-turbo Project to include only information relevant to libjpeg-turbo. For conditions of distribution and use, see the accompanying README.ijg file. Since numerous people will be contributing code and bug fixes, it's important to establish a common coding style. The goal of using similar coding styles is much more important than the details of just what that style is. In general we follow the recommendations of "Recommended C Style and Coding Standards" revision 6.1 (Cannon et al. as modified by Spencer, Keppel and Brader). This document is available in the IJG FTP archive (see jpeg/doc/cstyle.ms.tbl.Z, or cstyle.txt.Z for those without nroff/tbl). Block comments should be laid out thusly: /* * Block comments in this style. */ We indent statements in K&R style, e.g., if (test) { then-part; } else { else-part; } with two spaces per indentation level. (This indentation convention is handled automatically by GNU Emacs and many other text editors.) Multi-word names should be written in lower case with underscores, e.g., multi_word_name (not multiWordName). Preprocessor symbols and enum constants are similar but upper case (MULTI_WORD_NAME). Names should be unique within the first fifteen characters. Note that each function definition must begin with GLOBAL(type), LOCAL(type), or METHODDEF(type). These macros expand to "static type" or just "type" as appropriate. They provide a readable indication of the routine's usage and can readily be changed for special needs. (For instance, special linkage keywords can be inserted for use in Windows DLLs.) A similar solution is used for external function declarations (see the EXTERN macro.) The JPEG library is intended to be used within larger programs. Furthermore, we want it to be reentrant so that it can be used by applications that process multiple images concurrently. The following rules support these requirements: 1. Avoid direct use of file I/O, "malloc", error report printouts, etc; pass these through the common routines provided. 2. Minimize global namespace pollution. Functions should be declared static wherever possible. (Note that our method-based calling conventions help this a lot: in many modules only the initialization function will ever need to be called directly, so only that function need be externally visible.) All global function names should begin with "jpeg_". 3. Don't use global variables; anything that must be used in another module should be in the common data structures. 4. Don't use static variables except for read-only constant tables. Variables that should be private to a module can be placed into private structures (see the system architecture document, structure.txt). 5. Source file names should begin with "j" for files that are part of the library proper; source files that are not part of the library, such as cjpeg.c and djpeg.c, do not begin with "j". Keep compression and decompression code in separate source files --- some applications may want only one half of the library. Note: these rules (particularly #4) are not followed religiously in the modules that are used in cjpeg/djpeg but are not part of the JPEG library proper. Those modules are not really intended to be used in other applications.