[typon]

I wish this kind of thinking would die. 9 times out of 10 when I'm working on a large code base at (any company I've worked at so far), the main problem I have is with disorganized, messy code with poor abstractions, state everywhere, functions that are too long, functions that are too short, references to objects everywhere with no regard for lifetime and the list goes on and on. The times I have been stumped with clever syntax are few and far between. Almost never have I said "oh man I wish they didn't use a std algorithm/container here, makes the code more obfuscated!".

Yes I have seen cases where classes or functions are unnecessarily generic, adding templates when you only needed to support a specific type (YAGNI).

But in the end, most bad code I look at, I completely understand it's syntax. It's the semantics of this so called "dumb" code that prevent me from modifying it or fixing a bug in it for days until I actually understand the rats nest of ideas expressed in the code.

I think using features like using const as much as possible, preferring return by tuple rather than multiple in out parameters and a bunch of other modern C++ features more often than not make code bases simpler than the other way around.

[PezzaDev]

You made me realise that term "dumb code" isn't exactly what I mean. I want to advocate writing code that is very easy to statically understand. You should be able to look a piece of code without needing to read too much around it to understand what it is doing. One of the best ways of doing this in my experience is keeping things simple (or "dumb" as I put it earlier). Using simple abstractions, keeping code organised and avoiding global state also help in this regard.

[neutronicus]

It's the endless copying-and-pasting that gets you.

Fix a bug somewhere ... pray to the Nasal Demons you got there before more than two developers duplicated it elsewhere.