Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Java Unit Testing in Java What to Test Know Your Bounds

JT Keller
JT Keller
12,731 Points

Single Entry/Single Exit Philosophy in Java from Unit Testing in Java

Hey Craig,

Enjoying the course so far! I did have a quick question regarding the fix you implemented for the getItemPrice method. Most of the developers that I work with follow a strict single entry (self enforced with most modern languages) along with a single exit philosophy. Based on what I've read, the single exit piece of this philosophy seems somewhat antiquated. What's your take on this approach?

Relevant Link: http://stackoverflow.com/questions/17295315/when-a-statement-is-said-to-be-single-entry-single-exit-and-when-it-isnt

1 Answer

Craig Dennis
STAFF
Craig Dennis
Treehouse Teacher

I think it really depends on the situation and the complexity of the code inside the method (in which case the method should probably be broken down farther).

The single exit principle is pretty dogmatic and like you said antiquated. The single return was actually originally attempting to tackle the spaghettiness of GOTO statements, and it has long been misunderstood to be returning from when the original problem it was solving was returning to. That being said others have made cases for when this principle is still valid in a Java return way. But that said, it's dogmatic in most cases and does not improve legibility.

If your code doesn't produce side effects, I actually think that the sooner you can exit a method the better. But that's a matter of taste and team. Always follow whatever style is in place, but if I am writing new code, I usually always default on returning early and often. I think it reads cleaner in most cases.

I'm going to do a little Google hunting to see what popular style guides say about it, and I'll let you know my findings.

Craig Dennis
Craig Dennis
Treehouse Teacher

No clear mentions in the big ones, but lots of multi-return methods ;)

Gavin Ralston
Gavin Ralston
28,770 Points

[the problem was] misunderstood to be returning from when the original problem it was solving was returning to.

...and that problem seems solved since method calls are returning to the same point in the code so why are folks clinging to the dogma? Seems the Martin Fowler "Refactoring" quotes in that S.O. post made a whole heap of sense.

Or, really, it makes a whole stack of sense.

(crickets)