The goto statement is one of the most obscure statements in C and C++.
This could be due to the fact that not a lot of tutorials and books teach about it. But mainly it's due to the mishandling of the goto statement by our ancestor programmers.
This all began when C language had just gained traction. Many assembly programmers hopped on to the C ride and began building complicated programs with the goto statement in C which was more familiar to the goto statement in assembly.
goto statement works in such a way that it tells your program to execute the section of code that the goto statement points to. This statement may be with in any scope of the code being executed.
The goto statement represents how the CPU actually performs some of it's execution, hence it's more close to the machine.
However, due to the mishandling of the goto statement by our ancestor assembly programmers, goto was generally shunned by the developer community and it's currently considered bad coding practice to use it.
But it doesn't have to be that way. In fact all the C and C++ compilers in existence support it anyway, so why not use it. We just have to provide Standard means on how to use them.
First, among the confusing things done by the ancestor programmers was to declare labels within other functions and have goto statements point to them. This was generally confusing because the function declares it's own local scope, so having another function point to that functions scope was confusing. Mostly because it was hard to find where the goto statement was actually pointing to.
So generally it would be better to make all labels as globally scoped.
Secondly, the labels themselves should have a standard notation. Pointers in C and C++ are written with _ptr as a suffix and it's a generally accepted notation. Labels can also be written with a _lab suffix to denote that it's a label, for example endProcess_lab could be a label for a section of code that closes a process when an error is encountered.
I can give many reasons as to why goto statement should return, but it would make this article longer and more tedious to read than it already is.
It's just a polite suggestion to the developer community that I hope shall be put into consideration.
Top comments (0)