Hi Jacob! Thanks for your proposal!

I think that both the previous language, and your proposed change, speak too strongly toward moving code to a new method, when the text of course can have no idea how appropriate it would be to move code to a new method for a particular case. ("should probably")

To further explain my position, I am often against moving code to a method just because it has a functionality that one _could_ separate into a new method. 

If it can be used by several actors and removes redundancy, I'm all for it, but taking a 50 line method and dividing it into 5 methods for no other reason than to separate the functionality performed does nothing but make more methods to have to know about, and more levels in the debugging stack to have to click through to see things.

So my proposed language would be something like "Whitespace within methods should separate functionality, but of course be aware of appropriate opportunities to split functionality into new methods."

This would give it a more neutral position. I wonder what the rest of the team thinks!