I think the problem is that it's difficult to articulate what clean code "looks" like. Unfortunately, this is precisely the medium ("looking") through which man

I think the problem is that it's difficult to articulate what clean code "looks" like. Unfortunately, this is precisely the medium ("looking") through which many developers learn best. Yes there are books, and rules, and this, and that explaining which properties clean code must exhibit, but for many these rules are simply too abstract when the rubber meets the road. So we start to emulate the "look" of clean code (example are everywhere!) instead of the intent. And you know what happens... a mess. For those of us who have finally made it to the other side of the above process, clean code is more of a "feeling" than a "look". Of course we can point to pain points in the code and explain why this or that might need to be refactored in order to be more "clean", but our spidey-sense is our guiding light _not_ some internal catalog of "unclean" code snippets to avoid. For me the most important part of writing clean code is making sure it can be understood (which means it can be changed). And to this end I think Flow Of Control tends to be an important consideration because I have realized it's less about "looking" at the code and more about "seeing" the program.