-
Notifications
You must be signed in to change notification settings - Fork 6
/
CONVENTIONS
82 lines (72 loc) · 3.25 KB
/
CONVENTIONS
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
79
80
81
82
#############################################################
# This File is based on CONVENTIONS from fftw-3.3alpha1
# TODO: I still have to check some files, if this coding
# standard was applicated correct.
# Double commented lines mark coding standards that
# are introduced by FFTW but are not yet used in all
# the PNFFT code.
# (Because I found the CONVENTIONS file of FFTW after
# I had written a lot of PNFFT code - Sorry)
#############################################################
Code conventions (hopefully everywhere) used internally by PNFFT (not in API):
LEARN FROM THE MASTERS: read Ken Thompson's C compiler in Plan 9.
Avoid learning from C++/Java programs.
## INDENTATION: K&R, 5 spaces/tab. In case of doubt, indent -kr -i5.
# TODO: We have used another indentation with 2 spaces/tab. I search for
# an editor with nice automatic indentation (that covers all the nasty
# special cases).
## NAMES: keep them short. Shorter than you think. The Bible was written
## without vowels. Don't outsmart the Bible.
Common names:
R : real type, aka fftw_real
## E : real type for local variables (possibly extra precision)
C : complex type
## sz : size
## vecsz : vector size
is, os : input/output stride
## ri, ii : real/imag input (complex data)
## ro, io : real/imag output (complex data)
## I, O : real input/output (real data)
## A : assert
## CK : check
## S : solver, defined internally to each solver file
## P : plan, defined internally to each solver file
## k : codelet
X(...) : used for mangling of external FFTW names (see below)
XM(...) : used for mangling of external FFTW_MPI names (see below)
PX(...) : used for mangling of external PFFT names (see below)
PNX(...) : used for mangling of external PNFFT names (see below)
## K(...) : floating-point constant, in E precision
If a name is used often and must have the form pnfft_foo to avoid
namespace pollution, #define FOO pfft_foo and use the short name.
Leave that hungarian crap to MS. foo_t counts as hungarian: use
foo instead. foo is lowercase so that it does not look like a DOS
program. Exception: typedef struct foo_s {...} foo; instead of
typedef struct foo {...} foo; for C++ compatibility.
NAME MANGLING: use PNX(foo) for external names instead of pnfft_foo.
PNX(foo) expands to pnfftf_foo, pnfft_foo or pnfftl_foo, depending on the
precision. (Unfortunately, this is a ugly form of hungarian
notation. Grrr...) Names that are not exported do not need to be
mangled.
## REPEATED CODE: favor a table. E.g., do not write
##
## foo("xxx", 1);
## foo("yyy", 2);
## foo("zzz", -1);
##
## Instead write
##
## struct { const char *nam, int arg } footab[] = {
## { "xxx", 1 },
## { "yyy", 2 },
## { "zzz", -1 }
## };
##
## and loop over footab. Rationale: it saves code space.
## Similarly, replace a switch statement with a table whenever
## possible.
##
## C++: The code should compile as a C++ program. Run the code through
## gcc -xc++ . The extra C++ restrictions are unnecessary, of
## course, but this will save us from a flood of complaints when
## we release the code.