diff options
author | Andy Deng <theandy.deng@gmail.com> | 2017-01-25 05:14:31 +0100 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2017-01-26 23:27:59 +0100 |
commit | 9e5e74e61ce8615d4105b2651f6b7d46434014f2 (patch) | |
tree | 46a6bb1104968cd7280566baf27073b99471d009 /Documentation/translations | |
parent | Doc: Fix double words in Documentation (diff) | |
download | linux-9e5e74e61ce8615d4105b2651f6b7d46434014f2.tar.xz linux-9e5e74e61ce8615d4105b2651f6b7d46434014f2.zip |
zh_CN/CodingStyle: improve translation
Some of the sentences in Chapters 19 and 20 are re-translated:
- Fixed translation errors in Section 2 of Chapter 19 to prevent
misleading readers;
- Retranslate some sentences to make the translation more clear and
accurate.
Signed-off-by: Andy Deng <theandy.deng@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/translations')
-rw-r--r-- | Documentation/translations/zh_CN/CodingStyle | 61 |
1 files changed, 31 insertions, 30 deletions
diff --git a/Documentation/translations/zh_CN/CodingStyle b/Documentation/translations/zh_CN/CodingStyle index dc101f48e713..45b8fc9ef8ea 100644 --- a/Documentation/translations/zh_CN/CodingStyle +++ b/Documentation/translations/zh_CN/CodingStyle @@ -735,22 +735,22 @@ Vim 能够解释这样的标记: 第十九章:内联汇编 -在特定架构的代码中,你也许需要内联汇编来使用 CPU 接口和平台相关功能。在需要 -这么做时,不要犹豫。然而,当 C 可以完成工作时,不要无端地使用内联汇编。如果 -可能,你可以并且应该用 C 和硬件交互。 +在特定架构的代码中,你可能需要内联汇编与 CPU 和平台相关功能连接。需要这么做时 +就不要犹豫。然而,当 C 可以完成工作时,不要平白无故地使用内联汇编。在可能的情 +况下,你可以并且应该用 C 和硬件沟通。 -考虑去写通用一点的内联汇编作为简明的辅助函数,而不是重复写下它们的细节。记住 -内联汇编可以使用 C 参数。 +请考虑去写捆绑通用位元 (wrap common bits) 的内联汇编的简单辅助函数,别去重复 +地写下只有细微差异内联汇编。记住内联汇编可以使用 C 参数。 -大而特殊的汇编函数应该放在 .S 文件中,对应 C 的原型定义在 C 头文件中。汇编 -函数的 C 原型应该使用 “asmlinkage”。 +大型,有一定复杂度的汇编函数应该放在 .S 文件内,用相应的 C 原型定义在 C 头文 +件中。汇编函数的 C 原型应该使用 “asmlinkage”。 -你可能需要将你的汇编语句标记为 volatile,来阻止 GCC 在没发现任何副作用后就 -移除了它。你不必总是这样做,虽然,这样可以限制不必要的优化。 +你可能需要把汇编语句标记为 volatile,用来阻止 GCC 在没发现任何副作用后就把它 +移除了。你不必总是这样做,尽管,这不必要的举动会限制优化。 -在写一个包含多条指令的单个内联汇编语句时,把每条指令用引号字符串分离,并写在 -单独一行,在每个字符串结尾,除了 \n\t 结尾之外,在汇编输出中适当地缩进下 -一条指令: +在写一个包含多条指令的单个内联汇编语句时,把每条指令用引号分割而且各占一行, +除了最后一条指令外,在每个指令结尾加上 \n\t,让汇编输出时可以正确地缩进下一条 +指令: asm ("magic %reg1, #42\n\t" "more_magic %reg2, %reg3" @@ -759,33 +759,34 @@ Vim 能够解释这样的标记: 第二十章:条件编译 -只要可能,就不要在 .c 文件里面使用预处理条件;这样做让代码更难阅读并且逻辑难以 -跟踪。替代方案是,在头文件定义函数在这些 .c 文件中使用这类的条件表达式,提供空 -操作的桩版本(译注:桩程序,是指用来替换一部分功能的程序段)在 #else 情况下, -再从 .c 文件中无条件地调用这些函数。编译器会避免生成任何桩调用的代码,产生一致 -的结果,但逻辑将更加清晰。 +只要可能,就不要在 .c 文件里面使用预处理条件 (#if, #ifdef);这样做让代码更难 +阅读并且更难去跟踪逻辑。替代方案是,在头文件中用预处理条件提供给那些 .c 文件 +使用,再给 #else 提供一个空桩 (no-op stub) 版本,然后在 .c 文件内无条件地调用 +那些 (定义在头文件内的) 函数。这样做,编译器会避免为桩函数 (stub) 的调用生成 +任何代码,产生的结果是相同的,但逻辑将更加清晰。 -宁可编译整个函数,而不是部分函数或部分表达式。而不是在一个表达式添加 ifdef, -解析部分或全部表达式到一个单独的辅助函数,并应用条件到该函数内。 +最好倾向于编译整个函数,而不是函数的一部分或表达式的一部分。与其放一个 ifdef +在表达式内,不如分解出部分或全部表达式,放进一个单独的辅助函数,并应用预处理 +条件到这个辅助函数内。 -如果你有一个在特定配置中可能是未使用的函数或变量,编译器将警告它定义了但未使用, -标记这个定义为 __maybe_unused 而不是将它包含在一个预处理条件中。(然而,如果 -一个函数或变量总是未使用的,就直接删除它。) +如果你有一个在特定配置中,可能变成未使用的函数或变量,编译器会警告它定义了但 +未使用,把它标记为 __maybe_unused 而不是将它包含在一个预处理条件中。(然而,如 +果一个函数或变量总是未使用,就直接删除它。) -在代码中,可能的情况下,使用 IS_ENABLED 宏来转化某个 Kconfig 标记为 C 的布尔 -表达式,并在正常的 C 条件中使用它: +在代码中,尽可能地使用 IS_ENABLED 宏来转化某个 Kconfig 标记为 C 的布尔 +表达式,并在一般的 C 条件中使用它: if (IS_ENABLED(CONFIG_SOMETHING)) { ... } -编译器会无条件地做常数合并,就像使用 #ifdef 那样,包含或排除代码块,所以这不会 -带来任何运行时开销。然而,这种方法依旧允许 C 编译器查看块内的代码,并检查它的正确 -性(语法,类型,符号引用,等等)。因此,如果条件不满足,代码块内的引用符号将不存在, -你必须继续使用 #ifdef。 +编译器会做常量折叠,然后就像使用 #ifdef 那样去包含或排除代码块,所以这不会带 +来任何运行时开销。然而,这种方法依旧允许 C 编译器查看块内的代码,并检查它的正 +确性 (语法,类型,符号引用,等等)。因此,如果条件不满足,代码块内的引用符号就 +不存在时,你还是必须去用 #ifdef。 -在任何有意义的 #if 或 #ifdef 块的末尾(超过几行),在 #endif 同一行的后面写下 -注释,指出该条件表达式被使用。例如: +在任何有意义的 #if 或 #ifdef 块的末尾 (超过几行的),在 #endif 同一行的后面写 +下注解,注释这个条件表达式。例如: #ifdef CONFIG_SOMETHING ... |