编程与软件工程lysator.liu.se编辑精选
Rob Pike：C 编程笔记（1989）
Notes on Programming in C – Rob Pike (1989)
2010 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Rob Pike 1989 年关于 C 编程风格的笔记，列出一组简洁规则，涉及数据结构、算法表达、头文件包含、命名与复杂度控制。文中“数据主导”等观点被评论反复引用。
为什么经久不衰：规则虽写于 C 时代，但数据优先、把复杂度移到数据等洞见跨越语言和年代，今天仍值得对照。
HN 评论精选
赞同数据主导原则，认为代码最终是为处理数据服务，并支持头文件不互相包含。
“规则 5：数据主导。如果你选对了数据结构并把东西组织好，算法几乎总是自明的。编程的核心是数据结构，而不是算法。”我过了一段时间也得出同样结论。归根结底代码就是用来处理数据的。“简单规则：include 文件永远不应包含 include 文件。”太同意了！
gens查看英文原文
>Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be selfevident. Data structures, not algorithms, are central to programming. (See Brooks p. 102.) I came to the same conclusion, after a while. In the end code is there to process data. (there is meta programming and things like state machines but most programs do hold data in some kind of structures to be processed) >Simple rule: include files should never include include files. Yes, please!
反对原文的外部 include guard 建议，指出现代编译器优化，MSVC 例外，偏好 pragma once。
大部分建议仍成立，但有一条可以放心忽略：不要用外部 include guard 把代码弄丑——把 include guard 放在被包含文件里。现代编译器会做 include guard 优化。有一个例外仍成立：MSVC 没有正确做这个优化，也许是因为它偏爱预编译头。我个人更喜欢 pragma once，因为 include guard 重名风险比同一文件通过不同硬链接或副本可访问的风险更高，而且可读性更好。
unscaled查看英文原文
Most of the advice holds true, but there's one bit you should happily ignore: don't uglify your code with external include guards - that is put your include guards in the included file. Modern compilers perform include guard optimization: http://www.bobarcher.org/software/include/results.html There is one exception to this rule which I think still holds true: MSVC doesn't perform this optimization correctly, perhaps due to its love affair with precompiled headers. I personally prefer solving that issue with pragma once, as I find the risk of having an include guard name clash higher than the chance of having two the same file accessible between to different hardlinks or copies, let alone compiling anything on network share. It's also a lot more readable.
强调“把复杂度移到数据”的实用价值，并举数据库列替换 if 语句的例子。
这位资深程序员给了很多好建议。我以前就收藏过这些笔记，因为他简单有效的技巧让我有共鸣。文中说：“算法，或算法的细节，常常可以紧凑、高效且富有表达力地编码为数据，而不是一堆 if 语句。”我在别处读到过把代码复杂度转移到数据上，但很难找到相关讨论。我发现它确实成立。把细节从 PHP 移到数据库会让整体代码更短。第一个想到的例子是用数据库里的一个或多个列（比如某种分类）替换一堆 if 语句。
combatentropy查看英文原文
Lots of good advice from a long-time programmer (https://en.wikipedia.org/wiki/Rob_Pike). I have bookmarked these notes before, because his simple but effective tips resonate with me. From the article: > Algorithms, or details of algorithms, can often be encoded compactly, efficiently and expressively as data rather than, say, as lots of if statements. I have read elsewhere about moving your code complexity to your data. But I can't find that other article. It's hard to find mention at all of this strategy. But I have found it to be true. Moving details from PHP into the database results in shorter code overall. The first example that comes to mind is replacing a bunch of if-statements with one or more columns in the database, like for some kind of categorization.
规则 5 在现代库和强类型下仍有效；更愿用成熟库承担复杂度，而非手写简单实现；并指出与 Go 设计的反讽。
这些内容今天看仍有启发。当然要记得是 1989 年的，但事后回看……我很喜欢规则 5，尤其是结合 STL 和强类型时。考虑到 Go 的设计，从 Pike 这里得到这条建议有点讽刺。很多关于复杂度的材料假设你从零手写。只要明白自己在做什么，我愿意接受设计良好的库带来的复杂度，而不是从零构建“简单健壮”的东西。二叉树与伸展树的说法很有说明性；除非我需要重新看清裸数据结构，否则我更愿意用 STL，复杂与否都行。
glangdale查看英文原文
These are instructive to look at now. Important to recall the '1989' date of course, but with hindsight... I love Rule 5 ("choose the right data structures and the algorithms will almost always be self-evident"), especially when combined with STL and strong typing. There is a degree of irony in taking this advice from Pike, given the design of Go. Much of the material on complexity assumes you are hand-coding things from scratch. I am happy to take on complexity (as long as I understand what I'm getting into) from well-designed libraries rather than building something "simple and robust" from scratch. The statement about binary trees vs splay trees is illustrative; unless I need to see the bare data structure again I would much rather take on something from the STL, complex or otherwise.
历次讨论
同类还值得读
开源应用架构
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编辑精选