DEV Community
·
GOTO语句被认为有害——Go语言需要它吗？
💡
原文英文，约800词，阅读约需3分钟。
📝
内容提要
Dijkstra在1968年的论文中批评了GOTO语句，认为其导致代码混乱。尽管Go语言允许使用GOTO，但官方建议仅在必要时使用，并提供了更好的结构化编程替代方案，如带标签的break和错误处理机制。Dijkstra的观点在今天依然适用，结构化编程是最佳实践。
🎯
关键要点
- Dijkstra在1968年的论文中批评了GOTO语句，认为其导致代码混乱。
- Go语言允许使用GOTO，但官方建议仅在必要时使用。
- Dijkstra的观点在今天依然适用，结构化编程是最佳实践。
- GOTO语句导致代码不可读，调试和维护困难。
- Go语言提供了更好的结构化编程替代方案，如带标签的break和错误处理机制。
- 在特定情况下，GOTO可以简化代码，例如在深层嵌套循环中退出。
- 使用带标签的break语句比GOTO更清晰、更结构化。
- Go语言的错误处理机制使得不需要使用GOTO来减少重复的错误处理代码。
- 尽管GOTO在Go中没有被完全移除，但结构化构造始终优先于GOTO。
- 在使用GOTO之前，应该考虑是否可以使用break、return或defer。
- Dijkstra的见解在现代编程中依然适用，最佳的Go代码遵循结构化编程原则。
❓
延伸问答
Dijkstra对GOTO语句的主要批评是什么？
Dijkstra批评GOTO语句导致代码混乱，形成不可读的“意大利面条代码”。
Go语言中GOTO语句的使用建议是什么？
Go语言允许使用GOTO，但官方建议仅在绝对必要时使用。
在什么情况下GOTO语句可能是有用的？
GOTO语句可以在深层嵌套循环中简化退出逻辑。
Go语言提供了哪些替代GOTO的结构化编程方案？
Go语言提供带标签的break语句和错误处理机制作为GOTO的替代方案。
使用GOTO语句的风险是什么？
使用GOTO可能导致代码不可读，增加调试和维护的难度。
Dijkstra的观点在现代编程中是否仍然适用？
是的，Dijkstra的观点在现代编程中依然适用，结构化编程是最佳实践。
➡️
