3 ms·
I agree that dividing the largerFunction into smaller ones has a non-negligible cost, and that cost is never mentioned at school. However, I still think that th
by otikik 12y ago
I agree that dividing the largerFunction into smaller ones has a non-negligible cost, and that cost is never mentioned at school. However, I still think that the benefits provided by moving them out outweigh it.
One think that I found beneficial is that by dividing the big functions into smaller ones, the resulting functions have the same abstraction level. To give an exaggerated example: I try to split my functions so that I never deal with Countries, Provinces, Cities, Buildings, People, Body Members, Organs & Cells in the same scope. I try to only deal with one of them per function (sometimes two, in parent-child cases).
I find that 1-abstraction-level functions are easier to understand, and I gladly "pay the price" of having extra one-use names around for this reason. I do try to restrict the scope of those "extra functions" as much as I can, put related functions together, and reduce side-effects as much as I humanly can.
- eru 12y agoWhat non-negligible costs are you talking about?
- otikik 12y agoThe ones Karmack talks about. Several "concepts"(functions in this case) with implicit relationships (like what calls what, and in what order) are (sometimes) more difficult to absorve than a huge block of sequential code.
- otikik 12y agoThe ones Karmack talks about. Several "concepts"(functions in this case) with implicit relationships (like what calls what, and in what order) are (sometimes) more difficult to process for a human brain than a huge block of sequential code.
- eru 12y agoOh, ok. Thanks. I guess that's why we try to avoid unnecessary naming in Haskell, and if we can, just chain our functions like eg bigFunction = someFunction callBack . otherFunction arg1 callBack2