Hello everyone
Casey's compression oriented programming advices that code that is written multiple times should be reformatted into a function, but sometimes i get functions that are too big for me to look at, without having the privilege of obviously rewritten code.
My criterion for too big of a function is one that i can't reason with myself exactly what it does without looking at it, or that it has a lot of parts that all of them is related to one aspect of my software, and none of them seems to obviously not connected to the others enough to take them out to a different function.
What can you do in this situation? Should you just break them out? what if there's a better way of organizing that code that can only be viewed if looke together?
Casey's compression oriented programming advices that code that is written multiple times should be reformatted into a function, but sometimes i get functions that are too big for me to look at, without having the privilege of obviously rewritten code.
My criterion for too big of a function is one that i can't reason with myself exactly what it does without looking at it, or that it has a lot of parts that all of them is related to one aspect of my software, and none of them seems to obviously not connected to the others enough to take them out to a different function.
What can you do in this situation? Should you just break them out? what if there's a better way of organizing that code that can only be viewed if looke together?
There probably aren't any easy answers with this, but my preference lately has been to leave them in, and possibly if it's giving you a bad feeling then it might be a sign of an architectural issue rather than one of just where the code lives (and so maybe something to keep in mind as you continue rather than rectify immediately)
Here's John Carmack on the opposite problem--going from 'too factored' code to inlined code:
http://number-none.com/blow/blog/...9/26/carmack-on-inlined-code.html
The retrospective bit at the top is probably the most relevant, too (emphasis added)
Here's John Carmack on the opposite problem--going from 'too factored' code to inlined code:
http://number-none.com/blow/blog/...9/26/carmack-on-inlined-code.html
The retrospective bit at the top is probably the most relevant, too (emphasis added)
The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).
Those are not ideological, those are problems of not being able to edit the function in a fast way because it is so long and has so many parts.