The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Sorry.. I see the case you are trying to make, but in this specific case there is a simpler goto-less construct:
private static void AltFoo(int x)
Console.WriteLine(String.Concat("Option: ", x));
if (x != 1)
if (x == 0 || x == 1)
I expect your response will be something along the line of 'extend the example to more complex cases and the if-then approach becomes unwieldy'. Granted.
Of the three examples (mine and your two), your second example is the best solution. It is considerably easier to understand and is more maintainable.
Suppose the specification adds support for three other languages: French, German, and Italian. The goto version becomes impossible (without a lot of convoluted spaghetti code), but this code is very clear:
I expect your response will be something along the line
Actually, I don't really use gotos, and was merely throwing in a generally pushed point of view, hence the use of "some people" in my first sentence. And in my example, I'd always choose the goto-less version or some similar variant.
Somewhere in this thread, it has been assumed that I'm a VB guy
I think goto started life in basic which morphed into VB so the assumption seems reasonable to me.
There are a lot of us around that code in both VB and C#, most seem to have a preference to C# but VB is so very common. I moved our teams to C# because all the best examples are in that flavour (and I needed to learn something new/different about then anyway).
Never underestimate the power of human stupidity
To answer the poster: Here are some reasons why I would not if I was writing the IDE on a deadline:
I wonder if some Microsoft developer could post the number of "goto" statements present in the VS 2010 code base. This might be a hint. If there is not a huge number, I would love to know how many goto statements were used that were NOT for exiting an inner loop.
0. Assumption: gotos are rarely used.
1. Assumption: A goto will only be used to break a nested loop.
This means that you will type "goto done;" and a few seconds later type "done:".
2. Assumption: each label will only be referenced once (maybe twice)
3. Assumption: It will probably be a short label. (e.g. done: )
4. Assumption: A developer will never do this more than once (maybe twice) in a C# method.
If they need more than one label, they will probably split the method up.
5. Given: The label is always local to a method.
(You are not trying to retrieve a property or method from some object
that you did not write)
6. Given: If you type the goto and label so that they mismatch, the compiler will catch it.
See #2 and #7.
7. Given: If the IDE developer goes through all of the trouble to give a list of valid labels, and you select the WRONG label, you are just as screwed as if you had typed the wrong label!
8. Given: Workaround: Since it is local editing, just use Copy+Paste. Closed - Feature Not Needed.
P.S. Java killed the goto via the break [label]; and continue [label]; statements.
goto is a Java reserved word, but also a compile error.
C# decided to follow C++ and keep goto;
Not a proper softy (I'm a hardware guy who programs on occasion) I have used a goto only in RTOS situations where if the program counter/accumlator goes beyond a certain point it will make a whole in the wall as it goes beyond reach. I was one of the spagetti basic guys who gave the goto a bad rep. It's just a way of moving around the memory so thats why the .NET compilers use it (or a jmp or jump instruction) it's only when people who didn't know what it was or how to use it got involved did it get a bad reputation.
I totally agree with you.
Goto is used everywhere by everyone, right now, in C#, but it is abstracted to look like more complex statements. Goto can be a powerful tool in the right situation, especially in native c/c++.
I agree that a lot of programmers could really screw up a pile of mud if they were given powerful tools, but I don't think that means you outlaw back-hoes. It means you smack the hand of the ones who run with scissors around others, or go ahead and poke them in the eye so they know the consequences.
Allow me to protect me from myself.
Don't force me to be protected from myself.
First thought is, wouldn't it be quicker to type goto than to use intellisense anyway?
You hit "g", all available commands starting with G show up, then you select the one you want, then hit enter. Three key presses assuming it's top of the list, otherwise it would be easier to just type it up.
It would be like waiting for intellisense to give you the IF command instead of just typing it. Amusing if I'm observing, useless otherwise.
Goto usage is the ultimate spaghetti type programming, so you don't want to go that way. It's not a crusade, it's a fact.
Believe me - a former spaghetti analyser that has programmed for years in language like Data General/UBB (Universal Business BASIC).
For a long time in those languages (interpreter based) the "do while/for loop" instruction didn't exist and every line in your program had a linenumber. With the goto you could force a kind of do while or even if then else. Also a goto made the program go faster (interpreter) skipping the lines that it didn't needed. The goto was of course abused making the readability very poor.
Here's an example of a do while in old BASIC
100 if i<10 then
110 ... (instruction)
140 goto 100
150 end if
Gradually the linenumber became labels and vb3,vb4,... took on this way of programming.
100 if i<10 then
120 goto @start
130 end if
Those (nostalgic) days are gone now...
I think the only reason why MS didn't completely erase the command is backwards compatibility with VB6 where you had to use it with (on) error handling. Now you have an (even better) initiative for this, the try/catch/finaly block. The finaly part is certainly an improvement.
Conclusion : "Spaghetti is nice as long as it's on your plate accompagnied with some tomatoesauce, cheese and some tabasco".
My primary reason is for complex validation that share the same exception. Here's an example:
public void validateSomething(someComplexType)
else if (complexAlgorithmRequired)
//init vars for algorithm...
else if (second_conditionFails)
else //perform second phase of algorithm
//init vars for second phase...
else if (second_conditionFails)
//skip the end-of-routine error code
//set class vars...
//to an invalid state...
throw new someException();
How would you implement this with try/catch without a whole bunch of "throw someException()"?
The mind is like a parachute. It doesn’t work unless it’s open.
I didn't know for for what purpose you were trying to use the goto that's why I assumed it was for as try catch system (is the most common use). On your case it's not the try/catch that has to be used.
How I would solve this problem, is by using validationfunction with a return value.
This way you could even put your validation in a separate class or library.
It's a standalone function. Best practice to seperate this because if your using winforms, you could easily use the same validation when you decide to use ASP.net or something else.
Compile the lib as a dll, put the function public and you can use it in any language.
The enum is practical in .net because the intellisense kicks in but you could easily test it on the values 1,2,3
In fact you could consider the return value as a kind of a label.
I'll put it in VB because I know this best but you'll get the idea.
firstcondition = 1
secondcondition = 2
thirdcondition = 3
Private Sub ValidateMessage(ByVal someComplexType)
Select Case ValidateSomething(someComplexType)
Private Function ValidateSomething(ByVal someComplexType) As ValidateError
If someComplexType < 0 Then
If someComplexType > 100 Then
If someComplexType > 1000 Then
If someComplexType > 2000 Then
Yo've gotten a lot of negative replies (that I can see) because the GOTO statement is considered to be in the top 10 of BAD CODING PRACTICES in OOP. This i because GOT equates to 'Spaghetti Code' and thats something none of us ever want to hae to deal with.
If you are coding properly you don;t need to use GOTO in an OOP langauge; assuming you are using an update or current version. If you were using say VB 3 or something that may be a differnet story.