Refusing to define 2 or more classes in one .cpp file [closed]

Question

In my company there is implicit rule not to define multiple classes inside one .cpp file. The argumentation is that it looks like a mess and hard to read. But in my opinion it will make sense if the classes is related and not meant to be used outside compilation unit. Example:

example.h:

class ExampleState;

class Example {
    ...

    void SomeMethod();
private:
    ExampleState* state_;
}

example.cpp:

class ExampleState {
    ...
}

Example::SomeMethod() {
    state_ = new ExampleState();
    ...
}

What is your suggestion?

Answer 1

Both conventions will work, and given you are using a modern IDE, none has really an advantage over the other. So technically, this is purely opionated. However, if you have a lot of "cowboy coders" in the team, it is sometimes better to set more strict rules to avoid endless discussions about "when is a source file too big" and "are these classes related enough". And in a big team, once you introduce the freedom to put several classes into one file, there will be always one who starts to abuse that freedom.

So if most of the team (and especially your teamleader) really does not like the idea of putting more than one file into class, don't do it. If, however, the team takes this more as a rough guideline, and there are others thinking similar like you, and they approve the combination of two classes in one file during the usual peer review (you do regular code reviews, don't you?), then it is probably ok.

See also: How would you know if you've written readable and easily maintainable code?