A Philosophy of Software Design
I can&#x27;t at all agree with the added differences of opinion with Uncle Bob&#x27;s Clean Code. The author argues a reducing the size of a function of &quot;a few dozen lines&quot; likely won&#x27;t improve the readability of the code. That&#x27;s not even defensible! I would fail any (professional) code review for having that many lines of code in a function. It&#x27;s a complete failure of abstraction. He later goes on to say &quot;more functions means more interfaces to document and learn.&quot; This is also smelly. Clean code is self documenting. It should be simple to read because it should read like prose. If levels of abstraction are kept to one per function, it&#x27;s easy to understand what is happening. One would only drill down into functions if it were necessary to grok implementation details of an abstract function.<p>The comment on comments I also disagree with, although that&#x27;s more contentions. In general I agree with Uncle Bob that comments are usually apologies. Most of the time the code should be refactored to not need comments. Ousterhout does bring up a point that names can sometimes be verbose as a result, but I can&#x27;t be convinced that&#x27;s a universal evil in the same way I can&#x27;t be convinced that comments are a universal evil.<p>&gt;And, with this approach, developers end up effectively retyping the documentation for a method every time they invoke it!<p>In what way is that a negative? This is a feature of self documenting code! This is what makes good code so great! This seems like some degree of misunderstanding of Clean Code.<p>I&#x27;m compelled to pick up this book, however.