goto statement
-
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 inco
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:
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 inco
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! X| ). 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)
-
jschell: "Not to mention of course that profiling systems is unlikely to substantially increase the speed of the application. The only time it does lead to substantial increases is when it identifies points which were poorly designed or architected in the first place." I have found that profiling the code and subsequently optimizing the code can, in some cases, cause significant speedups even in a well-designed and well-implemented system. However, I don't doubt that it's not desirable to optimize the code in whatever problem domain you worked in. Some things can't be made significantly faster. And, even when code can be sped up a lot, it's not always necessary. Digital filters, which are used in audio codecs, video codecs, imaging, and sometimes graphics, can be sped up dramatically, such as running from 1.5 to 3 times faster, or rarely even faster, by writing specialized assembly routines that use parallel (SIMD) instructions. Modern Intel and AMD processor have wide registers that allow simultaneous multiples and adds of multiple numbers at the same time. These are Single Instruction Multiple Data (SIMD) instructions. Even Intel's parallel compiler cannot handle the special parallel instructions in an optimal fashion in all cases. There's still a need for hand-written assembly code in some cases. The C or C++ code to implement the algorithms is not badly designed. The compiler often can't generate the best code using these SIMD instructions today. Compilers can handle much more than in the past, but they still aren't as good as a person yet for some things. Intel now sells various routines that do mathematical operations, such as a dot-product, and even a modern video codec, and these routines use the SIMD instructions internally, so less SIMD code has to be written today. The routines don't cover all cases though. In a previous job, I wrote code to rotate an color image using bicubic filtering. I then sped up rotating the image on a page by a factor of 1.7 by writing writing specialized assembly code using SSE1 instructions to do part of the calculations. This was only part of the calculations, but that speedup was very significant and resulted in a competitive product. Not all the optimizations that I have done involved writing assembly language. For one audio application, I unrolled a loop and that caused a significant speedup. That does make the code harder to read, but I added comments. In this case, the speedup was critical to the application. For another hypothetical
Bill_Hallahan wrote:
My point is, while most of the time the code I worked on didn't need to be optimized, occasionally I've seen optimization result in significant improvements in performance.
I have not doubt that optimization can make applications significantly faster. However that is different than saying that you managed this only after profiling.
Bill_Hallahan wrote:
Digital filters, which are used in audio codecs, video codecs, imaging, and sometimes graphics, can be sped up dramatically, such as running from 1.5 to 3 times faster, or rarely even faster, by writing specialized assembly routines that use parallel (SIMD)...
Sounds quite reasonable and are you saying that you came across this need, all of it, by profiling the existing application?
-
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?
-
Bill_Hallahan wrote:
My point is, while most of the time the code I worked on didn't need to be optimized, occasionally I've seen optimization result in significant improvements in performance.
I have not doubt that optimization can make applications significantly faster. However that is different than saying that you managed this only after profiling.
Bill_Hallahan wrote:
Digital filters, which are used in audio codecs, video codecs, imaging, and sometimes graphics, can be sped up dramatically, such as running from 1.5 to 3 times faster, or rarely even faster, by writing specialized assembly routines that use parallel (SIMD)...
Sounds quite reasonable and are you saying that you came across this need, all of it, by profiling the existing application?
jsachell wrote: "I have not doubt that optimization can make applications significantly faster. However that is different than saying that you managed this only after profiling." I usually profiled the system, but not always. Sometimes I just timed how long it took to do something. These times, I did know what the bottleneck would be without profiling because it was obvious, even to the casual observer, even without experience and history, both of which I have in this area. For just one such case, in an embedded processor, I was getting data from an Analog to Digital Converter (ADC) using DMA, and then doing millions of calculations per second on the data, and then writing the data to an in-memory buffer, and then the processed data would be written to a Digital To Analog Converter (DAC). I knew that the majority of the time would be spent doing the algorithm that does millions of calculations per second, because the input and output buffering would be many orders of magnitude faster. Sometimes in simple systems, it is obvious what needs to be optimized even without profiling. I do agree with you, in large systems, profiling is needed. Very simple systems can be understood almost completely, particularly when someone is repeatedly implementing similar simple systems.
-
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)
-
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.
-
Why many hate this statement and do not advise using it! I used it when I started programming with BASIC and GWBASIC. It is also found in the C#. Troubles are based on the programmer who is misusing it.
If it was so evil, why is it still there? Mosquitos that spread malaria are around for a reason. Right now, because it causes so many deaths (program crashes?) and suffering (coders finding code difficult to track), we think they're bad. They are there for a reason (keeping human population in check?): all you have to do is figure it out and learn how to respect them (don't create insecticide resistant varieties) and use them properly. If you have nested loops, how would you jump straight out? Have nested routines with exits? Throw pretending that it is not a goto? Set lots of flags and check them every time? longjmps (goto in function form) are just a variant of goto. Why don't you just use a goto instead of wrecking your brain how not to use one. If you don't wish to use gotos (squeezing the toothpaste tube in the middle) you don't have to (roll it from the end). Like a toothpaste tube that may not be squeezed the way you like it, you can choose to live with it or let it annoy you. If it annoys you that much, you could use gotoless languages (tooth powder?) like Bliss or Python.
-
If it was so evil, why is it still there? Mosquitos that spread malaria are around for a reason. Right now, because it causes so many deaths (program crashes?) and suffering (coders finding code difficult to track), we think they're bad. They are there for a reason (keeping human population in check?): all you have to do is figure it out and learn how to respect them (don't create insecticide resistant varieties) and use them properly. If you have nested loops, how would you jump straight out? Have nested routines with exits? Throw pretending that it is not a goto? Set lots of flags and check them every time? longjmps (goto in function form) are just a variant of goto. Why don't you just use a goto instead of wrecking your brain how not to use one. If you don't wish to use gotos (squeezing the toothpaste tube in the middle) you don't have to (roll it from the end). Like a toothpaste tube that may not be squeezed the way you like it, you can choose to live with it or let it annoy you. If it annoys you that much, you could use gotoless languages (tooth powder?) like Bliss or Python.
:)
-
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)
-
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! X| ). 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.
-
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)
-
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.
-
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)
-
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.