Question

Keeping a consistent style is important when adding to an existing project. But what about when subclassing heavily from a library in a new project when there are distinct differences between the project’s and the library’s standard?

I’m working on a project with a particular coding style, specifically when it comes to how classes and methods within those classes are named. One module of the project however, the UI, relies heavily on an external library and most of the classes in this module will overload this library. In this case, it’s Qt, but it could be anything.

In such a situation, is it better to stick to the style used by the API or use the project’s style for new functions? As an example, Qt uses camelCase for its function declarations whereas this project uses UpperCase. Consider something like this:

class MyNewWidget : public QWidget {
    Q_OBJECT
public:
    void setVisible(bool visible); // QWidget override
    void SetNewFeature(std::string feature_key); // New function

    bool visibility() const; // I know you can't override that, but bear with me
    std::string GetNewFeature() const; // propertyName() vs GetPropertyName()
};

This feels along the same lines as subclassing from STL which uses lower_case. There are some good reasons in that case to follow convention in some instances at least, e.g. when typedef’ing iterator types or if you want your begin/end/swap functions to be usable by <algorithm> et al.

But I’m at a wall on this one.

Answer 1

I would strive to maintain a single style per class/file/module where possible. The difficulty comes when you’re trying to think of the name of a method, and the less you can cause others to stop and think, the better. Of course, a good IDE/editor should correct your case.

Another option is to favor composition over inheritance. This would mean you’ll write new methods using your projects style that delegate to the Qt methods internally. It will give you the added benefit of not being tied to the Qt API if that’s at all a concern.