• Post Reply Bookmark Topic Watch Topic
  • New Topic

if else coding style  RSS feed

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Hi I was wondering which is a preferred way of writing methods like this:


The code above uses 'else' but I think the following is better:


Which is the recommended?
 
lowercase baba
Bartender
Posts: 12565
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some folks would say neither. a LOT of people think there should only be one exit point from a method, so they'd recommend this:



update...i'm not sure this will work with Y being declared 'final', but the point is still valid...
 
Greenhorn
Posts: 11
Java Spring Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I prefer less code lines... but the bettter way is the one posted by fred rosenberger
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I would prefer below:


i.e. only one exit point and return value can be clearly deduced from conditions.
 
Santiago Tovar
Greenhorn
Posts: 11
Java Spring Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
fred rosenberger wrote:Some folks would say neither. a LOT of people think there should only be one exit point from a method, so they'd recommend this:



update...i'm not sure this will work with Y being declared 'final', but the point is still valid...


It does not work because Y is final.
 
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Santiago Tovar wrote:
fred rosenberger wrote:...
update...i'm not sure this will work with Y being declared 'final', but the point is still valid...


It does not work because Y is final.


Yeah, that was a mistake. If we assume that Y should be final and should be defined inside the method then fred's code should be written something like:


 
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Standard consultant's reply: It depends.

1. If you don't have a team coding standard, then no foul no harm. Maybe talk to your teammates about adopting one for future reference.
2. If you have a team coding standard, try to follow it.
3. However, if you think that an exception to the coding standard can be justified, discuss it with someone on your team.
4. If your teammate(s) agree with the break from the standard, go with it. Consider updating the standard to call out the exception.
5. If they don't agree, ask yourself if it really hurts you to follow the standard. If it doesn't, go with the standard.
6. If you and your teammates just can't come to an agreement about the break from the standard, your problem is more than just a coding standard.

I have commented on this in a previous post but I'll repeat here since I'm too lazy to find the link. The "one exit point" rule is a good rule of thumb to follow. It's especially good to follow in code that is more than 20 lines long. However, a justifiable and well-placed return in a short method does not do much harm. See the refactored code in this Composed Method example. Here, the guard/sentinel clause idiom calls for an immediate return. The other exit point is the end of the method, where execution just "falls out" but having the two exit points doesn't seem at all bad.

Another case in point:

This is part of a typical implementation of Joshua Bloch's recipe for overriding the equals method. It is clear from the first two if-statements that no other calculations need to be done if any of these conditions are true, so just return the result immediately. This clearly violates the "one exit point rule" but it doesn't really matter that much. Why? Because the rule is there for a reason which is mainly to improve code clarity. When you have unclear and convoluted code, multiple exit points just add to the confusion and can create more problems. However, if you effectively attack and resolve any problems having to do with code clarity, you might find that having multiple exit points is actually a non-issue. That's exactly the case in the equals() recipe implementation above. Any attempts to force conformance with the "one exit point" rule might actually result in more complex code if you end up with a deeply nested if structure.
 
Peter Kovac
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Junilu.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!