A little (fairly random) list of coding habit changes I tried in my weekend projects (mainly Oryol) over the past few years and how they worked out, in no particular order. This is all strictly IMHO, don’t take this as ghospel / the-one-and-only-truth ;)
no setters/getters: I was used to make class members private and write public or protected setter/getter methods. One day I removed all setters/getters from Oryol to see ‘how it feels’, and it just felt right (still does). Class declarations in headers are much easier to grok, and code is more readable. Const-correctness still works, the only thing you lose is the ability to set a breakpoint into the setter/getter methods, but I can count on one (maybe two) hands when I ever needed that.
no more ‘big ideas’: I stopped long ago believing in ‘big architecture ideas’ that dominate an entire project (Oryol is one result of this, although the ‘old way’ is still visible in places like the Messaging module). Stuff like ‘everything is an object’, ‘everything communicates by message passing’, ‘all objects have names’, ‘all objects live in a big tree’, everything this, everything that… ESPECIALLY if these big ideas are cast into centralized code. At one point you inevitably start working around the big idea because new things just don’t quite fit in anymore. It is better for a project to have many ‘small, local ideas’ and very little shared code. Big ideas can still have their place, but only isolated in small leaf-modules where they cannot infect an entire project.
no inheritance: I hardly use class inheritance anymore, this is more an unintended side effect of other habit changes (mostly because I stopped caring about ‘designing for code-reuse and extensibility’, both are well-intended, but dangerous lies).
no pointers: This was not really intended but happened as an automatic side-effect of keeping objects in fixed-size arrays. There are hardly any pointers (of the raw or smart flavour) in Oryol, there are also hardly any calls to new/delete/make_shared/whatever. Instead an ‘object handle’ is usually a simple array index, sometimes with an unique value as ‘dangling reference protection’, or it can be any other type of ‘id’ that can be mapped to one (or more!) memory locations.
no tiny heap objects, no pointer-chasing: …another side-effect of grouping (and processing) objects in flat arrays. There’s a lot of C++ code out there which creates thousands of tiny objects on the heap, held together by smart pointers and long chains of pointer-chasing call like get_this_obj()->get_that_obj()->do_this(). This is the typical ‘death-by-a-thousand-cuts’ code which is slow without any obvious hotspots and thus nearly impossible to optimize.
this->: I’m still a fan of using ‘this’ for member access inside class methods, otherwise I find it hard to differentiate between local variables and member variables (and don’t get me started on the m_ notation)
const correctness: I still think const-correctness is a very useful concept, even though I have to admit that I can’t think of a case ‘where it actually prevented a bug’ (may be that’s exactly the point of using const, I don’t know). I even started to use const for local variables that should not be mutable, but I think that might go a bit too far, especially since I’m not always consistent with this. I would actually love if everything in C++ was const by default and would have to be explicetly marked as mutable, will never happen of course.
Only one thing comes to mind, probably because I forgot about stuff that obviously didn’t work pretty fast: