编程语言与软件工程2015pixelscommander.com
安全关键代码的开发规则
Rules for Developing Safety Critical Code
入门 · 约 45 分钟读完前置知识：C 语言基础、嵌入式系统基础
导读
这是 NASA 喷气推进实验室（JPL）提出的 C 语言安全关键代码编写规则，涵盖编译警告零容忍、静态分析、函数长度限制、避免复杂控制流等约束，旨在降低嵌入式与航天软件的缺陷率。规则强调简单性优先，例如函数不超过约 60 行、断言不得有副作用等。
HN 关注点：HN 读者长期关注如何写出高可靠代码，讨论焦点集中在这些严格规则是否适用于日常开发，以及函数长度等限制的合理性。
后来怎么样
JPL 的这套 C 语言编码规则（基于 MISRA C 思路扩展）成为安全关键嵌入式开发领域被广泛引用的编码规范范本，常被与 MISRA C 并提，用于航天、汽车等高可靠性软件的代码审查与静态分析实践。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
补充NASA 把 bug 视为流程问题而非个人过错，值得借鉴
关于 NASA 软件开发，最令我印象深刻的一点这里没提到：缺陷至少在原则上不被视为个人的失败，而是整个开发流程的失败。发现问题后，问题不是“谁干的、怎么惩罚”，而是“我们作为团队该怎么做才能让它不再发生”。不知道实际执行如何，但即使在低风险环境下这也听起来是很好的制度。
tgb查看英文原文
The most impressive thing I've read about NASA's software development isn't mentioned here. It was the system where bugs and defects were (at least in principle) not treated as the failing of an individual but rather as a failing of the entire development process. So when a problem is found, the question isn't "Who did this and how can we punish them?" it's "What can we as a team do so that this never happens again?" I don't know how this works in practice, but it sounds like a great system even when dealing with code in a lower-risk setting.
亲历亲历：长期运行才暴露的依赖 bug 险些变砖产品，看门狗也不保险
补充一条规则：不要发布你无法测试的行为，包括有状态系统长时间运行后的行为。我曾花多个周末和深夜修一个 bug，若发布出去最终会把嵌入式产品变砖——软件会以躲过所有看门狗和复位定时器的方式挂起，仅靠数周压力测试的边缘才勉强抓到。结果 bug 不在我写的代码里，而在一个开源依赖中。应对方法包括长时间测试、加速模拟时间的测试框架、定期重启，以及软硬件看门狗；但看门狗并非万无一失——我的例子里主 I/O 循环还在跑，但关键协议栈已失效。
_iyig查看英文原文
I'll add another rule: don't ship behavior you can't test. This includes the behavior of a stateful system after an extended period of uptime. I once spent weekends and late nights fixing a bug which, if it had shipped, would have eventually bricked an embedded product. It caused the software to hang in a way which evaded every watchdog and reset timer. This bug was only barely caught by the edge of a multi-week stress test. As it turned out, the bug itself wasn't in any of the code I had written, but in an open-source dependency. There are several ways to approach this problem. Besides simply testing your product over an extended period of time, you can build a test harness which simulates time at an accelerated rate. Another method is to periodically reboot your system from scratch after the longest period of uptime you're able or willing to test. It also helps to use software and hardware watchdogs which automatically reset your system, in whole or in part, if it becomes unresponsive (fails to "feed" the watchdog). However, watchdogs by themselves aren't foolproof - in my case, the program's main I/O loop kept running, but a critical part of the stack no longer functioned correctly.
支持力挺零警告规则，吐槽现实中普遍无视编译警告
“所有代码从开发第一天起就要以最严格的警告设置编译，且零警告；每天用至少一种先进静态分析器检查并零警告通过。”我太沮丧了，周围到处是无视警告的做法。我业余时间都在工作里消除警告、删掉没注释的 @SuppressWarnings。一句话：KISS（保持简单）。
jordanpg查看英文原文
> All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings. Wow, am I ever frustrated by the summary ignoring of warnings I see going on around me. I spend my spare time at work making warnings go away and deleting uncommented @SupressWarnings from our codebase. In a word, KISS. Another engineer designing critical systems for the US government coined that one, apparently [1]. [1] http://en.wikipedia.org/wiki/KISS_principle
质疑对比 Ruby 社区 5 行方法规则，质疑 60 行限制是否过松
“函数不应超过一张纸能打印的长度，通常约 60 行。”可能因为 C 更底层，这些限制比高级语言讨论的宽松得多。对比 Sandi Metz 的 Ruby 规则：类不超过 100 行，方法不超过 5 行。从 5 行到 60 行差距很大。我认同 Sandi：更小的单一职责函数带来更低耦合、更易维护的代码。60 行到 5 行只是思想演进吗？哪个更好？如何解释这种差异？
evolve2k查看英文原文
> No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function. Maybe it’s because C is a lower level language but for me these limits seem much looser than is discussed in higher order languages, specifically for me ruby. Take Sandi Metz rules for practical object oriented [quality] code. https://thoughtbot.com/blog/sandi-metz-rules-for-developers 1. Classes can be no longer than one hundred lines of code. 2. Methods(functions) can be no longer than five lines of code. Its a long way from a 5 line constraint to a 60 line constraint. I agree with Sandi that smaller ‘single purpose’ functions lead to less coupled, easier to maintain code. Is 60 down to 5 lines just about a progression of thought, with 60 lines being more what used to be acceptable and is possibly still acceptable with ‘older languages’? Is one better than the other? How to explain the difference?
历次讨论
- 2015Hacker News 讨论帖171 分 · 76 评
- 2019Hacker News 讨论帖143 分 · 44 评
同领域还值得读
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 分钟编辑精选