I want to tell you why I resist rules in general. Magazine articles love "TheFive Ways to Avoid Violence." And you memorize these things and imagine that byrote somehow they will apply to your situation, but they won't. They won'treliably do so.
Gavin de Becker on personal safetyInterview with Sam Harris
Many programmers are surprised to find out that the goto statement is stillwidely used in modern, high-quality codebases. Here are some examples, using thefirst codebases that come to mind:
| Repo | goto usages | ratio to continue |
|---|---|---|
| Linux kernel | 150k | 6.27 |
| .net CLR | 5k | 2.13 |
| git | 960 | 0.76 |
| Python runtime | 5k | 16.9 |
| Redis | 554 | 2.14 |
The ratio to usages of the continue keyword is provided to normalize for linesof code and the prevalence of loops in the code. This is not limited to C codebases. Lucene.net for example has 1,511 goto usagesand a ratio of 3 goto usages to each continue usage. The C# compiler,written itself in C#, clocks in at 297 goto usages and 0.22 ratio.
People who take "goto is evil" as dogma will point out that each of these usagescould be rewritten as gotoless alternatives. And that's true, of course. But itwill come at a price: duplication of code, introduction of flags, severalif statements, and overall added complexity. These are highly reviewedcodebases written by talented people. When they use goto, it's because theyfind it to be the simplest approach.
This is exactly how dogma hurts software development. We take a sensible rulethat works most of the time and promote it to sacred edict, deeming violators asinferior programmers, producers of unclean code. Thus something that would havebeen a helpful guideline becomes a hard constraint. Pile up enough of these,and code that could have been simple ends up in a tangled mess, all in the nameof "purity."
We have a long tradition of dogmas, but goto is the seminal example, denouncedin Edsger Dijkstra's famous letter, Go To Statement Considered Harmful. Justbarely over a page, it's a good case study. The letter is good advice in thevast majority of cases: misuse of goto will quickly land you in a maze oftwisty little passages, all alike. Less helpful were the creation of a socialtaboo (goto is the province of inferior programmers) and the absolutist callsfor abolition. Dijkstra himself came to regret how "others were makinga religion" out of his position, as quoted in Donald Knuth's more level-headedpaper, Structured Programming with go to Statements.
Taboos tend to accrete over time. For example, overzealous object-orienteddesign has produced a lot of lasagna code (too many layers) and a tendencytowards overly complex designs. Chasing semantic markup purity, we sometimesresorted to hideous and even unreliable CSS hacks when much simpler solutionswere available in HTML. Now, with microservices, people sometimes break upa trivial app into a hard-to-follow spiderweb of components. Again, these arecases of people taking a valuable guideline for an end in itself. Always keepa hard-nosed pragmatic aim at the real goals: simplicity, clarity, generality.
When Linus Torvalds started the Linux kernel in 1991, the dogma was that"monolithic" kernels were obsolete and that microkernels, a message-passingalternative analogous to microservices, were the only way to build a new OS.GNU had been working on microkernel designs since 1986. Torvalds, a pragmatistif there was ever one, tossed out this orthodoxy to build Linux using the muchsimpler monolithic design. Seems to have worked out.
Every programmer pays lip service to simplicity. But when push comes to shove,most will readily give up simplicity to satisfy dogma. We should be willing tobreak generic rules when the circumstances call for it. Keep it simple.
Article Link: Goto and the folly of dogma | Many But Finite