Visual Studio Gets Achievements, Badges, Leaderboards
bonch writes "Microsoft has introduced a gamification plugin for Visual Studio that lets users win achievements and badges as they compete on leaderboards by writing code. The full list of achievements includes gems like 'Go To Hell' for using goto, and 'Potty Mouth' for using five different curses in one file. This is another example of Gamification, one of the latest trends to hit social media."
Was why GOTO is a bad idea every explained to you?
The honest fact is that, if you go low level enough, it (equivalent) is the only method of not proceeding to the next instruction, so you'd think that it would make sense to have it in all the higher languages.
However, the difference there is each label is (generally) only used once, and the state of all registers will be the same before and after. The problem with goto is that it requires the compiler to work out the meaning of all the variables at the point it jumps to, and to deal with loading those all into memory as part of the jump operation. At least with breaking out of a loop, you're going to be in the same scope as leaving it through the loop's condition becoming false. Returning from that context will move up (or, if you view things the other way, down) a scope, which is reasonable to deal with
GOTOs, on the other hand, used to allow jumps into noticeably different scopes, where variable contexts could lead to information not having the right meaning. And, that's where the raptors break through.
[citations needed]
Judicious use of GOTO can dramatically simplify resource cleanup when exception handling is not supported. A function that must grab N resources in order (and free them in reverse order on success or failure) requires N nested blocks if you don't use GOTO (and no nesting if you do use GOTO). Often the only way to refactor such logic into sub-functions is by using continuation passing style, which is clear as mud.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Citations won't be found, because the explanation is incorrect. There is no technical issue with compilers implementing 'goto' so long as the destination is in the same lexical scope (C has this limitation). Nor is it worth considering execution context at the level of the CPU, as any high-level loop or branch instruction must be translated into one of a limited number of conditional or non-conditional, relative or absolute jumps. Ultimately whether you use 'goto' or some other control construct you are attempting to express the same programmatic flow, and the compiled instruction stream will be sufficiently similar that it's not worth splitting hairs over.
The reason 'goto' is "considered harmful" is because structured programming theorizes that any computable function can be expressed by combining simpler programs using sequence, selection and iteration; and this provides the opportunity for a constructive approach to program correctness. Dijkstra argues that we are cognitively limited and can benefit from code that is structured so that we can tell at any point where we are and where we have come from (a gross paraphrasing of what Dijkstra calls "coordinates"). But "[t]he unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress". In other words careless use of 'goto' makes it hard to reason about your code.
Knuth contended that one could created structured programs with 'goto' statements, and provided examples of how 'goto' make the program more elegant.
It is important to realise that the claimed advantages of structured programming are undone by the use of break, continue, or exception handling. There are limited forms of goto, and using them prevents proofs of correctness (under the assumptions of structured programming; other techniques may be available) and reasoning using Dijkstra's "coordinates".
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net