coding guidelines

From: Toon Knapen (toon_at_[hidden])
Date: 2001-07-05 05:05:18

A few questions

2.12): Functions describing the state of an object should be English
noun phrases (e.g. size(), not get_size()). 

I neither like the 'get' and 'set' verb before every member functions
since it clutters the code and makes it longer. But since you also
suggested to have class names all lowercase you can get into trouble as
in the next example :

class size {
};

class foo {
public:
  const size& size() const { return size_; }
private:
  size size_;
};

int main() {
  foo f;
  f.size();
  return 0;
}

Here the class and the function clash. The problem would be solved by
saying the classnames should start with a capital letter for instance.

7.1):Use ``//'' to delimit comments in lieu of ``/*...*/'' 

We and many other projects use for instance doxygen for generating
documentation. Doxygen (and other similar tools) needs the java-style of
commenting using /** ... */. So could we also allow this in the
guidelines ? I know, it's a bit awkward to change rules to the protocol
of some tools but this type of comment has also become quit standard.

8.1,8.6 && 8.7): Class organisation
As you prefer not to repeat the virtual keyword in derived classes and
you insist on using 'public:' liberally could we not say that the
inherited virtual functions need to go in a seperate public: block.

class Base {
 public:
    virtual void foo() const = 0; 
};

class Derived : public Base {
 public:
    Derived() {};
 public: // inherited from Base
    void foo();
}; 

This makes it clear which functions are in reality virtual and from
where they are first declared and documented (as the rule is to document
the virtual function only in the base class declaration)