Monday, July 25, 2005

Code Structure: Multiple Exit Points & Code Standards

On the StriaghtTalking-Java list today, the following question came up:

"What is the consensus with regards to single entry, single exit methods. I was never taught to code to this convention but recently heard that some companies require it. I wondered how people felt about this?"

There were many responses, some agreeing but mostly disagreeing that it was a good "standard" to enforce. Some of the arguments in favor of single-exit-point-ness were:
  • Multiple exit points can lead to more bugs
  • There's too much license in "sometimes it's ok to do x". That's the same as saying "It's always OK if I feel like it on any given day."
  • It is easier to "see" the method structure with one exit point.
My two cents is that code readability wins out over dogma or "standards adherence." Sometimes a single exit point is the most clear structure and makes the code clean. However, I've read and written many, many, many methods that were far more readable with multiple exit points that they were with only one. I also agree that small-grained methods make this even less of an issue, and that exceptions usually throw single-exit off anyway.

To address the "more potential for bugs" argument, I respond with unit testing. A method that is complex or intricate enough to have multiple paths of logic should usually have a set of tests for each of those paths.

In summary: sometimes a single exit point (return) is more elegant, but sometimes multiple returns lead to more elegant code. We might all disagree (and almost certainly do) about how big those two "sometimes" are in relation to each other, but the bottom line is, "Readability/elegance/simplicity trump all coding rules or standards" - it's going to be pretty hard to argue with that.

In general I feel that code standards usually go too far, are too dogmatic. A coding standards doc should, IMO, always be called a "guidelines" doc and the first section/chapter should state something like "code readability and elegance" trump other rules. Yes, it requires careful attention and discipline to avoid the "I don't feel like it today" trap - but if programmers don't have discipline good attention to detail, well then "where they put their curly-braces" or "how many exit points they have in methods" are going to be the least of the problems...

Wednesday, July 6, 2005

Java Generics: I'm not alone

My thoughts on the addition of parameterized types (aka, "generics") to Java have been documented well here, on the StraightTalking-Java mailing list, and the Eclipse newsgroups. Bruce Eckel has always been on the same side as I, but until now there was little high-profile support for that position. Now, however, it appears to be gaining momentum. Ken Arnold has posted a blog entry "Generics Considered Harmful" and I'm glad to see it got Bruce Eckel's attention as well as Lambda the Ultimate.
Mr. Arnold and Mr Eckel are more eloquent than I have been about expressing the position that we all seem to share - I particularly like Ken's coining of the term "complexity budget." That is the succinct, easy-to-understand phrase that I have been searching for in my ramblings on the topic.
Bottom line: I'm glad to see some others coming out to express the idea that this "upgrade" may have pushed Java out of the realm of "simple" languages for good. I'm not alone any longer in my distaste for the increasing complexity the language designers are introducing.
Not that the company makes the discomfort any easier to live with...