D
Dave Harris
In particular, I wonder if it is a good idea to separate mutating
from const functions, e.g. setters and getters.
I think so. That's partly because my style of programming is influenced by
functional (ie side-effect free) languages. I think in terms of the const
interface and the non-const interface, and I like to express that fairly
directly in the code.
I tend to have a lot more getters than setters. I have noticed other
people who seem to organise their interfaces around instance variables,
with a get/set pair for each one, which in my view is the wrong way to go
about it.
Instead, I would prefer grouping member functions based on some
higher level criteria. For instance, if a class implements an
interface, the interface members should be put in their own
section titled "IfaceX implementation" or something. Likewise,
ctors and dtor could reside in a section titled "Construction
and destruction", for example.
I do that as well. A typical class will begin with static methods, then
constructors and destructors, then const accessors, then setters, then
operations, then variables. This is repeated three times for public,
protected and private, in that order, with sections omitted if not needed.
Some classes have extra sections for particular interfaces. For example, I
have several classes which are std-like containers and which have empty,
size, and begin/end pairs in their own section.
However, I don't see any need for section title comments here. It's enough
to separate the sections with blank lines. People who know C++ don't need
to be told that a section contains, eg, constructors and destructors,
because's it's obvious.
Also, it might be fine I tell which members are implicitly defined for
a class:
I would say that was again stating the obvious.
-- Dave Harris, Nottingham, UK.