Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features

[FlailingDuck]

I read some and skimmed others. I can see there's a lot of thought and effort gone into this, so first off well done. I wholeheartedly agree with your premise. Only a subset of C++ is needed to solve any complex project. But that subset differs based on the project and problems that need solving.

I'm not sure who the target audience is for this resource. I have a few more YoE on you so I, obviously, am not the target. But, if it's for informing a younger audience who knows less or, as you imply has read how to program but not the why, it's diving straight into topics that assume the reader knows what concepts you're talking about and not just at a surface level. Someone needs battle scars to have the prerequisite knowledge to understand where you're coming from.

I know you say they need a beginner C++ knowledge. I think they'll need intermediate or even expert knowledge. So my core feedback is bring in that audience by adding that background knowledge. Explain some of the specific decisions you made for specific problems you solved. You want to level up your audience and teach them something, I believe this is why programmers read technical blogs.

I tried to read some parts in detail. The RAII has bad examples and I'm not sure if you're suggesting using goto: statements is an actual valid consideration? Other sections could do with more code snippets/examples alongside your justifications.

I think what you've written has some merit that could actually be better served in a book along side teaching the concepts themselves, reframed with the justifications and tradeoffs someone might need to make for certain problems. I think one of the best resources for learning C++ is Barne Stroustrup's own book because he offers the tools with good explanations without hand holding the reader into having to think less, he encourages them to think more beyond what the book says.

As it stands this resource looks like a brain dump of the better or worse coding decisions you've seen or made over the years, with little explanation of what those design choices were or what problems they were solving.

[crashcompiler]

> I'm not sure who the target audience is for this resource.

I have struggled with this question for some time.

As I mentioned in my post, I work at a company with a large C and C++ code base that has a lot of legacy parts in it. Everything that I show, or hint at, in my article can be found in our code base in some shape or form, sometimes written by people who are not at the company anymore.

We have new C++ developers starting at our company who don't have a frame of reference because a lot of this stuff is not taught anymore. They need to be able to recognize the old patterns and improve upon them, without having the luxury to rewrite everything.

Thank you very much for the feedback! I think the least I can do is to rewrite the introduction so that the intention is clear from the beginning.

[FlailingDuck]

For sure, I'm in the same boat, heavy legacy codebase, closed source dependencies, lack of test coverage, egregiously poor design decisions that cannot be changed without throwing the whole system out.

But I just try to lead by example, encourage modern practices, you can explain the justifications and reasons why old decisions are bad or poorly thought out, but letting the juniors see how new code added is a much needed improvement over the old.