编程与软件工程github.com
Kernighan 定律：你并没有聪明到能调试它
Kernighan's Law: You are not smart enough to debug it
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 GitHub 上 dwmkerr/hacker-laws 仓库中的一页，收录了编程与软件开发领域流传的各种“定律”和经验法则，Kernighan's Law 是其中一条。它的原意是：调试的难度是写代码的两倍，所以如果你把代码写得尽可能聪明，那你按定义就不够聪明去调试它。这条定律提醒开发者：别为了炫技而牺牲代码的简单与可读。
为什么经久不衰：它把散落在演讲、社区和日常对话里的编程智慧汇成一份随时可查的清单，而 Kernighan 那句自嘲式的警告，至今仍是对抗“聪明代码”最有力的提醒之一。
HN 评论精选
Dijkstra 早在 1972 年就警告过聪明技巧的危害，与 Kernighan's Law 一脉相承。
“称职的程序员完全清楚自己脑袋的容量有限；因此他以充分的谦逊对待编程任务，并且像躲避瘟疫一样避免耍聪明。”——EWD 340（Dijkstra《谦逊的程序员》，1972 年图灵奖演讲）
edejong查看英文原文
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. " - EWD 340 [1] [1] E.W. Dijkstra - The Humble Programmer, ACM Turing Lecture 1972 (https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)
聪明不等于工程能力，炫技代码往往不可维护；作者已从追求 clever 转向追求可读。
这让我想起科学家写的典型代码。恕我直言，原始智力与软件工程技能（包括良好实践）之间存在巨大鸿沟。结果大多数代码变成代码高尔夫式的精巧装置，别人（包括未来的自己）都看不懂。免责声明：我以前就是那种喜欢“聪明 hack”的人，现在尽量让代码首先可读，很大程度上得益于 Python 哲学。
stared查看英文原文
It reminds me of a typical code written by scientists. IMHO there is the biggest gap between the raw intelligence and software engineering skills (including good practices). So, it means that most of the code ends up as code-golf-style contraptions, incomprehensible for anyone else (including their future themselves). Full disclaimer: I used to be that guy who liked "clever hacks". Now I try to make code readable in the first place (largely thanks to Python philosophy).
借自编定律的幽默指出日期格式化这类顽固问题至今未解，并给出实用建议。
20 多年前，我的一位工程师说总有一天会有“Moyer 定律”。我觉得有趣，就自己编了一个：Moyer 定律——“当我们终于能从任何电脑一致地打印到任何打印机时，就不会再有待解决的 CS 问题了。”推论——“打印出来的日期仍然会是错的。”PDF 让我们更接近通用打印，但日期转换和格式化至今仍是难题（建议 JSON 里的日期时间用 UTC ISO-8601 或 RFC3339）。
smoyer查看英文原文
Over 20 years ago, after I had devised a way to use Gray Code to embed a clock into a signal without increasing the signal's modulated bandwidth, one of my engineers said that someday there'd be a "Moyer's Law". I thought that was funny, so I created one myself: Moyer's Law: "When we can finally print from any computer to any printer consistently, there will be no CS problems left to solve." Since every good law has a corollary, I created one of those too (simply to be funnier): The Corollary to Moyer's Law: "The printed dates will still be wrong." While PDFs have brought us closer to "universal printing", I won't claim we're anywhere close to solving all CS problems. Sadly, date conversion and formatting continue to be problems (hint, consider UTC ISO-8601 or RFC3339 dates/times for the JSON representation). P.S. I don't actually think I'm smart enough to have a law named after me ... nor have I really contributed enough to "our art". - https://en.wikipedia.org/wiki/Gray_code - https://www.electronics-notes.com/articles/radio/modulation/frequency-modulation-fm-sidebands-bandwidth.php
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选