编程语言与软件工程2013two-sdg.demon.co.uk
极简主义：少写代码的实用指南
Minimalism: Practical Guide to Writing Less Code (2002)
入门 · 约 30 分钟读完前置知识：基本编程经验、常见面向对象语言（Java/C++）基础
导读
这是一篇 2002 年的论文《Minimalism: Practical Guide to Writing Less Code》，探讨如何通过“少写代码”来提升软件质量。文中给出了一系列实用建议，例如只包含真正需要的内容（避免过度设计）、将重复代码视为错误、谨慎使用 return/continue/break 等控制流语句等。
HN 关注点：这些 20 年前的“极简主义”编程建议在今天是否仍然适用，以及其中哪些观点（如单一返回点、过早 DRY）与现代实践相冲突。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 2
质疑过早 DRY 是万恶之源，应遵循三次法则
“把重复代码视为错误”——我部分不同意。我见过一些最糟糕的代码，正是为了消除重复而写出来的。尤其是在 UI 代码中，很容易误判重复，过早地构建 DRY 方案。过早 DRY 是万恶之源。我遵循“三次法则”，即使如此，也比年轻时谨慎得多。
christophilus查看英文原文
> Consider duplicate code to be a mistake I partially disagree. Some of the worst code I’ve seen was an attempt to reduce duplication. It’s easy, especially in UI code, to mistakenly identify duplicate code, and prematurely build a DRY “solution”. Premature DRY is the root of much evil. I try to follow the rule of three before trying to identify duplication. Even then, I’ve become much more cautious than in my younger days.
质疑反对单一返回点，支持尽早返回
我强烈反对“函数应少用 return、应节制使用”的说法。我认为尽早返回的代码才是最好的，单一返回点是非常过时的观念。我更担心的是看到毫无理由的十层缩进。对 continue 和 break 的建议同样很糟糕。其他建议倒还不错。
Kaveren查看英文原文
I vehemently disagree with the idea that returning from a function often is bad and that it should be used "sparingly". I find that code that returns as early as possible is the best. The idea of a nearly mandatory single return point is a very antiquated notion. I'm much more concerned when I see ten levels of indentation for no good reason. Likewise with continue and break. I think this advice is very bad. All the other recommendations seemed fine.
补充如何在不完全理解问题的情况下避免过度设计？
建议 2“只包含你需要的”引用了控制反转原则，但还可以扩展到更多方面。我想讨论的是：如何避免对尚未完全理解的问题过度设计？除非你在 NASA 工作，否则不到需要时你不会真正知道自己需要什么。这里的程序员们是如何应对意外情况的？
Dowwie查看英文原文
"Recommendation 2: Include Only What You Need" The slide refers to the inversion of control principle but can easily include other important aspects of including only what is needed. I would like to expand on this for discussion. Consider the challenges of not over-engineering solutions to problems you and others don't fully understand, yet. Unless you work for NASA, you won't fully know what you need until you need it. How do programmers here account for the unexpected?
支持只写解决当前问题所需的代码
少写代码的主要法则：只写解决当前实际问题所需的代码。为未来的问题写代码没问题，但过于追求通用性往往会撑大代码库并引入 bug。
taeric查看英文原文
Main rule for writing less code: only write the code you need to solve the actual problem you have. It is fine to write towards future problems, but all to often trying to be generic explodes the codebase and leads to bugs.
补充2002 年的指南针对的是冗长的 Java/C++，世界该向前走了
有点讽刺的是，这份 2002 年的极简主义指南，从用词看显然是针对 Java 或 C++ 这类以冗长著称的语言。我更希望看到关于 Clojure 的无锁并发、Go 强制组合优于继承等新语言特性的讨论。看一份处理上世纪九十年代末问题的 2002 年演示文稿固然有趣，但世界该向前走了。
martinced查看英文原文
It's kinda ironic that a guide to minimalism, written in 2002, obviously has in mind a language like Java or C++ (the vocabulary used makes it crystal clear)... Languages which are not exactly known for their lack of verboseness ; ) I know that for many here Java/C++/C# + ORM + XML + SQL is "The one true way of life"... But I moved on: I do really believe pg's point about "Beating the average" and trying to "think outside the (Java/C# ORM XML SQL) box"... For example, I'd personally much rather see posted and upvoted recent writings about languages offering, say, lockless concurrency (Clojure) or specifically preventing "type inheritance" (hence forcing you to use composition instead of inheritance) (Go), etc. I mean, it's cute to see a 2002 presentation about ways to deal with late nineties issues but honestly I think the world should start to move on. I don't doubt there are a lot of older codebase around that would benefit from this but what about people would start to use HN to try to move the world forward?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2013Hacker News 讨论帖19 分 · 3 评
- 2019Hacker News 讨论帖223 分 · 116 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选