]> git.saurik.com Git - apt.git/blame - doc/style.txt
add a missing \n to pl translation i had removed previously by accident
[apt.git] / doc / style.txt
CommitLineData
b2e465d6
AL
1Acronyms
2~~~~~~~~
3* dpkg is a 'word' the first d may be upper case - Dpkg
4* APT is a proper Acronym, all upper case please.
5
6Pkg - A Package
7Ver - A version
8
9Indenting, Comments, Etc
10~~~~~~~~~~~~~~~~~~~~~~~~
11Would make Linus cry :P However it is what I prefer. 3 space indent,
128 space tab all braces on seperate lines, function return on the same line
13as the function, cases aligned with their code. The 'indent' options for
14this style are:
15 indent -bl -bli0 -di1 -i3 -nsc -ts8 -npcs -npsl
16
17Each file gets a block at the top that should describe what the file does,
18basically a summary of purpose along with any special notes and
19attributions. The }}} and {{{ are folding marks if you have a folding
f30c4b6a
DK
20editor such as jed, the function separators are intended to give
21a visual separate between functions for easier browsing of the larger files,
b2e465d6
AL
22or indexed folding if you have such an editor.
23
24Each file should have 1 or 0 primary include files, that include
25file must always be the first include file included by the .cc. G++
26#pragma interface/implementation is used, as well as anti-include-twice
27#ifdefs.
28
29Include files, since there are so many, get their own subdirectory off
30the include search path, this is used consistently throughout all the code.
31#include "" should never be used for a global exported header file, only
32local ones.
33
34C++ Features
35~~~~~~~~~~~~
36Due to the legacy compiler heritage, exceptions, RTTI and name spaces are
37not used. Templates are used *sparingly* since G++ has traditionally had
38very weak support for them, this includes STL templates.
39
40Namespaces will probably be put in the code sometime after G++ 3, which will
41be a huge re-org again to make sanity, the majority of all nested things
42will go away.
43
44The C++ standard library's non parameterized types (string is included in
45this) are used freely when appropriate.
46
47The new C++ #include <iostream> (note the lack of a .h) is used for the
48standard library, but not for my code.
49
50Arguments and Ownership
51~~~~~~~~~~~~~~~~~~~~~~~
52[much of the code follows this now]
53These guidlines should be followed except in two cases.. the first
54is where it makes no sense, such as in a casting operator and the second is to
55retain API compatibility (this should be rare, since a change in the input
56almost always designates a change in ownership rules).
57
58 * Pass by value or pass by reference should borrow the object from the
59 caller
60 * Pass by non-const reference may be used to indicate a OUT type variable
61 * Pass by pointer (except in the case where the pointer is really an array)
62 should be used when the object will be retained or ownership will be
63 transfered. Ownership transference should be rare and noted by a comment.
64 * Standard C things (FILE * etc) should be left as is.
65
66 * Return by references should indicate a borrowed object
67 * Return by pointer (except arrays) should indicate ownership is
68 transfered. Return by pointer should not be used unless ownership is
69 transfered.
70 * Return by pointer to variable indicates ownership transfer unless the
71 pointer is an 'input' parameter (designated generally by an =0,
72 indicating a default of 'none')
73
f30c4b6a 74Non-ownership transferring arrays/lists should probably return an iterator
b2e465d6 75typedef or references..