Minimalism: Practical Guide to Writing Less Code (2002) [pdf]

&gt; Consider duplicate code to be a mistake<p>I partially disagree. Some of the worst code I’ve seen was an attempt to reduce duplication.<p>It’s easy, especially in UI code, to mistakenly identify duplicate code, and prematurely build a DRY “solution”. Premature DRY is the root of much evil.<p>I try to follow the rule of three before trying to identify duplication. Even then, I’ve become much more cautious than in my younger days.

I vehemently disagree with the idea that returning from a function often is bad and that it should be used &quot;sparingly&quot;. I find that code that returns as early as possible is the best. The idea of a nearly mandatory single return point is a very antiquated notion. I&#x27;m much more concerned when I see ten levels of indentation for no good reason.<p>Likewise with continue and break. I think this advice is very bad. All the other recommendations seemed fine.

&quot;Recommendation 2: Include Only What You Need&quot;<p>The slide refers to the inversion of control principle but can easily include other important aspects of including only what is needed.<p>I would like to expand on this for discussion. Consider the challenges of not over-engineering solutions to problems you and others don&#x27;t fully understand, yet. Unless you work for NASA, you won&#x27;t fully know what you need until you need it.<p>How do programmers here account for the unexpected?

Main rule for writing less code: only write the code you need to solve the actual problem you have.<p>It is fine to write towards future problems, but all to often trying to be generic explodes the codebase and leads to bugs.

Without understanding why these rules get broken, it&#x27;s hard to avoid breaking them.<p>There is a tension between dependency and redundancy. Avoiding redundancy often introduces dependency as code becomes shared for several purposes. Knowing which is preferable (dependency or redundancy) in a given case requires a lot of judgement and changes as the code evolves.<p>Redundancy is bad when it introduces too much code and too many chances for error or unnecessary divergence of implementation.<p>Dependency is bad when two things that start out closely related diverge in purpose, straining an implementation to handle both cases.

(2002)<p>Also, previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5024221" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5024221</a>

For many real world examples of minimalism and simplicity, see projects such as st or dwm from suckless. <a href="http:&#x2F;&#x2F;suckless.org&#x2F;philosophy&#x2F;" rel="nofollow">http:&#x2F;&#x2F;suckless.org&#x2F;philosophy&#x2F;</a>

Looking around int the web <a href="http:&#x2F;&#x2F;www.jbox.dk&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.jbox.dk&#x2F;</a> refered on this submission <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18829779" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18829779</a> about Sanos operating system I found this pearl.

&gt; Prefer code to comments<p>I used to make this same argument, and then took it overboard by never commenting. After reading some literate codebases, I’ve changed my mind.<p>Code is (almost?) always obvious to you as you are writing it. So, you never recognize code that is in need of a comment until you come back to it and struggle to understand its purpose and the context that gave it birth.<p>I now follow a rule: a meaningful comment at the top of each file. A comment on every exported function &#x2F; value. Often, in the process of writing the comment, I realize I’ve poorly named something or that I’ve failed to handle some case. Comments help guide the reader, but also the writer.

I struggle to understand this; I guess the speaker added a lot of information verbally.

Is there some version of this pdf with code examples ?

Could someone explain these recommendations more in-depth?<p>(5) Manage Resources Symmetrically (10) Let the Code Make the Decisions<p>What does it look like when you do the opposite of these rules?<p>I think I&#x27;m unfamiliar with the problems these slides address, so I can&#x27;t grasp the insight in them.