> The question becomes: when does hiding complexity improve your ability to reason about the code? How about this: "when the degree of complexity hidden is gre

> The question becomes: when does hiding complexity improve your ability to reason about the code? How about this: "when the degree of complexity hidden is greater than the extra complexity introduced by the abstraction mechanism"? Edit: Here's an example to show what I mean. Suppose we have a 2D array representing a matrix of values and we want to print it. We could write an algorithm like this: function print_matrix = for each row i for each column j print_element i j Or we could write something like this: function print_matrix = for each row i print_row i function print_row i = for each column j print_element i j In the second version, we might have shorter functions and less nesting, but we haven't significantly lowered the level of abstraction between one function and the other, so there is little real benefit. On the other hand, we have reduced the cohesion because now the reader must follow the logic through two functions instead of one, and this is bad. There is too much extra complexity created by introducing the second function and not enough hidden complexity because the levels of abstraction aren't much different, so breaking out the inner loop is a bad trade-off that makes it harder to reason about the code.