Principle of Least Coding

&#62;<i>So how can we go about writing code that is least coding? In general, when one works out the design (as has been apparent many times from personal and anecdotal experiences) well in advance before writing code</i><p>Can't agree with this advice. Figuring out the design before writing code is not going to work because you simply don't understand the problem well enough before you try to implement the solution. It is that first prototype that helps you gain knowledge, discover practical use cases, prioretize features, etc. The design that you "figure out" without writing any code will most likely be inadequate.<p>The thing is - you want to minimize the amount of code you end up with, <i>not</i> the net amount of code you write along the way.<p>PS. Two exceptions: a. your problem is trivial; b. you've solved a similar problem before.

<i>&#62; When one designs a solution well, the amount of code that one has to write becomes minimized.</i><p>It can also be noted that a really well designed solution may require no lines of code at all.<p>For example, engineering away parts of a process that are no longer required within an automated version of that process.

Every line of the code is a constraint working against you.

The main reason why I don't find this principle as useful as it appears at first sight is the phenomenon of obfuscation by abstraction.<p>You can cut down on LOC and even make the code appear more elegant by making it very abstract. Is this better than writing more lines of code that express the intention more directly? I don't have a general answer to that and I don't think there is one. Nothing will ever free us from the burden to find the right balance.

Another, similar take on this idea is this article, written in 2007:<p>Code is a Liability<p><a href="http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability" rel="nofollow">http://blog.objectmentor.com/articles/2007/04/16/code-is-a-l...</a><p>Excerpt: "Code size reduction is a very good thing. I want the simplest, the smallest, the least code possible, with the least risk of breaking something else in the system. I don’t want big functions that touch everything in sight. I don’t want long complicated blocks of if/else statements. I don’t want monster functions which conglomerate dozens of operations in a single, fat interface. Shallow is good. Short is good. Less code is good. More code is a liability. This isn’t about typing less, it’s about owning less."

Writing less and elegant code take more time... I used to spend more time in perfecting my logic in as less code as possible.. But if the code is for an MVP then it should be quick and dirty.

<i>&#62; In general, when one works out the design well in advance before writing code.</i><p>One tool available is Behavior/Feature Driven Development which forces you to work out the design well in advance and then implement only the code that makes that design "pass".

Rule of thumb: run test coverage. Consider deleting any code not covered before writing a test to cover it.

Definitely a case of Less Is More. A program should be no bigger than it needs to be. First rule of engineering anything - bridges, dams, roads, software.