• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
reply
    Bookmark Topic Watch Topic
  • New Topic