编程与软件工程lars-lab.jpl.nasa.gov
JPL C 语言编程规范（2009）[PDF]
JPL Institutional Coding Standard for the C Programming Language (2009) [pdf]
2012 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这份 PDF 是 JPL（喷气推进实验室）面向 C 语言的机构编码标准，为安全关键和嵌入式软件列出强制规则与理由。评论提到它要求静态分析零警告、禁止 goto/setjmp/longjmp、限制动态内存，以及用括号显式表达求值顺序等严格条款。
为什么经久不衰：它把安全关键 C 的严格规则和可静态检查性讲得很具体，既是嵌入式编码范本，也持续引发关于 goto、动态内存等取舍的讨论。
HN 评论精选
标准严格且切中真实事故，预处理指令规则能防止隐蔽灾难。
用最先进的静态分析工具跑一遍而没有任何警告？这非常严格。还有第 23 条规则：所有 #else、#elif 和 #endif 预处理指令都必须与相关的 #if 或 #ifdef 位于同一文件。我从没想到有人会不这么做，但这确实很该禁止。（我曾在一个 include 文件末尾忘了闭合 C 风格注释。因为它是最后一个 include 文件，C 文件接下来几行被注释掉了——恰好是 main() 函数名和左花括号。于是 main() 剩余部分被当成文件级变量声明，直到实际代码处才报错。我因此收到 1800 个编译错误……）
AnimalMuppet查看英文原文
Run through a state-of-the-art static analysis tool with no warnings? That's seriously stringent. And then, rule 23: "All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related." It never even occurred to me that anyone might do otherwise, but yeah, that's a real good thing to forbid. (I once failed to close a C-style comment at the end of an include file. It was the last include file, so the next couple of lines in the C file were commented out - which happened to be the main() function name and the opening curly brace. It then treated the rest of main() as file-level variable declarations, which was fine until we got to the actual code. I got 1800 compiler errors from that...)
反对全面禁止 goto，认为 goto error 是必要的错误处理惯用法。
“不要使用 goto、setjmp 或 longjmp。”在 C 里不用这些原语做错误处理，几乎总会写出很糟的代码。他们应该开个例外：应当允许并鼓励“goto error;”。
uasm查看英文原文
> "Do not use goto, setjmp or longjmp." Error handling in C without those primitives will almost always result in horrible code. They should've made an exception here: "goto error;" should've been allowed and encouraged.
静态分析检查器的实现难度差异很大，有些规则需要 AST 和解析器。
几年前夏天，我在 JPL 实习，为这套标准开发静态分析套件。为这类规则写检查器是很有意思的练习，也让我成长很多：从没接触过形式语言、解析和文法，到用这些概念帮助构建更可靠的软件。有些规则用合适的 sed 表达式就能查；另一些则必须借助 AST。像“复合表达式中多个子表达式的求值顺序必须用括号显式说明”这样的规则尤其难，我花了几周钻研解析基础、lex 和 yacc，LaRS 的研究生帮了很多忙。
mvanveen查看英文原文
A few summers ago I was an intern at JPL working on a static analysis suite for this exact standard. Writing code checkers for these sorts of rules is a really interesting exercise and it helped me grow a lot as a programmer! I went from having no exposure to formal languages, parsing, and grammars to actively playing around with these concepts to try and help build more reliable software. It was a humbling, challenging, and incredibly rewarding experience. Sometimes, a rule is extremely simple to implement. For example, checking a rule that requires that an assert is raised after every so many lines within a given scope is just a matter of picking the right sed expression. Other times, you really need an AST to be able to do anything at all. A rule like "In compound expressions with multiple sub-expressions the intended order of evaluation shall be made explicit with parentheses" is particularly challenging. I spent a few weeks on this rule! I was banging my head, trying to learn the fundamentals of parsing languages, spending my hours diving into wikipedia articles and learning lex and yacc. The grad students at LaRS were always extremely helpful and were always willing to help tutor me and teach me what I needed to learn (hi mihai and cheng if you're reading!). After consulting them and scratching our heads for a while, we figured we might be able to do it with a shift-reduce parser when a shift or reduce ambiguity is introduced during the course of parsing a source code file. This proved beyond the scope of what I'd be able to do within an internship, but it helped me appreciate the nuance and complexity hidden within even seemingly simple statements about language properties. Automated analysis of these rules gives you a really good appreciation of the Chomsky language hierarchy because the goal is always to create the simplest possible checker you can reliably show is able to accurately cover all the possible cases. Sometimes that is simple as a regular language, but the next rule might require you to have a parser for the language. For what it's worth, this is only one of the ways the guys at LaRS (http://lars-lab.jpl.nasa.gov/) help try to improve software reliability on-lab. Most of the members are world-class experts in formal verification analysis and try to integrate their knowledge with missions as effectively as possible. Sometimes, this means riding the dual responsibility of functioning as a researcher and a embedded flight software engineer, working alongside the rest of the team. If anyone's interested in trying out static analysis of C on your own, I highly reccomend checking out Eli Bendersky's awesome C parser for Python (http://code.google.com/p/pycparser/). I found it leaps and bounds better than the existing closed-source toolsets we had licenses for, like Coverity Extend. At the time, it had the extremely horrible limitation of only parsing ANSI 89, but Eli has since improved the parser to have ANSI 99 compliance. Analyzing C in Python is a dream.
质疑禁止动态内存分配会严重限制程序能力。
等等……没有 malloc 或 sbrk？那意味着所有空间都得在栈上分配？这是相当严重的限制，可能很难做真正有意思的事。
afhof查看英文原文
Wait.... no malloc or sbrk? That means all space has to be stack allocated? That's a pretty serious limitation and would probably make it hard to do anything really interesting.
历次讨论
同类还值得读
开源应用架构
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编辑精选