Writing methods inside methods for readability. Good or bad?

Question

I personally like to break long methods into smaller steps, for example:

Load()
{
LoadStep1()
LoadStep2()
LoadStep3()
LoadStep4()
...
}

is this overkill? Someone else complained that there is too much jumping around to find the actual logic. I personally like it because I can see the intention of the programmer much easier.

What is the right balance, and how many levels of nested methods is recommended before it defeats the object of clarity?

I like to write methods like this as it is a good 'Separation of concerns'. In your case, I imagine the code calling Load() does not care how Load() loads, just that it loads whatever it is supposed to. Also if LoadStep3() needs changing, if it was not separated into its own method then you could possibly be left having to rearrange logic that actually has nothing to do with LoadStep3(). — Jammerz858, Jan 16 '13 at 14:49

score 1 · Answer 1 · answered Jan 16 '13 at 15:00

As no one else has left a more substantial answer I'll just refer to my comment on your question and provide this link (which is a decent read) http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-vs-single-responsibility-principle-soc-vs-srp.aspx

Writing methods inside methods for readability. Good or bad?

1 Answers1