Multiple Points of Exit Failure
Mark Mzyk | December 5, 2007
So I haven’t actually read the book, but I do keep up with the Beautiful Code blog to see what interesting ideas are bought up. I particularly enjoyed the now older entries on not so beautiful code (here and here). I certainly could sympathise.
Why do I bring this up? Well, courtesy of my coworker Kevin, who mentioned this idea in passing one day, I have a suggestion for something that might be useful in measuring how beautiful code is and helping to enforce its creation:
A multiple points of exit failure.
It’s simple – the IDE or compiler could check the exit points of a function, and based upon a ratio of lines of code to exit points, throw this failure if needed. I would imagine any function ten lines or under should only be allowed one exit point, and for every ten lines after that allow another. No function should have more than three exit points at most.
I know someone out there is slinging spittle at their monitor as they foam at the mouth after having read that last paragraph. Yet I think you have to agree with me that if you generally try to limit functions to one exit point that it forces you to write tighter and more intelligent code that also ends up being easier to comprehend.
Are there exceptions? Certainly. There are rarely any hard and fast rules. But in my experience, the less exit points there are in a function, the more beautiful it is. Now, it takes more than just one feature to be gorgeous, but it’s a start.