&gt;&gt; <i>While I don&#x27;t 100% agree with how Casey codes I wouldn&#x27;t get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90&#x27;s with a software renderer) and decided to use the common parts of C and C++ for the actual implementation.</i><p>Well, I would ;-). I think the quality of the code he writes for the game scores low on almost any objective measure of quality except pragmatism.<p>&gt;&gt; <i>You made me curious, what do you consider a good programming style for game programming ?</i><p>I don&#x27;t think there is a single &#x27;good programming style&#x27; for games, it all depends on the game, the development environment (language, tools) the third-party components you use, the target platform, etc. I think there&#x27;s a lot of best practices you could apply to any game though. Applying abstraction in those parts where it matters and doesn&#x27;t negatively impact performance, for example. Defining the components of your game and keeping clear boundaries between them. Making good use of the language features at your disposal. Not obsessing over constant factor performance &#x27;optimisations&#x27; before you know where the bottlenecks are. Thinking about and preferring efficient algorithms and data structures, over quick &amp; dirty &#x27;handmade&#x27; data structures, just because you feel STL or boost are &#x27;not efficient&#x27; (it doesn&#x27;t matter for 99% of your game code, especially not for something simple as HH). Not passing around naked pointers everywhere.  I could go on for a while...<p>If you watch Casey work on HH, most of the time he&#x27;s fiddling with and rewriting the same things over and over again, because he feels that he always needs to program everything &#x27;in the simplest possible way&#x27; first, and then rewrite when necessary. I don&#x27;t disagree with throwaway code at all, and not everything always needs to be &#x27;designed upfront&#x27;, but he&#x27;s taking these things to the extreme, which results in an entangled mess of spaghetti code full of bugs (which you&#x27;ll have seen he runs into in almost every episode of his stream). He basically disregards all the advances we&#x27;ve had in programming since the 90&#x27;s, and keeps hammering in C-style code that happens to be compiled by a C++ compiler, but doesn&#x27;t use any of the advantages C++ provides.<p>I still like to watch him do it though because there&#x27;s definitely educational value to his videos, and he does solve some interesting problems along the way. And because I&#x27;ve been working on a simple game myself for a while. In my earlier comment I refrained from plugging my own little side-project but now you&#x27;ve asked you could take a look here [1] if you wanted to see how I like to program games. It&#x27;s about an equal amount of hours in as HH but it already has some actual gameplay, is fully scriptable using Lua, Box2D physics, a sprite-based OpenGL rendering backend, persistency (freeze&#x2F;unfreeze), action replays with live code updates (inspired by HH, but done &#x27;the right way&#x27;), texture-mapped truetype font rendering, some interesting &#x27;handmade&#x27; algorithms (complex polygon triangulation, sprite packing), motion controls, etc. I realise it&#x27;s not the same thing as HH as I prefer not to re-invent the wheel for everything and use libraries and frameworks, but I still feel it&#x27;s much closer to how you would program a &#x27;real&#x27; game using modern technologies.<p>[1] <a href="http:&#x2F;&#x2F;www.wouterbijlsma.nl&#x2F;blog&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.wouterbijlsma.nl&#x2F;blog&#x2F;</a>