I've just read about spaghetti code ( wiki link) that "goto" statement creates, I wonder if label in java makes spaghetti code?
I just interested in this because one of my old question about break and label in java that I asked here
Labels are so rarely needed/used that no, not really. Also you can't jump to a label, you need to break to it, so you can't get the similar kind of confusion as with filling the code with goto whereever statements.
The main problem with labels is that they are rarely used which means they are surprising and possibly confusing for a reader. e.g
http://stackoverflow.com/
System.out.println("Hello SO");
At first glance, that doesn't even look like valid Java code, but it is.
Because labels tend to be used only when the are really needed, and sometime not used when they should have been used IMHO, they don't lead to spaghetti code in Java in reality.
Related
while reading "Java complete reference seventh edition" in page 100.
I read this statement "However, be careful. Too many break statements have the tendency to destructure your code"
What I don't understand how can break statement change or deconstructed in my code?
Is that in java only or in all programming languages?
Is that something linked to byte-code?
Thanx so much, please do not misunderstand me :)
Too many break statements have the tendency to destructure your code
I believe that the author means that it is more difficult to follow the execution paths in your code. This is because break jumps to a line of your code that potentially can be far away from the line with the break.
The author uses the word de-structure your code. Its just an expression. what he actually meant by that is:
Imagine you writing five loops one inside another having break statements for all the loops. If the loop gets bigger and bigger, there are high chances of losing the execution path as a developer i.e. which loop is being executed and from which loop the control has broken out of.
Imagine the chaos it creates if you have more loops having break for each loop/more break statements for a few loops. The only thing that catches your eye is the break statement .
However, be careful. Too many break statements have the tendency to destructure your code.
This doesn't mean that if you have a switch statement to compare over 100 unique values, then it will de-structure your code. Because, in this case, that's the only need.
But suppose, you are using too many loops, could be anything, for-loop, while-loop, do-while-loop or even if-else conditions, excessively using breakstatement will come out with too many permutations and combinations of execution path which we at development phase might not see. And then, can cause a big trouble at real time execution with multiple values or multiple types of values which may trigger a new, unexplored path of execution. (I mean, those paths, which we were not intended to create.)
So, the author says better to avoid too many break statements. Not all.
Why using labels in Java is a bad practice? I cant find a reason. All explanations - you shouldn't use it just because you shouldn't.
It's difficult to read code containing breaks to a label. Also, a label can be accidentally moved, or code inserted at an incorrect location with respect to a label. The compiler is not able to warn you of these effects since the code remains syntactically valid.
Code that's difficult to read is difficult to maintain. Bugs will inevitably creep in.
Other control structures (break, continue, while, for, etc.) don't suffer from this.
Note that a switch to a label doesn't suffer from these effects either: the structure of a switch block is well-defined.
The most sensible alternative to breaking out of a nested loop is to recast the code to a function and use return. You also get the added benefit of being able (potentially) to return a value back to the caller.
I think that you are referring to break and continue labeled.
The problem is that labeled break (and continue) is a construct of imperative languages that is absolutely not related to Object Oriented.
In Object Oriented programs the flows can be easily understood. It is not possible to jump from a part of code to another part of code, you can only call a method or continue current code or exit the current block of code.
Jumping from position to position is a probable point of break for your application where bugs can easily happens. Jumping creates what is called spaghetti code
Labelled breaks (and breaks, in a smaller way) are a more-modern equivalent to the old GOTO statements of older languages (FORTRAN, COBOL, Basic). Goto statements were found to be much more liable to contain an error than all other kinds of statements combined -- the study I'm remembering measured it as 9 times more likely. This gave rise to the "structured programming" movement in the 70s, and the banning of the goto statement from some software shops at the time.
It is more important to be able to read code easily than to be able to write it without restrictions.
Labels are fine to break out of nested for-loops. I'd suggest to put the nested loops in a separate method and then break out with return.
The problem is that the complex flows of processing becomes really hard to follow.
I just want to get some information before I go ask my teacher during his offices hours tomorrow.
We have have project to do thats something like an iclicker question answer collector. He told us to avoid using switch case statements. I was just wondering why and why don't people in the field like using them, what alternative is there to do? and I doubt he wants us to use if statements either.
I think we have to use polymorphism/interfaces but I just cant rap my head around that, switch cases seems so much straight forward.
Thank you.
Usually when an instructor asks "don't use feature X", it's because they want you to learn how to do something without using a feature that might be a shortcut. In your case, it sounds like your instructor wants you to wrap your head around polymorphism. If you don't, you won't learn that bit and will have much more trouble later in the class.
It depends upon the project. For example, in using a RESTful APi, you do have switch statements because there is a limit, known set. But, with your program there might be a lot of different options and that option can change, increase (or decrease), so while you started out with three cases, then something else is wanted, that's four, then five, and so on. You end up with 50 cases, and that's probably not good or easy to maintain.
With your OOP class, the instructor is probably going to show you that. Come back and show the whole problem and the final result, and maybe others can shed light.
There's an example that I've seen in my old Java book, and did a search and see it is still decent. Consider employees and salaries. You have three types of employees, then you have 50 types.
On a small scale, there appears to be not much difference. It requires enlarging the problem and considering consequences.
Ways to eliminate switch in code
That is a good example. Sure, there's only two cases in that example. But, again, what if it were 50? How easy will it be to maintain that? A lot of things in programming are about saving time and making things logical in the long run, as you will be coming back to your code or someone else's, and you have to maintain and support it.
I am trying to learn proper code formatting in Java, the conventions, keeping it neat and putting proper comments.
I am baffled, however, on what wording I should use when I call for a JOptionPane input dialog in order to 'receive' a user-specified value.
What is normally used in this situation?
I am using "// Get user input", but I just read an article explaining that 'getting' something has an entirely different meaning whatsoever.
In my opinion comments should explain why you do something (if it is not obvious). The code itself should tell how it is done.
If you cannot understand what the code does, the code might be bad.
If you understand the code but don't understand why a specific action is executed, you are missing a comment.
So instead of adding a comment like // read user input you should name your methods and variables in a useful way:
...
String userInput = getUserInput();
...
No comment needed to understand this.
Don't stress too much about the exact language of the comments. You just want them to be clear so that whom ever comes behind you to maintain the code will understand what is going on. Don't worry about syntax for comments, it really isn't that important.
You could say:
//get user input
//read user input
//take user input
Honestly, it is one of the least important things to worry about. Just make sure that people know what you are doing. I'd focus on making the code itself clean and well-formatted, not the comments. It's important to have comments, as most programmers don't take the time to do it, but it isn't the most important thing.
It is more important to watch your verbiage when naming methods/classes/functions/variables. Not the comments.
:)
After running Sonar on one of my project I get a violation for 'trailing comments'. So I wonder, is this purely related to accepted/recommended code layout conventions for Java or is there 'more to it'? What's the reasoning behind it? When I'm looking over some C++ code ( recent Doom code review, there are tons (or binder full of) trailing comments.
From the famous book Code Complete:
The comments have to be aligned so that they do not interfere with the visual structure of the code. If you don't align them neatly, they'll make your listing look like it's been through a washing machine.
Endline comments tend to be hard to format. It takes time to align them. Such time is not spent learning more about the code; it's dedicated solely to the tedious task of pressing the spacebar or tab key.
Endline comments are also hard to maintain. If the code on any line containing an endline comment grows, it bumps the comment farther out, and all the other endline comments will have to bumped out to match. Styles that are hard to maintain aren't maintained.
Endline comments also tend to be cryptic. The right side of the line doesn't offer much room and the desire to keep the comment on one line means the comment must be short. Work then goes into making the line as short as possible instead of as clear as possible. The comment usually ends up as cryptic as possible.
A systemic problem with endline comments is that it's hard to write a meaningful comment for one line of code. Most endline comments just repeat the line of code, which hurts more than it helps.
Having said that, it's also about one's choice about coding style. I would personally avoid trailing comments as they don't help that much.
Just because something has trailing comments doesn't mean they're good. Also bear in mind that Doom 3's code is ~10 years old, and coding styles change over time.
In general, trailing comments indicate that a line of code cannot stand on its own. And, in general, that's a code smell, because a single line of code should be fairly transparent.
Looking through some of the source I don't actually see a ton of trailing comments, though I see a lot of methods that are too long, and a lot of comments in the middle of functions.
Those often indicate the following code deserves its own method.
I would argue that yes, there's more to it, and the "more" is communication and clarity.
Trailing comments are nothing bad per se. However, you should write your code as clearly as possible so that you don't have to explain your code line by line using comments. That's why some people consider trailing code comments as a hint that the code is not understandable enough.
See also the Java Style Guide for more information about that.