4 ms·

Lost me here: "Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of do

Lost me here: "Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC). We should distrust every line of code written by ourselves as well as those written by others. The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs." Less code does not necessarily mean less bugs.

taneq 10y ago
That depends on how you measure code. If you're talking lines or statements, sure, but if you're talking concepts then the code with fewer concepts expressed must necessarily have less opportunity for bugs, if the number of bugs per concept is held constant.
- rnernento 10y ago
  " The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs." I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
  - dalacv 10y ago
    "the only winning move is not to play"?
SeanDav 10y ago
Less code does absolutely mean less bugs, in the majority of cases. Of course it is not an absolute rule and can be gamed, but simple logic dictates that since it is not possible to always write 100% bug free code, the more code one writes, the more chance there is to introduce bugs. However I don't believe the statement was meant to be taken entirely literally.
- rnernento 10y ago
  Then why do I spend so much time fixing bugs in code where the concept was complicated to the nth degree so it could be written in five lines instead of ten? I agree that fewer lines of code is better, unfortunately if you hold that concept in too high a regard it's easy to make a mess. Some programming challenges are complex and the complexity can't be avoided. Sometimes solving that problem in fewer lines of code makes the problem even more complex. Just because the complexity is moving from the code itself into the developers head doesn't NECESSARILY mean that it will be less prone to bugs.
  - mordocai 10y ago
    Those 5 lines probably had 100s if not thousands of lines backing them. Maybe best to say 'fewer lines of code executed' as it doesn't really matter whether those lines are in a library or in your project, they still have a chance for bugs.
    - rnernento 10y ago
      You're missing the point, it's not about executed code it's about concepts and simplicity. Sometimes people work too hard to make two functions with slightly different objectives into a single complicated function. This can save lines of code since you aren't writing two similar functions. In general this is good practice but it's VERY common to take this too far, and it's very likely that the resulting complicated function will be MORE prone to bugs than the two simpler functions would have been.
st3v3r 10y ago
Less code does mean less possibility of bugs.
liw 10y ago
The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run. There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.

taneq 10y ago

That depends on how you measure code. If you're talking lines or statements, sure, but if you're talking concepts then the code with fewer concepts expressed must necessarily have less opportunity for bugs, if the number of bugs per concept is held constant.

rnernento 10y ago
" The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs." I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
- dalacv 10y ago
  "the only winning move is not to play"?

SeanDav 10y ago

Less code does absolutely mean less bugs, in the majority of cases. Of course it is not an absolute rule and can be gamed, but simple logic dictates that since it is not possible to always write 100% bug free code, the more code one writes, the more chance there is to introduce bugs. However I don't believe the statement was meant to be taken entirely literally.

rnernento 10y ago
Then why do I spend so much time fixing bugs in code where the concept was complicated to the nth degree so it could be written in five lines instead of ten? I agree that fewer lines of code is better, unfortunately if you hold that concept in too high a regard it's easy to make a mess. Some programming challenges are complex and the complexity can't be avoided. Sometimes solving that problem in fewer lines of code makes the problem even more complex. Just because the complexity is moving from the code itself into the developers head doesn't NECESSARILY mean that it will be less prone to bugs.
- mordocai 10y ago
  Those 5 lines probably had 100s if not thousands of lines backing them. Maybe best to say 'fewer lines of code executed' as it doesn't really matter whether those lines are in a library or in your project, they still have a chance for bugs.
  - rnernento 10y ago
    You're missing the point, it's not about executed code it's about concepts and simplicity. Sometimes people work too hard to make two functions with slightly different objectives into a single complicated function. This can save lines of code since you aren't writing two similar functions. In general this is good practice but it's VERY common to take this too far, and it's very likely that the resulting complicated function will be MORE prone to bugs than the two simpler functions would have been.

st3v3r 10y ago

Less code does mean less possibility of bugs.

liw 10y ago

The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run. There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.