aspose file tools*
The moose likes Java in General and the fly likes Go/Label makes code Readable, if if else else makes unreadable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Go/Label makes code Readable, if if else else makes unreadable" Watch "Go/Label makes code Readable, if if else else makes unreadable" New topic
Author

Go/Label makes code Readable, if if else else makes unreadable

Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
I have following Case, where it is suppose to use label or GOTO related statements.....any alternative please



1) Either i make flow like


Consider as readibility affeected as prgrammer have to scroll down for each that what error is logging

2) Consider this


functionize the thing or what way is better to do this thing?


Regards
Azrael Noor
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Azrael Noor wrote:I have following Case, where it is suppose to use label or GOTO related statements.....any alternative please


I wouldn't say it is supposed to use those statements, just that they'd be one alternative if they existed.

Azrael Noor wrote:
else //Such else formation consider as destroy readability


While excessive nesting can harm readability, I don't think there's any problem with what you have here.

functionize the thing or what way is better to do this thing?


I think what you had with the if/else was acceptable, and I definitely would NOT want to see it with GOTOs. Here are some options:




One possible shortcoming of your model is that you are only noticing one validation error at a time. This may be fine for automated back-end processing where these errors should be rare and any one of them makes it impossible to process that whole unit, but if this were, for example, validating required fields on a user input screen, if the user forgot all 3 of those fields, he'd have to see 3 different error messages; he wouldn't be able to correct everything at once.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Thank you for your great reply. Given my views under each codes






I have used this. Message is different in every case

What do you think is it bad in practice? or any performance Issue?



Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Azrael Noor wrote:
I have around 20 Operations and every object have its own methods, and need to validate minimum of 2 maximum of 10 obj-functions. This will lead to function fair in my case.


Well you're going to have that much different code anyway. I'd say it's better to have it in its own methods rather than mixing validation and business logic in the same method. And if there are too many methods, then maybe you need to split it up into more classes.

Your comment reminds me of an old joke: A guy orders a pizza. The person taking his order asks him if he wants it cut into 4 pieces or 8. The guy says, "4, please, I'm not hungry enough to eat 8."

What do you think is it bad in practice? or any performance Issue?


Did that actually compile?

My first reaction: No, I would definitely NOT use that, even if it is syntactically legal, if for no other reason than it's non-standard and therefore is likely to cause confusion. After looking at it a bit, I don't think it's that bad. If ever there's a use for a label in Java, this might be it. Still, I know that it would confuse somebody down the line and tick somebody off, so I'd be very cautious about the atmosphere in which I used it.

In the end, I would most likely go with separate validation methods (and possibly separate classes). It's easier to understand for most people, and, IMHO, offers the proper division of responsibility. Ultimately though, you have to use your own judgment, taking into account things about your context that you know and I don't.

As for performance, this is not the kind of decision where performance even comes into the picture. These kinds of microoptimizations almost never have any noticeable effect on the performance of your application. You pick the approach that makes the most sense from a design perspective, that's easiest to write, read, test, debug, maintain, and enhance.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Jeff Verdegan wrote:
Your comment reminds me of an old joke: A guy orders a pizza. The person taking his order asks him if he wants it cut into 4 pieces or 8. The guy says, "4, please, I'm not hungry enough to eat 8."


I try to make function in those cases where repetitive codes go on.
but the above code which i mentioned will happen single times, but few of their function may be present in other too.

I have 10 Objects.

1) getResponse - Shown above
2) getAResponse
3) getBResponse
4) getCResponse
5) getDResponse
6) getEResponse
7) getFResponse
8) getGResponse
9) getHResponse
10) getIResponse

These could be increase with passage of time. Now these objects have different states and behavior.

The operations of particular type handles by particular object which is present in particular function
like



sly i have 10 client classes holding that much operations and so on.

To get actual errors, i need to do all that

I have to write validation class for all 10 separately or 1. This would take more time. passing objects there, put in if's, etc.

thats why


Jeff Verdegan wrote:
Did that actually compile?


YES It work perfectly fine
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
The code will go for review and more optimization, so i have used two techniques

> do{} while(false), told by you
> label:, use by me

let's see what they will do, hope they will remove label :p

You idea about separate class is good, but will give lot of complexities in whole project

As you said "easiest to write, read, test, debug, maintain, and enhance. ", will try to follow it

Thank you for help
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Go/Label makes code Readable, if if else else makes unreadable