The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
You are convinced that goto's and ternary operators are examples of bad programming.
Good grief. I didn't say ternary operators were bad; I said that since they are no longer needed in your specific code, they can be removed. What I learned was that the code
text == "" ? "0" : ...
does not throw an exception in C# if text is null.
My view that gotos are bad is based on years of experience of finding bugs caused by their use (even in assembly where JMPs are a given and cause all sorts of problems when you aren't careful.)
Condescension is in the eye of the beholder. In this case, you had a code review, extremely valid suggestions were made on how to improve it. You concede that much of what you are doing isn't needed, but insist on keeping it that way. That's fine, but don't go around blasting everyone for being condescending, a snob or not seeing the full picture.
Do you have an example? After years in the trade, I have still to see the first instance where it actually improves readability/maintainability.
In C/C++ for e.g. in a switch statement where you must share some portion of code.
Although one can put that shared part inside another function, for visibility & tracking purposes, some times is better to have the code in the same screen avoiding scrolling up and down to follow the code. Believe it, is real but I cannot show company code.
I don't remember which old Pascal guru told that but sometimes a goto is preferable instead of doing a lot of work to avoid its usage and make the code difficult to read.
For the other side, as an assembly programmer... I see JMPs everywhere hehehe.
Days ago started to program a driver and remembered me that, altough in some places you can see try/leave/except blocks is modern code, because is programmed in plain C, "goto" is still used a lot mainly for cleanup purposes.
I don't use it in high level languages where there is a structured alternative. The only time I'm tempted is the 'double break', i.e. wanting to escape from two levels of nested looping; to do this you have to create a method to do the double loop and use return, which often feels like overkill.
I've using one while I test some timeout code on a function, but I'll refactor it out before I commit it. Just nice to see the whole process at once for now (and I can make sure it works before I spend time figuring out exactly how to best cleanup before cancelling it).
I have always thought goto was the equlivant of the assembly language jmp (blocking?), if it is I used one this morning. Goto is also acceptable in RTOS situations (which Windows isn't) if you want the valve to close now and not later.
Well as an assembly programmer I really don't have much choice.
And as for higher level languages, sure, though rarely. There are people who religiously avoid it, but that's just silly. We must remember the reason it is seen as bad, and not open a witchhunt.
Introducing a boolean variable just to quit out of a non-enclosing loop makes readability/understandability worse, not better, and refactoring an inner loop into its own function just so you can return out of it creates a bunch of tightly-coupled functions that do nothing useful on their own. Besides, that return would essentially be a goto.
In one of our legacy apps (VB) the goto is used to apply database updates based on the exe version. ErrorHandlers: seperate the update logic for each version and are arranged from top to bottom so that code execution always 'fall through' to the bottom. It may me wrong but it works!
I put it into my own language just because I wanted to see if I could write a program all in one function which started at the bottom and worked its way to the top. I am not sure why, one of those days. I then immediately removed it from the language spec although the code for it is still in the compiler source - just commented out.
I only use it nowadays in assembly (no choice) and scripting languages that don't have good structured programming constructs (ie. if/then/else etc.).
I learned programming in the days of early Fortran IV (and actually regressed a little on an older machine with Fortran IID) that only had arithmetic if[^] and computed goto[^] for conditional logic flow.
I really came to appreciate the evils of the 'goto' statement and never use them unless there is no other choice. If I use a goto, it will always transfer control downwards, never up.
And yes, I use break and continue, and multiple returns in methods.