[thezipcreator]

seems pointless to extract `handle_suspend` here. There are very few reasons to extract code that isn't duplicated in more than one place; it's probably harder to read to extract the handling of the event than to handle it inline.

[skrtskrt]

I strongly prefer this sort of code:

```

    fn does_a_many_step_process():

         first_step_result_which_is_not_tied_to_details_internal_to_the_step_implementation = well_named_first_step_which_encapsulates_concerns();



        second_step_result_in_same_manner = well_named_second_step_which_encapsulates_concerns();

  ...etc

} ```

The logic of process flow is essentially one kind of information. All the implementation details are another. Step functions should not hide further important steps - they should only hide hairy implementation details that other steps don't need to know about.

[kstrauser]

One huge one is so that you can test it in isolation.

[scuff3d]

There's extraction for reuse and then theres extraction for readability/maintainability. The second largely comes down to personal taste. I personally tend to lose the signal in the noise, so it's easy for me to follow the logic if some of the larger bits are pushed into appropriately named functions. Goes to the whole self commenting code thing. I know there's a chunk of code behind that function call, I know it does some work based on its name and args, but I don't have to worry about it in the moment. There's a limit of course, moving a couple lines of code out without good cause is infuriating.

Other people prefer to have big blocks of code together in one place, and that's fine too. It just personally makes it harder for me to track stuff.

[thezipcreator]

fair enough, I suppose