Adarsh Verma 发布的文章

在终端上使用各种命令执行重要任务是 Linux 桌面体验中不可或缺的一部分。Linux 这个开源操作系统拥有丰富的命令，任何用户都无法全部记住所有这些命令。而使事情变得更复杂的是，每个命令都有自己的一组带来丰富的功能的选项。

为了解决这个问题，人们创建了 手册页 man page ，（手册 —— man 是 manual 的缩写）。首先，它是用英文写成的，包含了大量关于不同命令的深入信息。有时候，当你在寻找命令的基本信息时，它就会显得有点庞杂。为了解决这个问题，人们创建了TLDR 页。

什么是 TLDR 页？

TLDR 页的 GitHub 仓库将其描述为简化的、社区驱动的手册页集合。在实际示例的帮助下，努力让使用手册页的体验变得更简单。如果还不知道，TLDR 取自互联网的常见俚语： 太长没读 Too Long Didn’t Read 。

如果你想比较一下，让我们以 tar 命令为例。 通常，手册页的篇幅会超过 1000 行。tar 是一个归档实用程序，经常与 bzip 或 gzip 等压缩方法结合使用。看一下它的手册页：

tar man page

而另一方面，TLDR 页面让你只是浏览一下命令，看看它是如何工作的。 tar 的 TLDR 页面看起来像这样，并带有一些方便的例子 —— 你可以使用此实用程序完成的最常见任务：

tar tldr page

让我们再举一个例子，向你展示 TLDR 页面为 apt 提供的内容：

tldr-page-of-apt

如上，它向你展示了 TLDR 如何工作并使你的生活更轻松，下面让我们告诉你如何在基于 Linux 的操作系统上安装它。

如何在 Linux 上安装和使用 TLDR 页？

最成熟的 TLDR 客户端是基于 Node.js 的，你可以使用 NPM 包管理器轻松安装它。如果你的系统上没有 Node 和 NPM，请运行以下命令：

sudo apt-get install nodejs
sudo apt-get install npm

如果你使用的是 Debian、Ubuntu 或 Ubuntu 衍生发行版以外的操作系统，你可以根据自己的情况使用yum、dnf 或 pacman包管理器。

现在，通过在终端中运行以下命令，在 Linux 机器上安装 TLDR 客户端：

sudo npm install -g tldr

一旦安装了此终端实用程序，最好在尝试之前更新其缓存。 为此，请运行以下命令：

tldr  --update

执行此操作后，就可以阅读任何 Linux 命令的 TLDR 页面了。 为此，只需键入：

tldr  <commandname>

tldr kill command

你还可以运行其帮助命令，以查看可与 TLDR 一起使用的各种参数，以获取所需输出。 像往常一样，这个帮助页面也附有例子。

TLDR 的 web、Android 和 iOS 版本

你会惊喜地发现 TLDR 页不仅限于你的 Linux 桌面。 相反，它也可以在你的 Web 浏览器中使用，可以从任何计算机访问。

要使用 TLDR Web 版本，请访问 tldr.ostera.io 并执行所需的搜索操作。

或者，你也可以下载 iOS 和 Android 应用程序，并随时随地学习新命令。

tldr app ios

你觉得这个很酷的 Linux 终端技巧很有意思吗？ 请尝试一下，让我们知道您的反馈。

via: https://fossbytes.com/tldr-pages-linux-man-pages-alternative/

作者：Adarsh Verma 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

rules of coding nasa

引言： 你知道 NASA 顶级程序员如何编写关键任务代码么？为了确保代码更清楚、更安全、且更容易理解，NASA 的喷气推进实验室制定了 10 条编码规则。

NASA 的开发者是编程界最有挑战性的工作之一。他们编写代码并将开发安全的关键任务应用程序作为其主要关注点。

在这种情形下，遵守一些严格的编码规则是重要的。这些规则覆盖软件开发的多个方面，例如软件应该如何编码、应该使用哪些语言特性等。

尽管很难就一个好的编码标准达成共识，NASA 的喷气推进实验室（JPL）遵守一个编码规则，其名为“十的次方：开发安全的关键代码的规则”。

由于 JPL 长期使用 C 语言，这个规则主要是针对于 C 程序语言编写。但是这些规则也可以很容地应用到其它的程序语言。

该规则由 JPL 的首席科学家 Gerard J. Holzmann 制定，这些严格的编码规则主要是聚焦于安全。

NASA 的 10 条编写关键任务代码的规则：

  1. 限制所有代码为极为简单的控制流结构 — 不用 goto 语句、setjmp 或 longjmp 结构，不用间接或直接的递归调用。
  2. 所有循环必须有一个固定的上限值。必须可以被某个检测工具静态证实，该循环不能达到预置的迭代上限值。如果该上限值不能被静态证实，那么可以认为违背该原则。
  3. 在初始化后不要使用动态内存分配。
  4. 如果一个语句一行、一个声明一行的标准格式来参考，那么函数的长度不应该比超过一张纸。通常这意味着每个函数的代码行不能超过 60。
  5. 代码中断言的密度平均低至每个函数 2 个断言。断言被用于检测那些在实际执行中不可能发生的情况。断言必须没有副作用，并应该定义为布尔测试。当一个断言失败时，应该执行一个明确的恢复动作，例如，把错误情况返回给执行该断言失败的函数调用者。对于静态工具来说，任何能被静态工具证实其永远不会失败或永远不能触发的断言违反了该规则（例如，通过增加无用的 assert(true) 语句是不可能满足这个规则的）。
  6. 必须在最小的范围内声明数据对象。
  7. 非 void 函数的返回值在每次函数调用时都必须检查，且在每个函数内其参数的有效性必须进行检查。
  8. 预处理器的使用仅限制于包含头文件和简单的宏定义。符号拼接、可变参数列表（省略号）和递归宏调用都是不允许的。所有的宏必须能够扩展为完整的语法单元。条件编译指令的使用通常是晦涩的，但也不总是能够避免。这意味着即使在一个大的软件开发中超过一两个条件编译指令也要有充足的理由，这超出了避免多次包含头文件的标准做法。每次在代码中这样做的时候必须有基于工具的检查器进行标记，并有充足的理由。
  9. 应该限制指针的使用。特别是不应该有超过一级的解除指针引用。解除指针引用操作不可以隐含在宏定义或类型声明中。还有，不允许使用函数指针。
  10. 从开发的第一天起，必须在编译器开启最高级别警告选项的条件下对代码进行编译。在此设置之下，代码必须零警告编译通过。代码必须利用源代码静态分析工具每天至少检查一次或更多次，且零警告通过。

关于这些规则，NASA 是这么评价的：

这些规则就像汽车中的安全带一样，刚开始你可能感到有一点不适，但是一段时间后就会养成习惯，你会无法想象不使用它们的日子。

此文是否对你有帮助？不要忘了在下面的评论区写下你的反馈。

作者简介：

Adarsh Verma 是 Fossbytes 的共同创始人，他是一个令人尊敬的企业家，他一直对开源、技术突破和完全保持密切关注。可以通过邮件联系他 — [email protected]

via: https://fossbytes.com/nasa-coding-programming-rules-critical/

作者：Adarsh Verma 译者：penghuster 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出