5 ms·

Principle of Least Coding

51 points by rmord 15y ago

dchichkov 15y ago
Every line of the code is a constraint working against you.
- InclinedPlane 15y ago
  That's a very elegant way to put it.
- blazvi 15y ago
  nicely put
- sjmulder 15y ago
  /* I have only made this method longer because I have not had the time to make it shorter. */
- pohl 15y ago
  That is such a beautiful expression. It goes straight to my list of inspirational programming quotes. I hope you don't mind that I drop "the" from my version.
Craiggybear 15y ago
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.
- bahadden 15y ago
  A major difference between software and engineering (roads, bridges etc) is in the amount of redundancy. Bridges and such are usually made massively bigger and stronger than they need to be, just in case. Belt and braces. Of course, it's a lot cheaper to build that redundancy into a bridge than it is in software.
Akram 15y ago
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.
- einhverfr 15y ago
  Once you get the design down, I think this is a false dichotomy. Also I would suggest that if you focus on more generic flexible (what I call "superset") features, then long-run the codebase becomes a lot smaller. For example, when rewriting the the project accounting side for LedgerSMB, I generalized it out, and so the same logic could also handle funds accounting.
azov 15y ago
>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 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. The thing is - you want to minimize the amount of code you end up with, not the net amount of code you write along the way. PS. Two exceptions: a. your problem is trivial; b. you've solved a similar problem before.
- beobab 15y ago
  I sort of agree with you; Code to find the edges of the problem, design to work out what to do, and back to code to implement. Sometimes the only thing that saves my sanity is a nice process diagram in the design phase, which makes me realise that something important has been missed.
- bigiain 15y ago
  Advice from a long time ago that took me way longer than it should have to understand fully: "Always throw the first one away." I now consider the entire first prototype to be part of the "working out the design" process, and all the code written for that is considered disposable (quite often I write a prototype in a different language to the intended delivered product, partly to ensure I throw the first one away, but when I'm honest with myself - at least partly 'cause I enjoy rapid-prototyping in Perl.)
  - barefoot 15y ago
    An important corollary to that statement is: "And never show the prototype to non-developers".
    - debacle 15y ago
      This is probably my biggest fault. "So I whipped together a quick API integration yesterday evening..." "Oh, so you're almost done then!"
ericHosick 15y ago
> When one designs a solution well, the amount of code that one has to write becomes minimized. It can also be noted that a really well designed solution may require no lines of code at all. For example, engineering away parts of a process that are no longer required within an automated version of that process.
- einhverfr 15y ago
  Absolutely. One of the really gratifying things about hte newer architecture of LedgerSMB is: 1) How easy it is to write new code that works with the architecture, and 2) How little code you have to write to do something useful. I sometimes joke that our codebase is shrinking as our features increase, so we should have an infinite range of features about the time our codebase hits zero lines of code!
ericHosick 15y ago
> In general, when one works out the design well in advance before writing code. 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".
jimfl 15y ago
Rule of thumb: run test coverage. Consider deleting any code not covered before writing a test to cover it.
fauigerzigerk 15y ago
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. 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.
greenyoda 15y ago
Another, similar take on this idea is this article, written in 2007: Code is a Liability http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability http://blog.objectmentor.com/articles/2007/04/16/code-is-a-l... 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."

51 points by rmord 15y ago

dchichkov 15y ago

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

InclinedPlane 15y ago
That's a very elegant way to put it.
blazvi 15y ago
nicely put
sjmulder 15y ago
/* I have only made this method longer because I have not had the time to make it shorter. */
pohl 15y ago
That is such a beautiful expression. It goes straight to my list of inspirational programming quotes. I hope you don't mind that I drop "the" from my version.

Craiggybear 15y ago

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.

bahadden 15y ago
A major difference between software and engineering (roads, bridges etc) is in the amount of redundancy. Bridges and such are usually made massively bigger and stronger than they need to be, just in case. Belt and braces. Of course, it's a lot cheaper to build that redundancy into a bridge than it is in software.

Akram 15y ago

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.

einhverfr 15y ago
Once you get the design down, I think this is a false dichotomy. Also I would suggest that if you focus on more generic flexible (what I call "superset") features, then long-run the codebase becomes a lot smaller. For example, when rewriting the the project accounting side for LedgerSMB, I generalized it out, and so the same logic could also handle funds accounting.

azov 15y ago

>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 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. The thing is - you want to minimize the amount of code you end up with, not the net amount of code you write along the way. PS. Two exceptions: a. your problem is trivial; b. you've solved a similar problem before.

beobab 15y ago
I sort of agree with you; Code to find the edges of the problem, design to work out what to do, and back to code to implement. Sometimes the only thing that saves my sanity is a nice process diagram in the design phase, which makes me realise that something important has been missed.
bigiain 15y ago
Advice from a long time ago that took me way longer than it should have to understand fully: "Always throw the first one away." I now consider the entire first prototype to be part of the "working out the design" process, and all the code written for that is considered disposable (quite often I write a prototype in a different language to the intended delivered product, partly to ensure I throw the first one away, but when I'm honest with myself - at least partly 'cause I enjoy rapid-prototyping in Perl.)
- barefoot 15y ago
  An important corollary to that statement is: "And never show the prototype to non-developers".
  - debacle 15y ago
    This is probably my biggest fault. "So I whipped together a quick API integration yesterday evening..." "Oh, so you're almost done then!"

ericHosick 15y ago

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

einhverfr 15y ago
Absolutely. One of the really gratifying things about hte newer architecture of LedgerSMB is: 1) How easy it is to write new code that works with the architecture, and 2) How little code you have to write to do something useful. I sometimes joke that our codebase is shrinking as our features increase, so we should have an infinite range of features about the time our codebase hits zero lines of code!

ericHosick 15y ago

> In general, when one works out the design well in advance before writing code. 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".

jimfl 15y ago

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

fauigerzigerk 15y ago

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. 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.

greenyoda 15y ago

Another, similar take on this idea is this article, written in 2007: Code is a Liability http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability http://blog.objectmentor.com/articles/2007/04/16/code-is-a-l... 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."