3 ms·

If you named them like that, then sure that's less readable. But I feel there's a lot of straw man arguments in this thread; the main reason it's generally cons

If you named them like that, then sure that's less readable. But I feel there's a lot of straw man arguments in this thread; the main reason it's generally considered good practice to split up big functions is that humans aren't good at keeping a lot of context in their heads, so if you can provide a higher level abstraction then you can make it easier to follow. If we pick a more realistic RenderThePage() { FetchStateFromBackend() ProcessState() RenderTemplate() ReturnHTMLToUser() } I would find that a lot easier to follow than jamming all of that code into a single massive function that did all those different things. (Not to mention, I'd find it easier to test all those things in isolation, too). To take a completely contrarian position to that being put forth in this thread, I often find it clearer to pull a single hard-to-follow line of code into a function, just to encapsulate it behind a simpler named interface.

stiglitz 8y ago
Add a code comment to that single line of code.
majewsky 8y ago
Anecdata: Years ago, I refactored some code written by an inexperienced programmer. It was a multiple-thousand-line Perl CGI script where everything was on the top scope, i.e. there were not really any functions (except for a few one-liners). When this was called out by the lead architect, he improved the script by splitting everything into two functions: ($a, $b, $c, $d, ..., $x, $y, $z) = GetData(); PrintResult($a, $b, $c, $d, ..., $x, $y, $z); The variables actually had reasonable names, but there were at least 20 of them. He just splitted the code at some random point and all variables that needed to be used in the second half became return values and arguments, respectively.
- lmm 8y ago
  I'd argue that even that can be a small step in the right direction if there were more than 20 variables at the start - at least now you have an upper bound on how much state from the top half of the code can be being used in the bottom half of the code.
- dagw 8y ago
  He just splitted the code at some random point and all variables that needed to be used in the second half became return values and arguments, respectively. I've done basically the same. It's as good a place as any to start getting a handle on the problem, as long as you don't leave it there.
Firadeoclus 8y ago
It is precisely because humans aren't good at keeping a lot of context in their heads that it is a good idea to keep that context together on screen. In this example it is not clear whether the reader may need to see the content of multiple functions simultaneously to understand what's going on. Or it may depend on the circumstances whether they do. So if you have to make the choice between inlining or not there will always be pros and cons. An optimal solution gives you the best of both worlds: have an IDE that lets you inline-expand function calls (read-only), optionally replacing parameters with arguments, and simple commands to 1) actually inline the code to make locally unique changes, 2) edit the function in-place to make global changes.
- theptip 8y ago
  > In this example it is not clear whether the reader may need to see the content of multiple functions simultaneously to understand what's going on. My argument is that if you've named the functions correctly, and abstracted at the appropriate level, then you shouldn't need to know what's going on in each function to understand the top level. And, if you've separated your concerns well, then the implementation of one function should not depend on state in the other function. If on the other hand you have global state being manipulated in each of those functions, then sure, it's going to be confusing. Don't do that? Note that my position is actually closer to what Carmack is arguing for; > 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!). He's saying that pure functions are better than inlining, because they get the readability benefits of splitting your code up, while also avoiding the problems of mutating state that's shared between multiple peer functions.

stiglitz 8y ago

Add a code comment to that single line of code.

majewsky 8y ago

Anecdata: Years ago, I refactored some code written by an inexperienced programmer. It was a multiple-thousand-line Perl CGI script where everything was on the top scope, i.e. there were not really any functions (except for a few one-liners). When this was called out by the lead architect, he improved the script by splitting everything into two functions: ($a, $b, $c, $d, ..., $x, $y, $z) = GetData(); PrintResult($a, $b, $c, $d, ..., $x, $y, $z); The variables actually had reasonable names, but there were at least 20 of them. He just splitted the code at some random point and all variables that needed to be used in the second half became return values and arguments, respectively.

lmm 8y ago
I'd argue that even that can be a small step in the right direction if there were more than 20 variables at the start - at least now you have an upper bound on how much state from the top half of the code can be being used in the bottom half of the code.
dagw 8y ago
He just splitted the code at some random point and all variables that needed to be used in the second half became return values and arguments, respectively. I've done basically the same. It's as good a place as any to start getting a handle on the problem, as long as you don't leave it there.

Firadeoclus 8y ago

It is precisely because humans aren't good at keeping a lot of context in their heads that it is a good idea to keep that context together on screen. In this example it is not clear whether the reader may need to see the content of multiple functions simultaneously to understand what's going on. Or it may depend on the circumstances whether they do. So if you have to make the choice between inlining or not there will always be pros and cons. An optimal solution gives you the best of both worlds: have an IDE that lets you inline-expand function calls (read-only), optionally replacing parameters with arguments, and simple commands to 1) actually inline the code to make locally unique changes, 2) edit the function in-place to make global changes.

theptip 8y ago
> In this example it is not clear whether the reader may need to see the content of multiple functions simultaneously to understand what's going on. My argument is that if you've named the functions correctly, and abstracted at the appropriate level, then you shouldn't need to know what's going on in each function to understand the top level. And, if you've separated your concerns well, then the implementation of one function should not depend on state in the other function. If on the other hand you have global state being manipulated in each of those functions, then sure, it's going to be confusing. Don't do that? Note that my position is actually closer to what Carmack is arguing for; > 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!). He's saying that pure functions are better than inlining, because they get the readability benefits of splitting your code up, while also avoiding the problems of mutating state that's shared between multiple peer functions.