(I feel funny throwing my 2c on these generic threads when I've contributed zip, but John opened it up so...)
- Exceptions, a.k.a. the surest way to templates-everything (via RAII-everything). - State. When performance allows, avoid storing duplicate state in members; instead have methods ask when they need. The plugin SDK rule is "release handles before re-enabling the HTTP transaction", which means the same thing; state you don't have can't go stale, pointers you don't have can't be dangling :-) - STL/standard library usage? std::string is handy, so is std::map... slippery slope. -----Original Message----- From: John Plevyak [mailto:jplev...@acm.org] Sent: Thursday, December 10, 2009 10:45 AM To: trafficserver-dev@incubator.apache.org Subject: Re: coding style - simple vs. complex C++ I would like to open up discussion on the simple vs. complex C++/OO issue. There is a continuum between basic K&R C and full-blown meta-template programming, virtual everything, multiple-inheritance, massively overloaded, super Object-Oriented C++. Somewhere there is a happy point where most contributors can read the code and understand it and make useful contributions while still taking advantage of the power that C++ offers where necessary and useful. Such a middle ground might include (these are some topics we might want to discuss): - favor shallow class hierarchies - try not to use multiple-inheritance - use templates only when necessary and in the simplest form necessary to accomplish the goal - don't use trivial accessors: int getFoo() { return _foo; } void setFoo(int foo) { _foo = foo; } which are a huge waste of time and energy and are less readable and no safer than just accessing the variable directly. - don't include gobs of boilerplate code on the off chance that someone might decide to extend the class unless you really are planning to extend the class in that way - don't make functions virtual unless you *are* overloading them and even then, consider if a conditional might not just be clearer and faster and result in a shallower class hierachy - don't overload operators except in truly special cases (e.g. smart pointers) - don't new/free things which are really static parts of another object just because that is how Java does it - don't have constructors and destructors do lots of complicated stuff as a side effect of creating/destroying the object - think of new things to add to this list :) Many of these things were hugely popular in the blush of first love with the OO paradigm, but have since fallen from favor. Nevertheless it might be helpful to discuss this as part of coding style. john Protected by Websense Hosted Email Security -- www.websense.com
