职业与工作方法steve-yegge.blogspot.com
一个菜鸟的画像
Portrait of a N00b
2008 — 2011，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Steve Yegge 的经典博文，通过对比两段风格迥异的代码（一段注释详尽、一段紧凑密集），探讨什么是真正优秀的代码，并尖锐地批评了 Java 社区的过度建模文化和新手程序员的种种习惯。文中对静态类型语言（如 Haskell、OCaml）的评论也引发了长期争论。
为什么经久不衰：它触及了注释密度、代码可读性、静态类型等永恒争议，每次重发都能引发激烈讨论，是检验自己代码观的绝佳镜子。
HN 评论精选
注释的价值取决于内容而非数量，PostgreSQL 是注释良好的典范
我的第一反应是：“天哪，我是个菜鸟！”第二反应是：“不，我只是不同意他的观点。”代码注释是有价值的——用“计数器加一”来注释显然很傻，但注释“这里不加锁也可以安全递增，因为调用方已经加了锁”就非常有用。我见过最漂亮的代码库是 PostgreSQL，它的注释密度相当高。你会说这些代码是两岁小孩写的吗？还是说它出自一个负责任的成年人之手，愿意为后来者省去大量抓头的时间？
wulczer查看英文原文
My first thought was: "oh my God, I'm a n00b!" My second thought was: "no, I just think I disagree with him". Comments in the code are good. They help the next person that touches that particular part of the project understand why it's coded as is and why it wouldn't be a good idea to code it differently. Commenting a counter increment with "increment the counter" is silly. Commenting it with "it's safe to increment it without taking locks, because the caller already took them" is useful. The most beautiful codebase I've ever seen is PostgreSQL and the comment density in its source tree is quite big. Take a look at https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L789 Would you say that this code has been written by a two-year-old? Or rather that it's been written by a responsible adult that cared about the integrity of future coders' tonsures and wanted to save them some heavy head-scratching?
好的代码应在过度注释和过度紧凑之间找到清晰这个中间点
两个例子对我来说都不及格。我追求的是中间地带：代码要清晰，不只对我，而是对任何将来要碰这些代码的人。第一个例子注释太多，把仅有的代码都淹没了；第二个太密集，必须缓慢仔细地读才能理解。写代码时我有充裕的时间，但调试紧急 bug 的人没有。我写代码时始终记住三点：1) 调试比写代码难，如果你写代码时耍了聪明，说明你还没聪明到能调试它；2) UNIX 哲学——把一件事做好；3) 用海明威风格写代码和注释——不用晦涩的语言，只说必须说的。
buro9查看英文原文
Both fail for me. There's a middle ground I aspire to. All I want from code is clarity. Not just for me, but for anyone who has to touch the code in the future. The first is so verbose in comments that you don't see the little code there is. And you couldn't see all the necessary code on the screen. The second (now) is so dense that you have to read the code carefully and slowly to understand what it's doing. I have the luxury of time when writing code, I can consider it and lay it out however I want, comment it how I want. To a person fighting a critical bug they lack this luxury. It's my job when I create code to help the person debugging it (even if it's me) to understand the code as quick as possible so that they may find and solve the problem as soon as possible. Three things I always remember when I code and design software: 1) Debugging is harder than writing code, so if you've been clever in writing code you are by definition not clever enough to debug it. 2) UNIX philosophy... do one thing well. 3) Write both the code and comments in a Hemingway style. Use no obscure language, keep it in layman's terms... but say only what you need to say.
即使是专家写的紧凑代码，如果难以验证正确性也不是好代码
Yegge 说新手不喜欢他的第二个例子，但我靠维护 Lisp 编译器拿了几十年经验者的薪水，我也不喜欢：那段“压缩”代码不算糟糕，但绝不是好例子。专家应该把事情讲清楚，哪怕只对其他专家而言。那个函数太长、可变变量太多，我盯着控制流看了一分多钟才确信它是对的。深度嵌套且带可变变量的 Lisp 函数往往藏着微妙的 bug。相比之下，Yacc 或 Parsec 写的解析器虽然需要专门知识，但一旦掌握就清晰明了，代码结构直接映射问题结构。
ekidd查看英文原文
Yegge says that novices don't like his second example. But I've been paid to maintain compilers written in Lisp, by people who've hacked in Lisp for decades, and I don't like it either: The "compressed" code example is not awful, but it's not a good example. An expert should make things clear, even if only to other experts. Basically, that function is too big, and it uses too many mutable variables. I had to stare at the control flow for 'destructuring' and 'init' for over a minute before I convinced myself that it actually worked correctly. More often than not, a deeply nested Lisp function with mutable variables will contain subtle bugs. So when I see something like this, I need to slow way down and take nothing on trust. Here are two ultra-compressed parsers that I like better than Yegge's: https://gist.github.com/1068185 and http://book.realworldhaskell.org/read/using-parsec.html To understand these, you'll need some specialized knowledge. But once you understand Yacc (or Parsec), this code is straightforward and clear. The structure of the code mimics the structure of the problem.
Yegge 对 OCaml 的批评有误，ML 的类型推断正是为了减少建模负担
他说 Java 是害怕干真活的“数据建模”极客的避风港，写一堆 getter/setter 确实感觉像在工作，这点很对。但他把 OCaml 放在“强迫你给一切建模”的极端一端就错了：OCaml 是 ML 方言，ML 恰恰相反——它推断所有类型，类型标注是可选的。你通过类型推断就能享受健全类型系统的全部好处，而它正是专门设计来减轻程序员负担的。
jluxenberg查看英文原文
He's spot-on about Java being a safe-haven for "data modeling" geeks who are afraid of doing real work. Writing a whole bunch of getters and setters in a freshly minted Java class certainly feels like work. However, I think he gets it wrong when he puts OCaml on the extreme "for you to model everything" end of the spectrum: And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success Hold on a minute...last time I checked OCaml was a dialect of ML. ML does not ask you to "statically" type everything, in fact it does the opposite. It infers all the types. Sure, it allows you to hint types to the compiler, but this is not necessary. You get all the benefits of "static" type checking through ML's concept of type inference. It's designed specifically to make it less work for the programmer to enjoy the benefits of a sound, correct type system. If you want to learn more about type inference in ML, check out this short introduction: http://bit.ly/8WEhD8
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com