rules

[Gilbert Peffer]

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?]