Documentation/translations/zh_CN/process/4.Coding.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/process/4.Coding.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/process/4.Coding.rst
Extension
.rst
Size
18243 bytes
Lines
294
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-zh_CN.rst

:Original: :ref:`Documentation/process/4.Coding.rst <development_coding>`

:Translator:

 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>

:校译:

 吴想成 Wu XiangCheng <bobwxc@email.cn>

.. _cn_development_coding:

使代码正确
======================

虽然一个坚实的、面向社区的设计过程有很多值得说道的，但是任何内核开发项目工作
的证明都反映在代码中。它是将由其他开发人员检查并合并（或不合并）到主线树中
的代码。所以这段代码的质量决定了项目的最终成功。

本节将检查编码过程。我们将从内核开发人员常犯的几种错误开始。然后重点将转移
到正确的做法和相关有用的工具上。

陷阱
----

代码风格
********

内核长期以来都有其标准的代码风格，如
:ref:`Documentation/translations/zh_CN/process/coding-style.rst <cn_codingstyle>`
中所述。在多数时候，该文档中描述的准则至多被认为是建议性的。因此，内核中存在
大量不符合代码风格准则的代码。这种代码的存在会给内核开发人员带来两方面的危害。

首先，相信内核代码标准并不重要，也不强制执行。但事实上，如果没有按照标准
编写代码，那么新代码将很难加入到内核中；许多开发人员甚至会在审查代码之前要求
对代码进行重新格式化。一个像内核这么大的代码库需要一些统一格式的代码，以使
开发人员能够快速理解其中的任何部分。所以再也经不起奇怪格式的代码的折腾了。

内核的代码风格偶尔会与雇主的强制风格发生冲突。在这种情况下，必须在代码合并
之前遵从内核代码风格。将代码放入内核意味着以多种方式放弃一定程度的控制权——
包括控制代码样式。

另一个危害是认为已经在内核中的代码迫切需要修复代码样式。开发者可能会开始编写
重新格式化补丁，作为熟悉开发过程的一种方式，或者作为将其名字写入内核变更日志
的一种方式，或者两者兼而有之。但是纯代码风格的修复被开发社区视为噪音，它们往
往受到冷遇。因此，最好避免编写这种类型的补丁。在由于其他原因处理一段代码的
同时顺带修复其样式是很自然的，但是不应该仅为了更改代码样式而更改之。

代码风格文档也不应该被视为绝对不可违反的规则。如果有一个足够的理由反对这种
样式（例如为了80列限制拆分行会导致可读性大大降低），那么就这样做吧。

注意您还可以使用 ``clang-format`` 工具来帮助您处理这些规则，快速自动重新格式
化部分代码，和审阅完整的文件以发现代码样式错误、拼写错误和可能的改进。它还
可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
信息，请参阅文档 :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`

抽象层
******

计算机科学教授教学生以灵活性和信息隐藏的名义广泛使用抽象层。当然，内核广泛
地使用了抽象；任何涉及数百万行代码的项目都必须做到这一点以存续下来。但经验
表明，过度或过早的抽象可能和过早的优化一样有害。抽象应用在适当层级，
不要过度。

简单点，先考虑一个调用时始终只有一个参数且总为零的函数。我们可以保留这个参数，
以在需要使用它时提供的额外灵活性。不过，在那时实现了这个额外参数的代码很有
可能以某种从未被注意到的微妙方式被破坏——因为它从未被使用过。或者当需要额外
的灵活性时，它并未以符合程序员当初期望的方式来实现。内核开发人员通常会提交

Annotation

Implementation Notes