3 ms·

> What you have stated is an article of faith from the structured programming movement back in the 1970s. There should be one and only one exit from a function

by jrajav 14y ago

> What you have stated is an article of faith from the structured programming movement back in the 1970s. There should be one and only one exit from a function or loop. However this is an article of faith that does not tend to be backed up with any concrete evidence that it is right - just unsupported assertions. This is a little overboard, considering that I did offer support for my assertions: My own personal experience, and sound explanation. I have had to maintain code heavy with returns, and not of the sane, early-exit kind mentioned by peterhunt - deeply nested returns based on obscure logic. I didn't even know before now that there was any such "movement" around this particular opinion, however long ago, I just know that it makes sense for me and will always appear in my style guidelines. And yes, it would be much better to finely modularize your code in the first place so that low level flow-control guidelines like this become trivial, but that's not always practical on a large team with programmers of varying skill.

btilly 14y ago
Your "support" was a bare opinion about what kind of flow of control is easiest to read. To me that is just a restatement of your opinion and not support. By contrast in two responses, two different flows of control were presented where early exits make for more readable code. (Guard conditions and the loop-and-a-half problem.) Furthermore my personal experience disagrees with you, as does the reasoning of a fairly well thought out article that I referred you to. Which also presented pointers to research indicating that it is easier for students to produce correct code for some common problems if they have the possibility of correct code. Granted, students are generally less competent than professional programmers. However if you're concerned about varying skill on your team, why would you choose to make it harder for the poorer programmers to correctly solve problems? Out of curiosity, what would it take for you to reconsider your style guides?

by jrajav 14y ago

btilly 14y ago

Your "support" was a bare opinion about what kind of flow of control is easiest to read. To me that is just a restatement of your opinion and not support. By contrast in two responses, two different flows of control were presented where early exits make for more readable code. (Guard conditions and the loop-and-a-half problem.) Furthermore my personal experience disagrees with you, as does the reasoning of a fairly well thought out article that I referred you to. Which also presented pointers to research indicating that it is easier for students to produce correct code for some common problems if they have the possibility of correct code. Granted, students are generally less competent than professional programmers. However if you're concerned about varying skill on your team, why would you choose to make it harder for the poorer programmers to correctly solve problems? Out of curiosity, what would it take for you to reconsider your style guides?