|
rgrep goto /path/to/linux/kernel/sources; git blame each of the hundreds of occurrences, and then try to convince those who committed that lines that they are worse coders than you are. Chances are, you're going to fail miserably.
|
|
|
|
|
After far more than 20 years with C/C++ (and other languages too) I put it this way: I strongly recommend not using goto - except if it is really necessary. There should be no dogma but only good reasoning.
There are good reasons for using a goto (most goto-s I've seen did not, but few did). In total I personally used it about maybe 10 times over all those years, but (as far as I see it) not breaking readability but guaranteeing readability at those perticular points. Of course it would have been possible to avoid the goto-s there too but only if I would have been breaking the "natural" logic of that code (or at least what seemed "natural" to me  ).
Making a long talk short, I think: "There is no silver bullet".
|
|
|
|
|
1. If it is critical that your code is correct, don't use goto: it has the capability to jump out of or into one or more nesting layers - even backwards - and thus makes it considerably harder to verify the correctness of the code.
2. If there is more than one programmer on the team, don't use goto: using it makes it considerably harder for another programmer to understand the flow of code, and what it is supposed to do.
3. If you intend to build on and maintain the code over a period of more than a couple of months, don't use goto: viewing a piece of code that you yourself wrote a couple of months ago is often not so much different from viewing another programmers' code - see item 2 above.
Please note that modern programming languages have plenty of alternatives that can be used in many cases where goto could be used. In C/C++, here are some examples:
- to repeat a block of code, use a for, while, or do loop construct rather than jumping backwards
- to skip over some piece of code, use an if-block rather than jumping forward
- to skip over the rest of a loop body, use continue
- to exit out of a loop, use break
In C++ you should also use the standard exception handling mechanism rather than using goto as an error exit mechanism. (There is no equivalent in C, so you might argue that in C the use of goto for that purpose is acceptable - but see below!)
The main reason however that you shouldn't use goto is that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions about goto. In all that time I've never heard or read one compelling argument in favor of using it. Yes, you can use it to reduce or avoid nesting, or otherwise reduce the amount of code. But that by itself is not a valid argument in my book.
|
|
|
|
|
Nearly all the static code analysis tools I know are operating on a CFG level (i.e., nothing but conditional and unconditional gotos). So, how exactly having an explicit goto may hinder code verification?
And there are many benefits in using goto. Pity you failed to notice them in the past 30 years. Chances are, you never implemented a state machine or a threaded code interpreter, and you never generated code from a high level DSL.
|
|
|
|
|
Tools can only get you so far, and they're not suitable for prooving code correctness. So I'm not sure why you brought that up.
As for benefits, I've read and taken part in countless discussions, and not a single example brought up managed to convince me. In every single case there was a suitable alternative using standard control statements. Most of the time the person bringing up either didn't come up with the proper way, or considered the effort of writing 2-5 additional lines of code too much to bear.
Based on that experience I'm convinced that there is always a better alternative. People claiming otherwise are just not sufficiently experienced to see it, or understand the need.
That said, all this assumes you're looking at code where proper coding guidelines and style even makes sense to take care of: if you're just programming away a piece of throw-away-code, then yes, use whatever suits you best and solves the problem.
In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Funny. It was YOU who brought the correctness and verification issue up. I would never imagine mixing it into a goto discussion. Proving code correctness always involves operating on CFG, no matter if it is a manual or automated proof. Your precious structured coding constructs are eliminated long before you can do any useful reasoning about the code.
For a "single example", are you blind?!? Never seen Linux kernel? Then how can you refer to your nearly non-existent "experience"?
Or, take this code and make it better: [^]
I am 100% sure you cannot keep the same performance without goto. Show me that pathetic "better alternative".
modified 12-Nov-13 6:52am.
|
|
|
|
|
Stefan_Lang wrote: Based on that experience I'm convinced that there is always a better
alternative.
Could be. But I don't write code for fun but rather I get paid for it and it is often critical code that I can't spend weeks finding an optimal solution but rather the first one that is good enough goes out the door.
Nor can I refactor millions of lines of code every two weeks every time I figure out a "better" way to do it.
And neither can the guy that is going to maintain my code after I am gone.
Stefan_Lang wrote: People claiming otherwise are just not sufficiently experienced to see it, or
understand the need.
Of course there are always people willing to rationalize that their way is "best" despite the fact that they can't demonstrate that with objective data and often can't even construct a coherent argument as to why it is "best".
And technology rationalizations are often based on nothing but technology while ignoring the realities of delivering software in a business environment.
Stefan_Lang wrote: In actual production code that is going to live through years of maintenance and
adding features, the presumed benefits of goto never outweigh the long term
maintenance problems.
That would of course be an excellent argument if in fact none of the following was true.
- Maintenance was the sole and only driving business requirement.
- The business had a firm enough grasp on process control to be able to quantify maintenance costs.
- The process control was structured enough that it could enforce quality on the entire rest of the enterprise and to such an extent that the trivial cost of infrequent code misuse rose above the most miniscule noise level of maintenance cost. Versus for example, no requirements, poor requirements, unused requirements, invalid requirements, zero architecture, chaotic process management, etc, etc, etc.
|
|
|
|
|
jschell wrote: Nor can I refactor millions of lines of code every two weeks every time I figure out a "better" way to do it.
Agreed, The code I'm working on has quite a few gotos, but I don't have the time to dig through the code and lack the test cases to do a secure refactoring, so they'll remain right there, unless I find the code is broken.jschell wrote: And technology rationalizations are often based on nothing but technology while ignoring the realities of delivering software in a business environment.
Absolutely, the points I've made refer to creating new code, not modifiying existing one to either insert or remove gotos. My point is that you shouldn't use goto in new code, or insert it into existing code where there is no gto yet. I claim that if you see no good or at least equivalent alternative using other language constructs, then maybe you haven't looked hard enough.
I willing to concede that there may be cases where there is a real benefit if using goto over any alternative, but I can't think of an example in C++, as long as you're using a decent compiler with a good optimizer that will translate alternate control statements into gotos anyway.
jschell wrote: That would of course be an excellent argument if in fact none of the following was true.
- Maintenance was the sole and only driving business requirement.
- The business had a firm enough grasp on process control to be able to quantify maintenance costs.
- The process control was structured enough ...
Maintenance doesn't need to be sole requirement and of course never is. But ignoring it would be a falacity, unless your application is supposed to be throw-away code that shouldn't be maintained (and I already said that for that kind of code all bets are off - there's no point in discussing coding guidelines at all
A business not able to quantify and control maintenance cost will soon be out of business, specifically in software development). There's a reason why there are SCRUM, XP, Agile, (R)UP, etc..
Ideally process control should indeed enforce quality on the entire enterprise - that's what they're modelled to achieve! We as software developers should strive to contribute towards that goal and leave the decision whether our efforts result in small or big gains to the project leaders. In my experience, while maintenance cost is considerably lower per year or month compared to development, it is never minuscule, and will add up over time to the point where it is relevant.
Also you shouldn't neglect the time you need to fix a bug: if you need double the time because of sloppy coding, then this may lower your reputation, resulting in less sales. Ask your sales people how much they like that! Of course, at this point you also need to weigh the effect of releasing your product on time, with clean code: if you need too long for that, you may lose market shares to a competitor. However, at this point we're leaving the scope of this discussion
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: but I can't think of an example in C++
Only time I ever saw one was in the code that implemented printf/sprintf which was part of a column in the C/C++ Users Journal. I believe the columnist made the case in the column itself why goto was used and I certainly couldn't find anything wrong with it. And at least at that point in time IO was often a significant bottleneck (and that I knew from personal experience) so slowing it down further wasn't an option.
No others that I was sure of.
Stefan_Lang wrote: Maintenance doesn't need to be sole requirement and of course never is. But ignoring it would be a falacity,
The point however is that the vast majority of development shops the actual cost of maintenance is significant because of other more serious factors. So minor corrections will have no impact.
Stefan_Lang wrote: A business not able to quantify and control maintenance cost
Err...I have worked for and know of even more businesses that do not quantify maintenance costs and do not even attempt to track it. All still in business. They are work under the 'next release' umbrella and even that is often poorly tracked with often the development department seeming to be nothing but a black hole that money gets poured into. I worked a contract one time for a company whose software development department hadn't delivered anything for 18 months and even failed to deliver just the specs for the interface APIs that I was supposed to be working towards for more than 6 months. (Both interesting and scary to write code for an API by guessing what it might do.)
Stefan_Lang wrote: In my experience, while maintenance cost is considerably lower per year or month compared to development, it is never minuscule
My point is that it is not measured and so is unknown. The vast number of places do not even take a minimal approach too tracking what it costs. And there are proven factors that will impact the actual cost far more than code misuse will.
Stefan_Lang wrote: Also you shouldn't neglect the time you need to fix a bug: if you need double the time because of sloppy coding
Yes if it is taking you twice as long to fix every bug because the code has too many gotos that are completely used incorrectly then you should be concerned.
Versus things like poor or non-existent requirements. Or requirements that are literally impossible to implement. Or zero architecture which means that communications between different smaller systems require a multitude of adaptors. Or over architecture where one still needs adaptors because one is trying to circumvent the entirely worthless framework(s) that were 'intended' to make things easier. Or a complete lack of QA.
Stefan_Lang wrote: Ideally process control should indeed enforce quality on the entire enterprise
Ideally process control should do many things. But the industry almost universally, certainly greater than 99%, relies on chaos for their process control. Did, does and will continue to do it despite the proven benefits of real process control. So no point in lamenting what might be.
Some examples of the state at which process control exists in the industry...
At one place I worked the DBA did his coding on the production system. His code existed only in the database. He didn't know what source control was. To be fair though if he broke the production database then he would have been fixing it as well. At another business they used source control religiously. Every time they brought on a new customer they would compile the systems (there were multiple deliverables) then bundle up the BINARIES and check them into source control. And label the binary. Not the source code, just the binaries. At another company they stopped creating formal designs and disbanded the process control group because it was 'confusing' to the developers of the company that had just acquired them. At another company which I interviewed I asked about their source control system during the interview and they stated they were thinking they should start using that and that I could set it up when I started. I have worked at companies that took process control seriously to the extent that they ended up documenting chaos and nothing more. They would codify the chaos and then continue to allow without restriction exceptions at every step of the process for every single project. No change with the newest darling 'Agile' as one goes into every sprint with half finished stories, missing stories, stories that change radically all the while one still faces fixed delivery schedules with fixed business requirements due on dates that are always unachievable.
This is the norm.
And keep in mind that I like process control. I have been evangelizing it for years. And pushed the usage and methods extensively for years. Along with studying the various methods and read extensively about the successes. So it isn't like I don't know what it should look like and what it can do.
|
|
|
|
|
jschell wrote: so slowing it down further wasn't an option
Which implies an alternative implementation would slow it down. Given the level of optimization current compilers can achieve, there is no way to know that for sure short of running actual performance tests.
jschell wrote: actual cost of maintenance is significant because of other more serious factors. So minor corrections will have no impact.
Which assumes that the complications and obfuscations caused by overusing goto always only results in minor complications, or that you can even measure whether it is or not. That does not match my experience: In the cases I've seen goto being used, it considerably increased the time required to understand the code and (if required) fix it. Time is money is maintenance cost. If overall that didn't add up to the majority of the cost this was only true because goto was in fact used rarely.
I don't buy the reasoning that "it doesn't matter what you do in this case because overall it will be neglectable". If everyone lives by that rule, everything you do will be considered neglectable, and nobody will care about the consequences.
jschell wrote: businesses that do not quantify maintenance costs and do not even attempt to track it
All businesses have to add up the numbers at the end of the year. Even if they don't accurately track it (or you just don't see how they do it), they must strive to keep maintenance cost at a minimum.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: That does not match my experience: In the cases I've seen goto being used, it
considerably increased the time required to understand the code and (if
required) fix it
Ok, and was this a place where code reviews occurred? And where code reviews were actual reviews and not just pushing paper (so code was in fact modified based on the review)?
If not, in your opinion, would the quality of the entire code base have been improved if reviews had been in place? If reviews had been in place would goto have been used as much as you saw it used?
|
|
|
|
|
If reviews by todays standards would have been used, then yes, every single one of these gotos would have been eliminated. No exception. And IMHO it would have been a net gain every single time.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: No exception. And IMHO it would have been a net gain every single time.
And presumably other problems would have been corrected as well. Thus one process control process which would have impacted that along with other problems would have eliminated many problems. Yet it wasn't in place. So an example of a chaotic development environment of which the use of goto was very likely a minor problem.
|
|
|
|
|
My point wasn't about process control (or the lack thereof) some unspecified time ago, it was about process control being in place and effective at the time I was working there. I totally agree that 20-30 years ago process control had quite a different quality.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: My point wasn't about process control...
Thought my original post was clear...the culture that leads to the inappropriate use of goto is one that is going to have other problems, including in code, which will be more serious than the use of goto.
|
|
|
|
|
jschell wrote: greater than 99%, relies on chaos for their process control.
That doesn't match my experience. At all. Every company I worked for, was contracted to, or was in contact with as a client used some sort of process control. In many cases mostly through paperwork and manually entering hand-written reports into a database. I know this is quite different in other countries (I lived and worked in germany and switzerland), so you may have a point depending on what country you look at.
But we're going off-topic here: the important point is that goto has an increased risk of causing lower quality pruducts and higher maintenance cost - whether or not your company successfully applies process control shouldn't matter to you - all you can and should do is improve it on the level that you can affect!
As for you're working experience with process control I clearly have been more lucky (sometimes too much so: I do hate SAP!  ). But as stated above: don't let the quality of process control )or lack thereof) in your company sidetrack you from producing high quality code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: Every company I worked for, was contracted to, or was in contact with as a
client used some sort of process control
I have also worked with companies that claimed to use process control. I have however also read a great deal, including actual studies, about processes and real (measured) benefits that companies that are strongly dedicated to process control achieve. And I have never seen much less worked for or with a company that was even close to what was actually possible.
Stefan_Lang wrote: your company successfully applies process control shouldn't matter to you
Again though the point is that such companies have more serious problems.
Stefan_Lang wrote: sidetrack you from producing high quality code
This thread has nothing to do with the code that I produce.
|
|
|
|
|
jschell wrote: I have never [...] worked for [] a company that was even close to what was actually possible.
I have, in the 90s. At first the company did use various processes in their departments with equally varying rates of success. But there was little process control behind it, and few synergies and overall organisation over the whole company.
Then the management pushed to introduce a software ISO certification (which at the time they started didn't even exist - they cooperated with the certificate institute to actually create it). Over the course of about 3-4 years the new company-wide standards and process was in place, and the improvements were huge. It was an eye-opener if I've ever seen one.
Since then I'm a believer in process control, on all levels of a company. It's true that few companies ever reach that level of control I've witnessed back then, but that doesn't mean you should stop trying to improve processes on the levels that you can effect.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: ...ISO certification (which at the time they started didn't even exist - they
cooperated with the certificate institute to actually create it). Over the
course of about 3-4 years the new company-wide standards and process was in
place, and the improvements were huge. It was an eye-opener if I've ever seen
one.
Not surprising to me.
Stefan_Lang wrote: Since then I'm a believer in process control
Great. Doesn't alter what I said however. The vast, vast majority of companies are not ISO certified. Matter of fact it is quite possible that 'fewer' companies seek such certification now as versus when you encountered it. That is very definitely the case for CMM certification. Keep in mind that I am not referring to business domains where those types of certification might be required to get business but rather the entire software industry.
Stefan_Lang wrote: but that doesn't mean you should stop trying to improve processes on the levels
that you can effect.
It does however mean that the overall impact within a company is that it will still remain in the 'chaos' level which means that in most (vast, vast) majority of cases that any attempts will never rise above the noise level.
And AGAIN noting that this has nothing to do with code/designs that I produce but rather it has to do with the overall 'goodness' of the software process and what one can expect in terms of that within a company. One might claim that X is better but everyone else in the company will have their own idea what X is and each will strive to maximize that. And since the industry as a whole can be said to have no real process control consequently, per my original comments, any single version of X is so inconsequential that it is pointless to attempt to suggest that it by itself is significant. Because it isn't significant. What is significant is the lack of complete process control.
|
|
|
|
|
I don't think we need to discuss that the lack of process control is bad, and unless we somehow manage to improve that situation in the company or at least department, then, yes, your own contributions and efforts may be wasted.
I probably was lucky to work in companies that either valued my opinion (on this matter) or already did practice process control at a satisfactory level. I understand that this is the exception rather than the rule: I keep reading studies about the bad rates of success of software projects, hinting at how bad process control is elsewhere.
We seem to be agreeing, generally, it just seems I'm more optimistic about the effect of my efforts. Whether this is justified or just a projection of my generally good experience - time will tell. Until then I wish you a share of my good experiences - if not in your current job, maybe you can find another in a company that actually values process control and your contributions!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: I probably was lucky to work in companies that either valued my opinion (on this
matter) or already did practice process control at a satisfactory level.
Ok, but note that my original point specifically pointed out that if the process control wasn't in place then that is where the problems came from.
And you also said the following in a different sub-thread "But it was nigh impossible to disentangle the mass of conditional code and goto statements (few as there were)... I'm not saying that the goto statements were the sole reason for the sorry, unmaintainable state of the code, but they were the main reason why I was unable to transform it into something maintainable!"
And in the context of that statement it would suggest to me that in that company one of the following would seem to be true.
- There was no process control
- The process control was basically ineffective (regardless of what the employees thought of it.)
- At some point in time those gotos were considered proper and correct. (As for this one then hindsight is not a rational basis to condemn the previous determination.)
And the first two of those conditions is what the vast majority of the industry is in. And if one of the first two then you have experienced at least indirectly what it is like.
|
|
|
|
|
Stephan_Lang wrote:
"The main reason however that you shouldn't use goto is that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions about goto. In all that time I've never heard or read one compelling argument in favor of using it. Yes, you can use it to reduce or avoid nesting, or otherwise reduce the amount of code. But that by itself is not a valid argument in my book."
Over the past 39 years, I've never used a goto in C or C++. I did use the goto in Basic. My first computer only had GWBasic and assembly language.
Some situations where there is a benefit to a using goto are mentioned in Hopkin's 1979 paper, "A Case For The Goto", which I believe was written in response to Dijkstra's paper, "A Case Against The Goto". Even with modern compiler optimizations, the examples in both papers still apply today.
I would, and have, gone to extreme lengths to avoid using a goto, for the reasons you mentioned. Even when I've had to jump out of the center of multiple nested loops, I used an exit-flag and an if-statement with a break after each loop. Still, there is no question that this is a bit slower than using a goto to jump out of the center.
I have coded many real-time Digital Signal Processing algorithms with streaming data. Often these algorithms must be fast enough to keep up with the input data stream. In some cases, I have had to write special assembly code routines for some calculations, otherwise the algorithm couldn't keep up with the input data. Unfortunately, unlike the C language, assembly language isn't portable.
Using a goto is likely to only result in a very small speed increase. I doubt that using a goto is typically justified, if it is ever justified. Still, there can be a benefit to using one, and I acknowledge that there might be some fringe case where, after other necessary algorithm and implementation optimizations have been done, using a goto is warranted. Thus I reject any dogmatic statement to the contrary.
I say, as a general rule, use all possible techniques to avoid using a goto. I've always been able to avoid the goto. You can probably avoid the goto too.
Check out one of the links in my first message in this thread where issue of dogma and the 'goto' is addressed. I also showed a loop construct as a way to avoid using a goto in some situations in that message.
modified 11-Nov-13 23:56pm.
|
|
|
|
|
Threaded OCaml bytecode interpreter is several times faster than the switch-based one. Far from being "a very small speed increase".
|
|
|
|
|
Yes, but I wrote:
"Using a goto is likely to only result in a very small speed increase." (Of course, that is only in specific situations, as listed in the paper I mentioned earlier by Hopkins).
I did not write anything at all to refute what you wrote.
|
|
|
|
|
I may be bordering on dogma, but as I stated above, I've never seen any good C/C++ example where using goto was the better alternative - at best you could argue that it wasn't conceivably worse than using standard control statements.
That's not to say that there aren't examples in favor of goto, in C/C++ or other languages. I just haven't seen any yet.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
