I don't agree with "if you have a block of code, consider making it a separate method". I've seen it done and done it myself in the past, and it ended up being a whole lot of methods used only once and described well (by name). However it added unnecessary complexity which added to the cost of ownership of the classes. I hope someone can relate.
I can relate - it can also be a way where you can introduce meaning to your code. As opposed to a a series of instructions without clear intention, you can put them in a function that has a name that signals your intention. So you are labelling what that code does, using language features. I'm sure there are plenty of examples of this done well and done badly.
Not only meaning, but also separation. Two chunks of code after each other in a method can communicate via all kinds of mechanisms, e.g. having the same variable in scope. As a reader you will have to check for these communications to understand the method, even if those two blocks of code do not in fact communicate.
If you separate the block out into their own methods, they reader will have a much easier time verifying that they are decoupled.
Originally it was ""if you have block of code in more than two places", tinco removed that from their reply.
I believe that inclusion solves the issue you've described. Obviously you don't need every 5 lines of code encapsulated into a method, but preventing code duplication should be paramount.
While it's not necessary to pull every block of code out into it's own function, its something a developer should keep in mind when writing code.
A lot of people seem to thing that code duplication is the only reason to refactor code out into it's own function. While that's certainly a good reason, there are many others. For me, being able to test the code easily is a major one. The smaller the function (specifically the less branching and the less it does), the easier it is to test.
