Needlessly Public

I don't know about the size of their codebase or the extent that it has consumers outside of the repository the author has access too, but once a code smell like this has been identified, it seems a bit strange not to just eliminate it completely straight away.

The hacks he describes seem like a good first pass to identify how much of the code relies write access rather than just read-only without having to change all the legacy code, but IMHO it'd be better to just move the member into the private section and then fix up the compile errors that produces.

Sure, fixing up all the compile issues requires a bit more upfront work, but it stops anyone else using the deprecated interface, and makes the design a bit more consistent when all access is done the same way. Having identified the legacy code use and then shoving it under the carpet just makes this someone else's problem in the future, and they will have to waste some time to go down a similar discovery path, potentially discovering an even bigger problem at that stage.

It’s baffling how the fear or reluctance of introducing a change drives a series of insane design decisions to accommodate the existing codebase.

Counterpoint: this kind of fiddling is what makes C++ unpleasant and unproductive language.

You spend so much time finding solutions to problems that don't exist in other languages and contribute nothing to actually shipping the software

"Let's make this member private, because others should not touch it".

"Shit this function I just wrote must touch it. I know! I'll add a friend declaration".

Now you changed the header and spend 5 minutes recompiling the whole program.

I speak as someone who wrote 120k loc of C++ in SumatraPDF.

I just don't bother making things private. Or to put it differently: I use other ways to do it, when possible (confine as much as possible to .cpp files, don't expose classes at all) but if I can't hide the whole class like that, I would rather expose it all than waste my cycles on micro-managing visibility.

"Ok, it works for you but surely won't scale to large teams!"

All the giant ruby, python, javascript codebases tell us otherwise.

On a side note: I don't think I ever seen Go being praised for coming up with the brilliant design of making public / private visibility a matter of a module, not struct, like literally everyone else, even those who did it after Go. This strikes the perfect balance of being able to hide details of a module without affecting productivity of people implementing the module.

In my opinion, the opposite of this is a bigger problem in most large codebases. Not exposing functionality that other parts of the code legitimately need to access is more common than exposing parts which shouldn't be used.