

Functions Should Be Short And Sweet, But Why? - koblenski
http://sam-koblenski.blogspot.com/2014/01/functions-should-be-short-and-sweet-but.html

======
izietto
"Easier to read" is the biggest advantage IMHO; I don't find that they are
"easier to write": for me it's more immediate to write code in a big dirty
main, than in small and self-documenting functions. But there is no choice:
you _must_ refactor your code if you want to understand something later

------
nikanj
I must point out that not all software is CRUD boilerplate that can be nicely
condensed to small chunks. Arbitrarily splitting a complicated algorithm
implementation, just to make a every piece less than N lines seems like some
weird variation of cargo cult programming.

~~~
dasil003
I thought the same thing as well. For every best practice there is a counter-
example. In the case of a simple procedural task that doesn't have any
independently executable pieces, the value of splitting it up into sub-methods
is debatable. All else being equal, it sometimes comes down to whether the
sub-tasks have an intuitive mapping to English, if they don't map well to
English or there are cross-cutting concerns or ambiguities underlying the
names of the methods then I'd say it's a net loss to readability and better to
just have one big hairy method.

