<story><title>John Carmack on Inlined Code (2014)</title><url>http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html</url></story><parent_chain><item><author>dzdt</author><text>I have had the pleasure to work with lots of other people&amp;#x27;s code of varying styles and quality.  Nothing is harder to read and understand than code which is deeply nested calls from one little helper (or wrapper) function to another.  Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function.&lt;p&gt;There are other tradeoffs of code reuse and speed and worst-case-speed and probability of introducing bugs.  If you haven&amp;#x27;t read the article, do, its worth it.&lt;p&gt;I love that Carmack tries to measure which styles introduce more bugs!  Who else does that?  Seriously, I would love to see more of that.</text></item></parent_chain><comment><author>jameshart</author><text>I don&amp;#x27;t think I can agree with &amp;quot;Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function&amp;quot; in the general case.&lt;p&gt;I &lt;i&gt;will&lt;/i&gt; agree that if you are coding in the kind of environment Carmack is talking about, where you are writing code which interacts with massive shared global state, that purely procedural structured code is easiest to understand, because you can be sure that you can see all interactions with global data structures in one place.&lt;p&gt;But if you don&amp;#x27;t have massive shared global state, I&amp;#x27;d argue that calling subfunctions is a hugely valuable aid to understanding, since it allows you to reason much more about the way data dependencies flow through code when you can be sure that a call to a function means that that function can only act on the data structures passed in to it and is guaranteed not to affect anything else. I would much rather in that case see:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   a = subOperationA(arg)
   b = subOperationB(a)
   c = subOperationC(a, b)
   d = subOperationD(b, c)
   return d
&lt;/code&gt;&lt;/pre&gt;
than see those three suboperations inlined and have to figure out for myself how the data dependencies flow through the code.</text></comment>
<story><title>John Carmack on Inlined Code (2014)</title><url>http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html</url></story><parent_chain><item><author>dzdt</author><text>I have had the pleasure to work with lots of other people&amp;#x27;s code of varying styles and quality.  Nothing is harder to read and understand than code which is deeply nested calls from one little helper (or wrapper) function to another.  Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function.&lt;p&gt;There are other tradeoffs of code reuse and speed and worst-case-speed and probability of introducing bugs.  If you haven&amp;#x27;t read the article, do, its worth it.&lt;p&gt;I love that Carmack tries to measure which styles introduce more bugs!  Who else does that?  Seriously, I would love to see more of that.</text></item></parent_chain><comment><author>kminehart</author><text>Good Lord yes.  When I was working on point of sale machines for Toshiba, there was this unbelievable depth of inheritance and ridiculously deep callstack constantly, and it made fixing any minor bug take weeks.&lt;p&gt;* abstract class Connection would have maybe 3 or 4 methods;&lt;p&gt;* DataConnection would extend Connection and add a couple more methods that were specific to some proprietary protocol.&lt;p&gt;* POSDataConnection would extend DataConnection and wrap this proprietary protocol for POS machines&lt;p&gt;* ControllerDataConnection would extend POSDataConnection because a Point of Sale controller is technically a POS machine with a bit more functionality (Really just a couple flags turned on).&lt;p&gt;* There was plenty more in between; it&amp;#x27;s been so long now that I&amp;#x27;ve forgotten it all.&lt;p&gt;It&amp;#x27;s just like we all learned in college!  Object Oriented programming is supposed to model real-life!  Except no, it&amp;#x27;s not.  That&amp;#x27;s stupid and complicated.&lt;p&gt;Now the part of the OS that was C&amp;#x2F;C++ was absolutely beautiful.  It took the UNIX style of programming &amp;#x2F; applications seriously; every little piece was its own program, and it worked flawlessly.  Anyone could jump in and get to work immediately because it was so well written.  You could follow any program top to bottom and it just... made sense!</text></comment>