It's worth adding something in particular to this, because I think it applies generally and, in this case, is basically a giant spike through the middle of the conversation.
As some general rules that can make questions like this easier:
If you have a block of code repeated once, it may be a candidate for a function for code clarity, especially if long, but moving it will give you no net gain save for easier maintenance. It is good to have many short functions (20 lines tops, 50 for rare exceptional bits) rather than few long ones.
if a block of code is repeated twice or more, it almost certainly should be in a function. If the block of code is repeated twice exactly, is more than 2 or 3 lines, and performs some specific namable functionality, think hard before deciding not to give it a function. Knowing when this is a good idea comes with practice, but I think a good rule of thumb is to ask yourself if you can put a comment before such blocks that says something like "computes the maximum of two integers", or similar. You are likely to want to use such blocks for a third time later, or possibly even in a completely different project.
If the block is repeated three or more times,, think very very hard before not putting it in a function. If the block is repeated four or more times or is repeated across multiple files, may the gods of programming smite you for your blasphemy.
To make these rules go even further, note that global state is bad. Putting your global state inside a class is one of those brilliant ideas that costs almost nothing, and you can still create the class globally and use it globally if needed. If you make sure all the related functionality is in the same file with the class, you can move it between projects instantaneously. This isn't really object oriented programming; it's exploiting what I think of as the "alternate universe" feature of classes, and it's saved me so many times. I'm not sure why so many people go into abstract perfection theory land when talking about classes, because this is one of those super obvious things that has an immediate and demonstrable benefit (OO is demonstrable, but not immediate). Yet no one talks about it first.
And finally, for the most bang for your buck, most programmers have trouble with more than 3 levels of nesting (that is, open braces), and it's not linear. Four might be okay for good programmers, five is going to require you to bend your brain when you look at it next week no matter who you are, 6 necessitates very, very explanatory comments, and I have never seen 7 anywhere ever. This is mostly related to my first point--if you can break the function up into 3 smaller ones, it can cut down on this nesting, giving you easier to manipulate blocks. You then replace the 50 lines of code in the original function with the 3 function calls, and everyone is much happier. It's debatable whether you count the function's left brace in this, and you'll eventually not need the rule, but it can certainly help manage things at first. Yes, this can be taken too far, but trust me, you'll know.
Since this particular conversation was the perfect place to put this and the solution I proposed falls directly out of the above, I figured I'd give the reasoning process that leads to it. Unlike much of programming, this is something that doesn't require huge amounts of experience to follow or understand. I don't have to say "trust me, you'll get it once you've done it wrong", and that's really nice for a change. If you follow this and find yourself deleting code or writing less than usual, you are doing it right. Good programmers can and do add features by decreasing line counts.
My BlogTwitter: @ajhicks1992