document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-28 23:20:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6149 from penghuster/master

Browse Source 
translated
This commit is contained in:
Xingyu.Wang 2017-10-21 08:00:06 -05:00 committed by GitHub
commit c98cd6a565
2 changed files with 67 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
sources/tech/20160611 How To Code Like The Top Programmers At NASA — 10 Critical Rules.md
View File

@ -1,71 +0,0 @@
translating by penghuster
How To Code Like The Top Programmers At NASA — 10 Critical Rules
============================================================
_**[![rules of coding nasa](http://fossbytes.com/wp-content/uploads/2016/06/rules-of-coding-nasa.jpg)][1] Short Bytes:** Do you know how top programmers write mission-critical code at NASA? To make such code clearer, safer, and easier to understand, NASA’s Jet Propulsion Laboratory has laid 10 rules for developing software._
The developers at NASA have one of the most challenging jobs in the programming world. They write code and develop mission-critical applications with safety as their primary concerns.
In such situations, it’s important to follow some serious coding guidelines. These rules cover different aspects of software development like how a software should be written, which language features should be used etc.
Even though it’s difficult to establish a consensus over a good coding standard, NASA’s Jet Propulsion Laboratory (JPL) follows a set of [guidelines of code][2] named “The Power of Ten–Rules for Developing Safety Critical Code”.
This guide focuses mainly on code written in C programming languages due to JPL’s long association with the language. But, these guidelines could be easily applied on other programming languages as well.
Laid by JPL lead scientist Gerard J. Holzmann, these strict coding rules focus on security.
[][3]
NASA’s 10 rules for writing mission-critical code:
1. _Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp _ constructs _, and direct or indirect recursion._
2. _All loops must have a fixed_   _upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated._
3. _Do not use dynamic memory allocation after initialization._
4. _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._
5. _The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements)._
6. _Data objects must be declared at the smallest possible level of scope._
7. _The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function._
8. _The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code._
9. _The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted._
10. _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._
About these rules, here’s what NASA has to say:
The rules act like the seatbelt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.
[Source][4]
Did you find this article helpful? Don’t forget to drop your feedback in the comments section below.
--------------------------------------------------------------------------------
作者简介：
Adarsh Verma
Fossbytes co-founder and an aspiring entrepreneur who keeps a close eye on open source, tech giants, and security. Get in touch with him by sending an email — adarsh.verma@fossbytes.com
------------------
via: https://fossbytes.com/nasa-coding-programming-rules-critical/
作者：[Adarsh Verma ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://fossbytes.com/author/adarsh/
[1]:http://fossbytes.com/wp-content/uploads/2016/06/rules-of-coding-nasa.jpg
[2]:http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
[3]:https://fossbytes.com/wp-content/uploads/2016/12/learn-to-code-banner-ad-content-1.png
[4]:http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf

67
translated/tech/20160611 How To Code Like The Top Programmers At NASA — 10 Critical Rules.md Normal file
View File

@ -0,0 +1,67 @@
如何跟 NASA 顶级程序员一样编程—10 条重要原则
===
**[![rules of coding nasa](http://upload-images.jianshu.io/upload_images/2489863-791757ae6bd313e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)][1] 引言:** 你知道 NASA 顶级程序员如何编写重要任务代码么？为了确保代码更清楚、更安全、且更容易理解，NASA  的喷气推进实验室制定了 10 条编码规则。
NASA 的开发者是编程界最有挑战性的工作之一。他们编写代码并将开发安全的关键任务应用程序作为其主要关注点。
在这种情形下，遵守一些重要的编码规则是重要的。这些规则覆盖软件开发的多个方面，例如软件应该被如何编码、哪些语言特性应该被使用等。
尽管很难就一个好的编码标准达成共识，NASA　的喷气推进实验室（JPL）遵守一个[编码规则][2]，其名为“The Power of Ten–Rules for Developing Safety Critical Code”。
由于 JPL 长期使用 C 语言，这个规则主要是针对于 C 程序语言编写。但是这些规则也可以很容地应用到其它的程序语言。
该规则由 JPL 的首席科学家 Gerard J. Holzmann 制定，这些严格的编码规则主要是聚焦于安全。
![][3]
NASA 的 10 条编写关键任务代码的规则：
1. 限制所有代码为极为简单的控制流结构—不用 `goto` 语句、`setjmp` 或 `longjmp` 结构，不用间接或直接的递归调用。
2. 所有循环必须有一个固定的上限值。该预置迭代上限值必须是能够非常可能被某个检测工具静态证明。如果该上限值不能静态证明，那么可以认为违背该原则。
3. 在初始化后不要使用动态内存分配。
4. 任何函数都不能比在一张纸上可打印的长度更长，在一个标准的参考格式中，一个语句一行，一个声明一行。通常地，这意味着一个函数的代码行不能超过 60。
5. 代码中断言的密度平均最少应该达到每个函数 2 个断言以上。断言被用于检测那些在真实生命周期中不可能发生的条件。断言必须总是没有副作用并应该定义为布尔测试。当一个断言失败时，一个明确的回复动作应该被执行，例如，返回一个错误条件到执行断言失败的函数调用者。对于静态工具来说，任何断言证明其从不失败或从不违反该规则（例如，通过增加 `assert(true)` 语句是不可能满足这个规则的）。
6. 必须在最小的范围内声明数据对象。
7. 每个调用函数必须检查非 void 函数的返回值，且在每个函数内其参数的有效性必须进行检查。
8. 预处理器的使用必须被限制在头文件包含和简单的宏定义。符号拼接、可变参数列表（省略号）和递归宏调用都是不允许的。所有的宏必须能够扩展为完整的语法单元。条件编译指令的使用通常是晦涩的，但也不总是能够避免。这意味着即使在一个大的软件开发中有一两个条件编译指令是正常的，推荐使用避免多次包含头文件的标准引用模板。上述每一种情况都应该用一个基本检查工具标记，并在代码中正当使用。
9. 应该限制指针的使用。特别地，不允许超过一级的解除指针引用。解除指针引用操作不可以隐含在宏定义或类型声明中。函数指针是不允许的。
10. 从开发的第一天起，必须在编译器开启最高级别告警选项的条件下，对代码进行编译。在此设置之下，代码必须零告警编译通过。代码必须每天至少进行一次检查，且更推荐一次以上。利用最先进的源代码静态分析工具对代码进行分析，且零告警通过。
关于这些规则，NASA 要求注意：
这些规则就像汽车中的安全带一样，刚开始你可能感到有一点不适，但是一段时间后就会养成习惯并且不使用它对你来说变得不可想象。
[来源][4]
此文是否对你有帮助？不要忘了在下面的评论区写下你的反馈。
---
作者简介：
Adarsh Verma 是 Fossbytes 的共同创始人，他是一个令人尊敬的企业家，他一直对开源、技术突破和完全保持密切关注。可以通过邮件联系他 — [adarsh.verma@fossbytes.com](mailto:adarsh.verma@fossbytes.com)
------------------
via: https://fossbytes.com/nasa-coding-programming-rules-critical/
作者：[Adarsh Verma ][a]
译者：[penghuster](https://github.com/penghuster)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://fossbytes.com/author/adarsh/
[1]:http://fossbytes.com/wp-content/uploads/2016/06/rules-of-coding-nasa.jpg
[2]:http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
[3]:https://fossbytes.com/wp-content/uploads/2016/12/learn-to-code-banner-ad-content-1.png
[4]:http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf