I prefer the top one too because due to the braces and indentation it's clear that the second return has nothing to do with the first. The structure of the code in the bottom one shows that the second return statement will be executed after the first one (because it follows the if statement). It's laid out like this even though clearly this is untrue.

With the second you also require the knowledge that the statements there specifically are return statements in order to work out that only one of them will ever be reached. You don't need this knowledge with the first example because the control flow points this out already.

For something so small, I agree. But I've seen the same style of code stretched across pages. Then this starts to make a difference.

Plus keeping to a common set of coding standards ensures that all sections of code which are structured similarly to the above will all be laid out in the same way. This makes the code patterns more recognisable on an instinctive level.

Where you have one return happen multiple times and the other return only happen once. Moving the first return out will make the code smaller (and so potentially easier to understand). But that goes against my preference to show the code flow.

Where you have one return happen multiple times and the other return only happen once. Moving the first return out will make the code smaller (and so potentially easier to understand). But that goes against my preference to show the code flow.

My first computer science professor in college marked off points because I did the second one. Not because of style, but because he said it was incorrect - i.e. it would return TWO values. My jaw dropped and I was close to leaving my university. In the end I had to show the professor through output that there was no way for it to be wrong...

Yeah... Fortunately he got sacked and my other professors were much better.

I have since tried to imagine a programming language where it would split itself into another thread for each return value. It would be the worst possible idea ever, but might be amusing. But yeah, implicitly creating threads is probably one of the dumbest things a language could ever do. It'd be even worse than the nil pointer in ObjC silently ignoring all calls to it...

The example I gave was based on some PHP code I was writing at the time, and between the two if statements was lots of work (like database access) preventing the conditions from being concatenated together. I skipped that to simplify my example, but I've obviously simplified too far. So how about...

The example I gave was based on some PHP code I was writing at the time, and between the two if statements was lots of work (like database access) preventing the conditions from being concatenated together. I skipped that to simplify my example, but I've obviously simplified too far. So how about...

// all the shiz that has been outlined in previous examples....// ....but assigning to the final int instead of immediately returning.

returnretVal;}

Yeah someone posted that above too.

I worked with someone who I really respected who did that so I started as well, but in the end I decided it wasn't worth it as sometimes it reduces readability (which is more important in my opinion).

The whole idea of kicking out of a method if you have something "invalid" is much clearer than a giant if statement around the actual body of the code; "if my object isn't null and I am allowed to be here right now then" is much more confusing than "if my object is nill, return, if I can't be here now, return" in my opinion.

The idea of having only one return statement is to reduce potential code paths you can do down and therefore reduce bug count, but I've honestly never found a bug related to return values if you keep things readable and small. A random return inside the middle of a massive method, on the other hand, is a bad idea because it's not immediately obvious how one gets there.

I was in particular pointing out the use of a final; forcing the code to assign the return value only once, which IMO has a positive knock-on effect for code structure & complexity.

I don't think there is necessarily a 'right', or even a 'better' answer to this question; it very much depends on the circumstances of the method. (size, complexity, control structures).I even sometimes find labeled breaks to be more readable than the equivalent for/while loop! (as they are self-documenting, often reduce the size of the loop condition, and keep the logic & it's effect together.

Just in case you were wondering: I wasn't addressing you with my 'rant'.

Anyway, I feel that much of this is part of your own coding style and your own preferences. I too prefer to keep the indentation to a minimum. Early return is comparable to throwing an exception: it should be done to abort the expected flow as soon as possible. Throwing an exception in the middle of nowhere is just as bad as returning at some 'random' location.

It's all about readability, because if it's readable it means it 'maps to your mind', which means it's easier to comprehend, analyze and debug. I think it shows your mind also aborts incorrect thought patterns as soon as possible, as opposed to building a stack of thoughts. Obviously I base this on absolutely nothing.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org