3 ms·

An aweful pedantic tome for a problem of one's own making. Compose and you won't have any readability problems. People write a method/function and then don't b

An aweful pedantic tome for a problem of one's own making. Compose and you won't have any readability problems. People write a method/function and then don't bother to pull out blocks of specific functionality that can be contained within other "helper" methods. Your 100+ line method can always be refactored to a 20 line method that calls the other smaller methods needed to compose its total functionality. Not only can I now read it, I can understand it. Giant blocks of code manufacture bugs.

m33k44 6y ago
The rule of thumb of 80 chars, which was(sometimes still is) applied for width, also applies for height: a function should not be more than 24 lines :) If it is greater than that then it needs to be refactored. Helps in readability as one does not have to scroll to read the entire function. Of course these rules came into being when terminals were 80wx24h. This was a guideline for Linux kernel developers for many years.
- tasty_freeze 6y ago
  I think strict adherence to such rules is silly. Some 20 lines functions are massively more complex than some 120 line functions. If the computation is simple and linear, then long functions are fine. If there are nested loops and if statements and other forms of flow control and deep nesting, then long functions are painful.
cloogshicer 6y ago
I respectfully disagree. If those functions are only used in this one place, I'd much prefer to have the code in one large block. John Carmack makes a good argument for why: https://news.ycombinator.com/item?id=25263488 https://news.ycombinator.com/item?id=25263488
spaetzleesser 6y ago
I have worked on code bases where they followed the 20 line per method rule religiously. It resulted often in artificially broken up functions that were way harder to read than one big function. I would call it "small function spaghetti code".
- datavirtue 6y ago
  So don't artificially break them up?
coldtea 6y ago
It can be the exact opposite too (which is why a shorter as opposed to longer function is a tradeoff that should be questioned each time, as opposed as a clear winner). A 250-line function might better encapsulate the required logic to understand a piece of code. 1 function composed of 10 20-line functions might requiring hunting around to get the point and understand the big picture, with everything always happening "somewhere else".
- datavirtue 6y ago
  Nope. All the methods should clearly name the functionality. No guess work. It reads like prose.
yowlingcat 6y ago
Refactoring a larger function into a group of small ones doesn't come for free. Even though it might often be a good idea, when it's not done with care it can confuse, not clarify. It comes down to a matter of judgment of the whole and deliberate expression. That's contextual, not absolute. With that said, I somewhat agree with the spirit of what you are saying. I tend to lean in the direction of smaller methods when possible because they often make things more readable and more explicit.
- datavirtue 6y ago
  If it isn't clear it's not easy to change, making it "bad code." Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
  - yowlingcat 6y ago
    As much as I like this idea in theory, in practice, a lot of the hairiness and opacity of code I've seen comes from the business domain itself, not the code. There is only so pretty you can make code which has to do painful and unintuitive tax calculation, or credit underwriting logic. But often times, this code is the most critical to the business as a whole. It is code which is counterintuitive because it reflects a reality which is itself painful and unintuitive. When it comes to writing clear code in reality, I'll repeat what I said before -- there aren't absolute rules, and things are contextual. Where it's possible, it's absolutely ideal to keep things compact and expressive. But that only will take you so far. When you run into domain logic that is to an extent incompressible, trying to compress things further will only impede clarity.

m33k44 6y ago

The rule of thumb of 80 chars, which was(sometimes still is) applied for width, also applies for height: a function should not be more than 24 lines :) If it is greater than that then it needs to be refactored. Helps in readability as one does not have to scroll to read the entire function. Of course these rules came into being when terminals were 80wx24h. This was a guideline for Linux kernel developers for many years.

tasty_freeze 6y ago
I think strict adherence to such rules is silly. Some 20 lines functions are massively more complex than some 120 line functions. If the computation is simple and linear, then long functions are fine. If there are nested loops and if statements and other forms of flow control and deep nesting, then long functions are painful.

cloogshicer 6y ago

I respectfully disagree. If those functions are only used in this one place, I'd much prefer to have the code in one large block. John Carmack makes a good argument for why: https://news.ycombinator.com/item?id=25263488 https://news.ycombinator.com/item?id=25263488

spaetzleesser 6y ago

I have worked on code bases where they followed the 20 line per method rule religiously. It resulted often in artificially broken up functions that were way harder to read than one big function. I would call it "small function spaghetti code".

datavirtue 6y ago
So don't artificially break them up?

coldtea 6y ago

It can be the exact opposite too (which is why a shorter as opposed to longer function is a tradeoff that should be questioned each time, as opposed as a clear winner). A 250-line function might better encapsulate the required logic to understand a piece of code. 1 function composed of 10 20-line functions might requiring hunting around to get the point and understand the big picture, with everything always happening "somewhere else".

datavirtue 6y ago
Nope. All the methods should clearly name the functionality. No guess work. It reads like prose.

yowlingcat 6y ago

Refactoring a larger function into a group of small ones doesn't come for free. Even though it might often be a good idea, when it's not done with care it can confuse, not clarify. It comes down to a matter of judgment of the whole and deliberate expression. That's contextual, not absolute. With that said, I somewhat agree with the spirit of what you are saying. I tend to lean in the direction of smaller methods when possible because they often make things more readable and more explicit.

datavirtue 6y ago
If it isn't clear it's not easy to change, making it "bad code." Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
- yowlingcat 6y ago
  As much as I like this idea in theory, in practice, a lot of the hairiness and opacity of code I've seen comes from the business domain itself, not the code. There is only so pretty you can make code which has to do painful and unintuitive tax calculation, or credit underwriting logic. But often times, this code is the most critical to the business as a whole. It is code which is counterintuitive because it reflects a reality which is itself painful and unintuitive. When it comes to writing clear code in reality, I'll repeat what I said before -- there aren't absolute rules, and things are contextual. Where it's possible, it's absolutely ideal to keep things compact and expressive. But that only will take you so far. When you run into domain logic that is to an extent incompressible, trying to compress things further will only impede clarity.