<story><title>“Clean Code, Horrible Performance” Discussion</title><url>https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md</url></story><parent_chain><item><author>nayuki</author><text>At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. &amp;quot;clean code&amp;quot;, is a valid goal.&lt;p&gt;I watched Casey&amp;#x27;s video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn&amp;#x27;t representative of every programming problem.&lt;p&gt;As an addendum to Casey&amp;#x27;s video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD&amp;#x2F;vectorization. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;AoS_and_SoA&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;AoS_and_SoA&lt;/a&gt;&lt;p&gt;For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth&amp;#x27;s advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.</text></item></parent_chain><comment><author>martinhath</author><text>&amp;gt; At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. &amp;quot;clean code&amp;quot;, is a valid goal.&lt;p&gt;Nobody is arguing against comprehensible code. Caseys video is not about clean code in general, but &amp;quot;Clean Code&amp;quot; as presented e.g. in the book by Robert Martin, which contains a bunch of code I would not classify as &amp;quot;clean&amp;quot; by any metric.&lt;p&gt;&amp;gt; But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic&lt;p&gt;He doesn&amp;#x27;t, though. The &amp;quot;Clean Code, Horrible Performance&amp;quot; video is an excerpt from his course called &amp;quot;Performance-Aware Programming&amp;quot;, where he explicitly says many times that the course isn&amp;#x27;t at all about &amp;quot;optimization&amp;quot;, but merely being &amp;quot;performance aware&amp;quot;. This isn&amp;#x27;t highlighted in the video though, so getting the full context is difficult.</text></comment>
<story><title>“Clean Code, Horrible Performance” Discussion</title><url>https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md</url></story><parent_chain><item><author>nayuki</author><text>At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. &amp;quot;clean code&amp;quot;, is a valid goal.&lt;p&gt;I watched Casey&amp;#x27;s video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn&amp;#x27;t representative of every programming problem.&lt;p&gt;As an addendum to Casey&amp;#x27;s video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD&amp;#x2F;vectorization. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;AoS_and_SoA&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;AoS_and_SoA&lt;/a&gt;&lt;p&gt;For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth&amp;#x27;s advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.</text></item></parent_chain><comment><author>thethirdone</author><text>I don&amp;#x27;t think Casey would object to &amp;quot;optimizing for human comprehension&amp;quot;. If you are willing to give up an order of magnitude of performance, you can probably just do it without much care.&lt;p&gt;I agree that &amp;quot;optimizing for human comprehension&amp;quot; is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don&amp;#x27;t think that guidelines like &amp;quot;clean code&amp;quot; actually are particularly effective at making understandable code. My personal guideline is to prefer code which is &amp;quot;simple&amp;quot; for both humans and computers.&lt;p&gt;&amp;gt; So by default, I follow Knuth&amp;#x27;s advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.&lt;p&gt;I hold the controversial opinion that Knuth&amp;#x27;s advice is not relevant to most modern programmers. Most modern programmers have never done the &amp;quot;optimization&amp;quot; that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won&amp;#x27;t be significant hotspots. Everything will be lukewarm.</text></comment>