> 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 "sparingly". 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'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.
"Recommendation 2: Include Only What You Need"<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't fully understand, yet. Unless you work for NASA, you won'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'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.
For many real world examples of minimalism and simplicity, see projects such as st or dwm from suckless. <a href="http://suckless.org/philosophy/" rel="nofollow">http://suckless.org/philosophy/</a>
Looking around int the web <a href="http://www.jbox.dk/" rel="nofollow">http://www.jbox.dk/</a> refered on this submission <a href="https://news.ycombinator.com/item?id=18829779" rel="nofollow">https://news.ycombinator.com/item?id=18829779</a> about Sanos operating system I found this pearl.
> 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 / 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.
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'm unfamiliar with the problems these slides address, so I can't grasp the insight in them.