![Parents Threatened To Email A Business Partner And Get Them To Stop Working With Me [closed]](https://cdn.sstatic.net/Sites/workplace/Img/apple-touch-icon@2.png?v=d39b333f5c58)
![[Tutorial] Chapter 4: Task and Comment Plugins](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Ffl10oejjhn82dwrsm2n2.png)
_Porntep_Lueangon_Alamy.jpg?#)
Go To Statement Considered Harmful – Does Go Need It?
Introduction: A 55-Year-Old Debate in Modern Go In 1968, Edsger Dijkstra wrote the now-famous article “Go To Statement Considered Harmful” in the Communications of the ACM. It was a short but powerful critique of the GOTO statement, arguing that it leads to unstructured and unreadable "spaghetti code." His ideas shaped modern programming, paving the way for structured programming paradigms that we rely on today. Fast-forward to today, and we have Go (Golang)—a modern, concise, and efficient language designed for simplicity and performance. And guess what? Go still has goto. But should we use it? Does Dijkstra’s argument still apply to a language designed half a century later? What Was Dijkstra's Problem with GOTO? Before structured programming, most languages (like Fortran and Assembly) heavily relied on GOTO for control flow. This led to chaotic jumps in execution, making debugging and maintenance a nightmare. Spaghetti Code in Action Here’s a simple example of unstructured GOTO usage in Go: package main import "fmt" func main() { num := 7 if num%2 == 0 { goto even } else { goto odd } even: fmt.Println("Even number") return odd: fmt.Println("Odd number") }
Introduction: A 55-Year-Old Debate in Modern Go
In 1968, Edsger Dijkstra wrote the now-famous article “Go To Statement Considered Harmful” in the Communications of the ACM.
It was a short but powerful critique of the GOTO statement, arguing that it leads to unstructured and unreadable "spaghetti code." His ideas shaped modern programming, paving the way for structured programming paradigms that we rely on today.
Fast-forward to today, and we have Go (Golang)—a modern, concise, and efficient language designed for simplicity and performance. And guess what? Go still has goto.
But should we use it? Does Dijkstra’s argument still apply to a language designed half a century later?
What Was Dijkstra's Problem with GOTO?
Before structured programming, most languages (like Fortran and Assembly) heavily relied on GOTO for control flow. This led to chaotic jumps in execution, making debugging and maintenance a nightmare.
Spaghetti Code in Action
Here’s a simple example of unstructured GOTO usage in Go:
package main
import "fmt"
func main() {
num := 7
if num%2 == 0 {
goto even
} else {
goto odd
}
even:
fmt.Println("Even number")
return
odd:
fmt.Println("Odd number")
}
