Code maintenance is hard, therefore a bugfix could easily turn the function to establish_connection_given_these_conditions_and_implicit_one(cond1, cond2);
Now the identifier is misleading and becomes a landmine waiting to blow your feet off :(
Having done some debugging where identifiers/comments/structure are misleading I am a bit afraid of such code.
I am really not sure what is the best way to structure highly imperative code though, because every option I have seen contains some dark corners.
Fair. On of the good aspects is that it makes this chunk testable, rather than having to test the behavior of the long line of statements. If there's a test for it it's a lot harder to sneak in an implicit assumption.
What I meant was that the implicit condition may be too context specific, dunno, maybe some NIC flags or something that are extremely unlikely to be caught by tests (especially written by anyone working on the code piece), code reviews or any such measure. Because the code works seemingly well until underlying conditions stop being satisfied.
Such conditions happen all the time, but are unproportionaly painful to debug in bulldozer code :(
Rant: Even though tests are nearly invaluable, though I personally believe that tests written by the same person writing implementation give a bit false sense of security. I see spec, tests and implementation different representations of author's understanding of the problem. If any two of those (e.g. tests and implementation) are produced from the same mind/understanding then they cannot be used to verify that understanding behind each other is the same.
Having done some debugging where identifiers/comments/structure are misleading I am a bit afraid of such code. I am really not sure what is the best way to structure highly imperative code though, because every option I have seen contains some dark corners.