What if you're on a team?Quote:
If they don`t have to bother with your code at all, they have nothing to argue about.
Printable View
What if you're on a team?Quote:
If they don`t have to bother with your code at all, they have nothing to argue about.
Answer for JeffAust17 and IntoWind:
goto is dangerose thing and must be used with extreme
care and ONLY if you exactly know what for you need it.
In most cases it can and should be replaced with other
language forms.
That`s why you will never find in C book for beginers
advice to use goto. It will be very bad advice.
For CornedBee:
The best team for man is a man himself.Quote:
What if you're on a team?
The program should be devided to modules and modules to functions.
The module (I guess in your case classes :) must be self defined
peace of code with well defined external interface.
The similar rule for function - it have to do one thing and to do it best.
All that general rules of any design that allow several people to share code.
If you do the function with "goto"`s with well defined parameters and well defined behaviour, the maintanance will not be a problem even by other programmers.
On other hand if you do seemingly simpler function, but with interface that is big library - here you have a problem. Specially if that library is not too mach tested and trusted.
I disagree. While you may be only one working on your module NOW, in the future someone else from the team might be transferred to help you out. In general, because programmers can shift, a single coding standard should be agreed upon for all modules and all code before the actual start of coding. And then you have to justify the use of gotos for the other developers.
Have you guys read the debate earlier in this thread between Galathaea and jfaust? I believe their arguments and conclusion are worth noting:
Quote:
Originally posted by jfaust
goto is an unconditional branch that is separated from the reason for the branch. Other control structures have the reason built in.
Jeff
The reason why goto's should be avoided is that a goto branch is not connected to the logic of the branch, leading to maintainablity problems and the increased likelyhood of bugs.Quote:
Originally posted by galathaea
jfaust, I concede to your superior debate move. Absolutely! It makes absolute sense. Because it should be a design principle that one should keep a branch connected to the logic of the branch. And so, this design principle invalidates the use of goto ever. Of course, I could argue that one could still use goto if the branch condition is connected to the goto in a complete statement group (if, goto) but then you have maintainability issues. Brilliant!
** galathaea spins melodramatically at the fatal shot to the heart **
Whispered, last gasp: "I have been fell by the greater rhetorics of jfaust. All should follow his advice. Never use goto."
Fine but what does it mean? Separated from what logic. A goto is used to interrupt the normal flow of other control structures, but so is a break statement. There's no difference in principle. It's just that break has got a fancy name and become accepted over time. It's still a goto, as structured programming affectionados can tell you.Quote:
Originally posted by KevinHall
The reason why goto's should be avoided is that a goto branch is not connected to the logic of the branch, leading to maintainablity problems and the increased likelyhood of bugs.
To use a goto once in a while as an extended break (jump to the exit point of a block) isn't the end of the world. It can even improve code because it can reduce the structural complexity of for example nested loops.
'if', 'while', 'switch/case' and 'for' have built-in well-defined branching logic. These largely replace any need for 'goto'. But alone they are not enough. There are some cases where you need more control for the looping constructs. 'break' and 'continue' help this. They both have a single well-defined purpose. 'goto' has no single well-defined purpose. 'break' is to break out of the loop. 'continue' will start with the next iteration on the loop. 'goto' could be used for either of these, or to jump to some exit/error condition, or to jump into the middle of some other if statement, or anything. Hence, there is no single well-defined purpose for it. That's the difference. It is separated from the reason for the branch.Quote:
Originally posted by _uj
Fine but what does it mean? Separated from what logic. A goto is used to interrupt the normal flow of other control structures, but so is a break statement. There's no difference in principle. It's just that break has got a fancy name and become accepted over time. It's still a goto, as structured programming affectionados can tell you.
No, not the end of the world. An no, not every place it is used is a maintenance problem. And yes, it can be used conscientiously. I'll even admit there may be cases where it can reduce structural complexity. However, I have not seen such an example in ten years that couldn't be fixed by a better method than using goto. Before that, if I used it, it's only because I didn't know better.Quote:
To use a goto once in a while as an extended break (jump to the exit point of a block) isn't the end of the world. It can even improve code because it can reduce the structural complexity of for example nested loops.
'structural complexity' is a big concern of mine. I've always found a way to deconstruct complexity without resorting to goto. Take nested ifs as an example. There's usually a question you are trying to answer with the nested ifs. Maybe you are trying to get at an object through several layers and want to perform null checks on each layer. Maybe you are checking various statuses. Whatever the case, this logic can often be moved to a separate method.
'structural complexity' usually comes about because the method is trying to do too much. So, decompose the problem. Don't use goto. Future generations of maintainers will thank you.
Jeff
A break is connected to the logic of the while or for loop.
Yes in C++ it is but Java for example is more liberal. There you can jump out of any block and even define labels to break to (within limits) like this,Quote:
Originally posted by KevinHall
A break is connected to the logic of the while or for loop.
It's quite interesting that Java is more permissive than C++, it so seldom is. I think the reason is to furher reduce the need for a goto statement, the greater evil. ;)Code:boolean b=false;
repeat: {
// ......
if (b)
break repeat;
}
Well, maybe the java people should post a thread in the Java forum about the evils of labelled break statements. ;)
The whole idea with the goto is that it's able to interrupt all other control structures at will. It's a very poverfull ability but this isn't why it should be avoided I think.Quote:
Originally posted by jfaust
It is separated from the reason for the branch.
Structured programming is about complexity reduction and in some cases the goto, and it's cousin the break, actually does that. One example is when you jump out of nested loops and thereby simplify loop exit criteria.
The break is interesting because what you do is basically to trade logical complexity for structural complexity. With a break you make the loop exit criterium simpler, but you pay with a more complex loop structure. I personally find a few breaks easier to comprehend than a huge boolean exit expression with lots of and's and or's.
Well, I very much agree with what you say Jeff. I also think goto should be avoided, but I'm not that totally against. If you can accept the break you should also be able to accept the judicious use of a goto for a purpose. It's sloppy, lazy usage that should be banned.
I can agree with that, even though I doubt I will ever see a need to use it myself.Quote:
Originally posted by _uj
If you can accept the break you should also be able to accept the judicious use of a goto for a purpose. It's sloppy, lazy usage that should be banned.
Another difficulty with it is that it's hard to put in a coding standards for a development team. It's much easier to say "don't use goto." Every team has a mix of talent and different areas of expertise. You may accept a poor programmer with a mostly fortran background if that person is an expert in the field, especially for scientific applications. Coding standards become very important, and increases with the size of the team. Effective rules can't be ambiguous.
Code reviews don't really help because it's very difficult to tell somebody to change something that works. But if you have a coding standard that prohibits it, you can ask them to change it without feeling like you're stepping on any toes.
Jeff
I see your point, but it's not just the goto's is it? C++ offers you an almost unlimited opportunity to screw up. At least that's my first impression. I have a Java background and in that language most of the dangerous stuff has been left out. Unfortunately some of the useful stuff too. That's why I'm here. :)Quote:
Originally posted by jfaust
Another difficulty with it is that it's hard to put in a coding standards for a development team. It's much easier to say "don't use goto."
/Ulrika
Certainly, but goto is much more likely to be misused. It can be employed in almost any scenario, but there are very few (if any) valid uses. And when misused, even when logically correct, creates a real maintenance headache. Moreso than any other C++ construct.Quote:
Originally posted by _uj
I see your point, but it's not just the goto's is it? C++ offers you an almost unlimited opportunity to screw up.
Except perhaps for compound ternary operators:
a = b ? c : d ? e : f;
:)
Jeff
Well...that is actually one of my lifetime favourites...it has saved me so many 'if...else' keying... :cool:Quote:
Originally posted by jfaust
Except perhaps for compound ternary operators:
a = b ? c : d ? e : f;
Now don't make me mad, Andreas. You won't me when I'm mad. Veins start pulsing in my forehead and such.
Jeff
I have a feeling the goto is just a minor problem in C++. On the level of structural programming it can wreak havoc of course but that's just on the C level. It's not a very big problem from a maintainance viewpoint really. The goto and the ternary operator must be very minor problems on the grand scale I'd say. The real problem with C++ must be at the OO side. How do you get a Fortran programmer to understand for example inheritance and how to use it correctly?Quote:
Originally posted by jfaust
Certainly, but goto is much more likely to be misused. It can be employed in almost any scenario, but there are very few (if any) valid uses. And when misused, even when logically correct, creates a real maintenance headache. Moreso than any other C++ construct.
Except perhaps for compound ternary operators:
a = b ? c : d ? e : f;