I'll agree that one case doesn't make the rule bad, but the rule hasn't been proven yet either. > There are complex dependencies among the subroutines which ca

I'll agree that one case doesn't make the rule bad, but the rule hasn't been proven yet either. > There are complex dependencies among the subroutines which can probably be simplified with refactoring, and which should be explicitly called out, but are allowed to "hide" in the original code where, locally, we have 7 global variables shared by 4 inline subroutines -- not a good situation. What is locally global supposed to mean? This piece of code can be written at least two ways: as a single function with comments or as a function calling four other functions. Just because splitting it up into multiple functions a certain way requires multiple returns or long argument lists doesn't mean that the original code is necessarily bad; It could be that the splitting points were chosen badly or that this code is simply better off as a single function. These "complex dependencies" you're worried about form a DAG in the example which seems simple enough to me. Anyways, most of this is moot without real code.