goto statement
-
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.