[rza]

> "...immediately realize that which will make it more difficult to modify these functions". Please clarify what you mean here.

I absolutely would prefer a method to look like:

def main():

  SetUp()

  try:

    DoStuff()

  except:

    HandleErrors()

then a thousand-line god function. It encourages modularity, reduced state and scope (please ignore my example above which implies a lot of shared state:)), and every method should be well-named and do a single thing well. Maybe for super-sensitive realtime systems, this might cause a few necessary checks that we could ignore, but we are talking about readability here.

Having to navigate between different methods is honestly a really lame excuse for sticking everything in one method. That's what IDE's, documentation, and good method names are for.

[taeric]

Seeing this makes me realize the beauty of CWEB. It lets you break up a piece of the code this way, but when it presents the code that is in "DoStuff" it explicitly tells you where else it is used.

That is, the concern with having a DoStuff method is that if it gains a new caller, it may have just gained new requirements. This will eventually pose a problem, especially when it is believed that one can edit functions in isolation to all of the expectations of existing call sites.

Explicitly listing the call sites, though, goes a long way to understanding why "DoStuff" does what it does.