programming styles

[Gilbert Peffer]

Hi everybody,
Programming styles are probably one of the more contentious issues, and
different people are used to different things. But I think Bernd is right to
bring up the issue of programming style. There are probably a zillion ways
of doing things, but what I would like to propose is that we should agree on
a set of C++ programming style rules. This, I think, will avoid problems at
a stage, when many more people are starting to add code.

There is a very concise set of rules (actually 92 of them) at
http://www.geosoft.no/style.html#General%20Recomendations, which we could
take as a base for discussion. I would propose that we should go through the
list and  discard those rules we don't like or add other rules, and thus
keep those we think guarantee a minimum degree of consistency in the code.

What are your thoughts on this?

Gilbert


____________________________________________

Gilbert Peffer
Project Manager
Finance, IT & Engineering
International Centre for Numerical Methods in Engineering (CIMNE)
Building C1 -  North Campus UPC
Gran Capità s/n
08034 Barcelona, Spain

Movil: [phone]
Tel:   [phone]
       [phone]
Fax:   [phone]
E-mail: [hidden email]
Web:    www.cimne.upc.es

[Luigi Ballabio-3]

At 04:02 PM 12/19/00 +0100, you wrote:
>Hi everybody,
>Programming styles are probably one of the more contentious issues, and
>different people are used to different things. But I think Bernd is right to
>bring up the issue of programming style. There are probably a zillion ways
>of doing things, but what I would like to propose is that we should agree on
>a set of C++ programming style rules. This, I think, will avoid problems at
>a stage, when many more people are starting to add code.

Gilbert,
         I agree with bringing up the issue. I had a look at the
recommendations you cited, and I agree with most of them. Actually, on
second thought, even with some that are against ones that I currently use -
and my colleagues know how grumpy I can get about these :) The only ones I
still have doubts about are:

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.

17) 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.

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.


Bye for now,
                 Luigi

[Luigi Ballabio-3]

Just a thought I had writing some code, regarding rule 8 of the guidelines
(i.e., Names representing template types should be a single uppercase letter).

It is true that, for instance,

template <class Type> class Handle;

does not give any information more than

template <class T> class Handle;

does, so that in this case rule 8 holds.

However, there are cases where a longer name does add information. Namely,

template <class RandomAccessIterator> class SteppingIterator;
template <class Iterator, class UnaryPredicate> class FilteringIterator;

are in my opinion more understandable even at a superficial glance than

template <class I> class SteppingIterator;
template <class I, class P> class FilteringIterator;

because in the former case the names express the requirements for the
template arguments with single terms which are clear enough to any one that
happened to browse through the C++ standard.

Bottom line: 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.

What do you think?

Bye,
        Luigi