Posted by
Gilbert Peffer on
Jan 24, 2001; 12:19pm
URL: http://quantlib.414.s1.nabble.com/rules-tp1684.html
Hi everybody,
Please find below the suggestions for changing the style guidelines in
http://geosoft.no/style.html. I marked those suggestions with CONTENTIOUS
where people didn't agree.
Please have another look at this list and provide some suggestions for the
still contentious bits.
Thanks, Gilbert
-----------------------------------------
Luigi Ballabio
--------------
5) Ok for having #defines in uppercase. I'd prefer enumerations inside
classes and static const class variables in mixed case starting with lower
case.
8) [...] We could relax rule 8, and leave it to the judgment of the
programmer whether a fully specified name would help. If not, the
single-character rule applies.
17) CONTENTIOUS ok for employee.setName(). However, employee.getName() seems
a bit
redundant to me - employee.name() is just as clear. Unfortunately this
would conflict with 6) since name() is not a verb (well, not in this case).
What the hey, you decide and tell me. [Nando argued against it. Shall we
leave the rule as it is?]
49) I would make an exception for static const variables, for which I see
no reason for access through a get() method.
69) I find an indentation of 4 more readable than 2. But hey, that's just
me, I can get used to it.
70) I like better example 1 for classes and functions too. But again,
that's just me.
83) f (x) looks very strange to me with the space in the middle. Then
again...
90) We'll have to stick to /* ... */ when comments are to be extracted by
Doxygen.
============================================================================
=========
Gilbert Peffer
22. I often call variable or object containers <set>, although for a
mathematical purist, this can provoke considerable grief
24. I usually use <num>, but <no> is as good. One may as well permit both
36. This is currently in contradiction to some of the code in Quantlib. I
myself are not too consistent in this particular style case. What do you
think?
38. CONTENTIOUS: ...TABs should be avoided. Does anybody have an idea of the
real impact
the use of TABs can have? [Shall we delete this rule?]
69. I prefer 4 spaces
73. I prefer the SUN recommendation, but this has no big impact anyway, I
think
87. CONTENTIOUS I would like to add a suggestion for function/subroutine
definitions.
For long argument lists (and for short ones as well), I prefer to stack the
arguments
runThisRoutine (int numNodes,
int numElements,
double* coordinateSet,
int* connectivityList) {
blah blah
}
[I still prefer argument stacking for readability. What are your thoughts?]