10 Tips for Cleaner C++ 20 Code - David Sackstein - CppCon 2022

dependency inversion is not dependency injection. dependency inversion is about having low level components (UIs, inputs, outputs, databases) depend on high level components (logic, use-cases) in terms of who is deciding on the interface (it should be the high level component that defines the interface)

This was a great talk. I really liked the IoC bit as I was looking for that in the C++ world as a former Java developer.

Lots of useful insights here. Thank you.

std::expected is expected in 2023, I want to know how much he giggled writing this title :) It's nice, we use lots of "Expected" in our code, the Try___ pattern. Many good aspects but for a 40 minute presentation I think it's a bit too much, could emphasize couple of them instead of trying to tell how to build an application, I know these aspects so it wasn't so hard for me to follow, others may have issues with it.

I'm going to push back a little on the "primitive obsession" smell. Every clean C++ talk seems to push for introducing more and more types, but this increases mental overhead of actually implementing something. I find this kind of advice to have a very strong bias towards maintenance, but in order to maintain something, first one has to actually reach the point when someone can pay for the maintanance, and trust me, there is going to be a lot of code thrown away before that, much more than finds its way to the final product. And if I wrote a struct or whatever is recommended for every number, string etc, I would never get to the point of releasing the product in the first place. Having powerful vocabulary types like int is what enabes rapid prototyping and experimentation, even if their ranges are too wide sometimes. The extra types have their uses, but if all advice a beginner hears is focused on maintenance only, at the expense of experimentation, no new C++ solution will ever be released.

I'm now more following the John Ousterhouse (TCL/TK creator) way of Software Engineeing. Then from SOLID nothing is left as a guideline except some little I and D. Large closed subsystems that encapsulate a lot of code.

Funny fact: the actual number of tips provided is 11, as shown on the last slide 53:15.

Would love to use modules, but it's not supported yet by any mayor compiler or build system, apart from some trivial examples.

That first bit of library code was so regular I wonder if it was generated by a solver from requirements. Anybody know?

A good presentation up to the 37 minute mark. After that, it takes a weird turn with few gems. Up to 37 is a good presentation overall, IMO.

32:05 what is the point of throwing if you are then going to wrap the constructor to catch the throw and return it as exceptional? just have the factory method be the one that does the validation.

I love the way he presents SOLID as good guidelines but we the caveat of "don't turn this into some kind of fanatical religion" (looking at you development managers)!

I don't feel like IOC containers are so powerful for the example presented. You should already be using interfaces and virtual methods along with composition instead of inheritance, in which case an IOC container is not required to substitute mock objects in tests. Yes a tiny amount of boilerplate can be eliminated with Hypodermic but you still have to code up the registration. Factory methods can be used to contain frequently used "recipes" of registrations and many of these are static anyways. I can see some utility in the container encapsulating all the instances of the related dependencies and maintaining their lifetimes uniformly, when there isn't a more natural way to manage lifetimes. I'm not sure if this is really an interesting design pattern for C++ programmers or if it is just a way to transplant a foreign idiom to C++ instead of using more native idioms.

Great talk, one comment though is to be very careful with using the "pimpl" idiom. I am currently working on a large codebase for an embedded system which is far from clean code (most is C++03 written as if it were C. It is basically every product developed over 20 years by 200+ engineers baked into a single monolithic application. Someone in the past decided to apply "pimpl" to every class their team wrote which makes navigating the code impossible. Pimpl has its uses but IMHO it should be used sparsely, and only after carefully considering the consequences.

This is pretty decent, but some opinions aren't explained: - why are comments bad in general? why prefer the additional indirection of declaring small use-one functions? - why is declaring too much in one file bad? why not group closely related definitions in a single file? what's the advantage pf having the extra indirection of putting related things into separate files?

Why pass the file name as const string&, if you have the std::filesystem::path object? that´s not clean

The example with std::expected and private constructor is unbearably bad. The point of "leave exceptions for exceptional situations" is about making erroneous states unrepresentable. Instead of validating duration and throwing if it is negative in runtime, you should instead define an abstraction of duration that makes invalid duration unrepresentable (should not compile).

clang-tidy issues lots of false positive for c++20 though

Pimpl idiom doesn't work if the outside class is a templated class, if the implementation needs to call back the outside class, for example to call inherited functions. Pimpl is ok, but in practice its usage is very limited in modern generic code.

As a counter perspective to this presentation, "Where does bad code come from?" by Casey Muratori is a must watch. https://www.youtube.com/watch?v=7YpFGkG-u1w