数据简化社区Google和Linux代码风格指南(附PDF公号发“代码风格”下载)

数据简化社区Google和Linux代码风格指南(附PDF公号发“代码风格”下载)

秦陇纪2019代码类 数据简化DataSimp 昨天

数据简化DataSimp导读：数据简化社区(Data SimplificationCommunity)遵从Google开源项目风格指南(中文版)/Linux内核代码风格/中英文对照版本。公号输入框回复关键字，可下载本文PDF。数据DataSimp社区分享：信息与数据处理分析、数据科学研究前沿、数据资源现状和数据简化基础的科学知识、技术应用、产业活动、人物机构等信息。欢迎大家参与投稿，为数据科学技术做贡献，使国人尽快提高数据能力，提高社会信息流通效率。做事要平台，思路要跟进；止步吃住行，无力推文明。要推进人类文明，不可止步于敲门呐喊；设计空想太多，无法实现就虚度一生；工程能力至关重要，秦陇纪与君共勉之。

数据简化社区Google和Linux代码风格指南(21195字)

目录

A Google开源项目风格指南(中文版)(4082字)

1.内容目录

2.内容(略)点上述链接访问网站

B Linux内核代码风格(16078字)

1) 缩进

2) 把长的行和字符串打散

3) 大括号和空格的放置

4) 命名

5)Typedef

6) 函数

7) 集中的函数退出途径

8) 注释

9) 你已经把事情弄糟了

10)Kconfig 配置文件

11) 数据结构

12) 宏，枚举和RTL

13) 打印内核消息

14) 分配内存

15) 内联弊病

16) 函数返回值及命名

17) 不要重新发明内核宏

18) 编辑器模式行和其他需要罗嗦的事情

19) 内联汇编

20) 条件编译

附录 I) 参考

参考文献(868字)Appx(1236字).数据简化DataSimp社区简介

---

A  Google开源项目风格指南(中文版)(4082字)

Google开源项目风格指南(中文版)

文|Google开源项目风格指南(中文版)；数据简化DataSimp©20190105Sat

1.内容目录

·        Google开源项目风格指南 (中文版)

·        C++风格指南 - 内容目录

o            0.扉页

§            0.1译者前言

§            0.2背景

o            1.头文件

§            1.1.Self-contained 头文件

§            1.2.#define 保护

§            1.3.前置声明

§            1.4.内联函数

§            1.5.#include 的路径及顺序

§            译者 (YuleFox) 笔记

§            译者（acgtyrant）笔记

o            2.作用域

§            2.1.命名空间

§            2.2.匿名命名空间和静态变量

§            2.3.非成员函数、静态成员函数和全局函数

§            2.4.局部变量

§            2.5.静态和全局变量

§            译者 (YuleFox) 笔记

§            译者（acgtyrant）笔记

o            3.类

§            3.1.构造函数的职责

§            3.2.隐式类型转换

§            3.3.可拷贝类型和可移动类型

§            3.4.结构体 VS. 类

§            3.5.继承

§            3.6.多重继承

§            3.7.接口

§            3.8.运算符重载

§            3.9.存取控制

§            3.10.声明顺序

§            译者 (YuleFox) 笔记

o            4.函数

§            4.1.参数顺序

§            4.2.编写简短函数

§            4.3.引用参数

§            4.4.函数重载

§            4.5.缺省参数

§            4.6.函数返回类型后置语法

o            5.来自 Google 的奇技

§            5.1.所有权与智能指针

§            5.2.Cpplint

§            译者（acgtyrant）笔记

o            6.其他 C++ 特性

§            6.1.引用参数

§            6.2.右值引用

§            6.3.函数重载

§            6.4.缺省参数

§            6.5.变长数组和 alloca()

§            6.6.友元

§            6.7.异常

§            6.8.运行时类型识别

§            6.9.类型转换

§            6.10.流

§            6.11.前置自增和自减

§            6.12.const 用法

§            6.13.constexpr 用法

§            6.14.整型

§            6.15.64 位下的可移植性

§            6.16.预处理宏

§            6.17.0, nullptr 和 NULL

§            6.18.sizeof

§            6.19.auto

§            6.20.列表初始化

§            6.21.Lambda 表达式

§            6.22.模板编程

§            6.23.Boost 库

§            6.24.C++11

§            译者（acgtyrant）笔记

o            7.命名约定

§            7.1.通用命名规则

§            7.2.文件命名

§            7.3.类型命名

§            7.4.变量命名

§                 普通变量命名

§                 类数据成员

§                 结构体变量

§            7.5.常量命名

§            7.6.函数命名

§            7.7.命名空间命名

§            7.8.枚举命名

§            7.9.宏命名

§            7.10.命名规则的特例

§            译者（acgtyrant）笔记

o            8.注释

§            8.1.注释风格

§            8.2.文件注释

§                 法律公告和作者信息

§                 文件内容

§            8.3.类注释

§            8.4.函数注释

§                 函数声明

§                 函数定义

§            8.5.变量注释

§                 类数据成员

§                 全局变量

§            8.6.实现注释

§                 代码前注释

§                 行注释

§                 函数参数注释

§                 不允许的行为

§            8.7.标点, 拼写和语法

§            8.8.TODO 注释

§            8.9.弃用注释

§            译者 (YuleFox) 笔记

o            9.格式

§            9.1.行长度

§            9.2.非 ASCII 字符

§            9.3.空格还是制表位

§            9.4.函数声明与定义

§            9.5.Lambda 表达式

§            9.6.函数调用

§            9.7.列表初始化格式

§            9.8.条件语句

§            9.9.循环和开关选择语句

§            9.10.指针和引用表达式

§            9.11.布尔表达式

§            9.12.函数返回值

§            9.13.变量及数组初始化

§            9.14.预处理指令

§            9.15.类格式

§            9.16.构造函数初始值列表

§            9.17.命名空间格式化

§            9.19.水平留白

§                 通用

§                 循环和条件语句

§                 操作符

§                 模板和转换

§            9.19.垂直留白

§            译者 (YuleFox) 笔记

§            译者（acgtyrant）笔记

o            10.规则特例

§            10.1.现有不合规范的代码

§            10.2.Windows 代码

o            11.结束语

·        Objective-C风格指南 - 内容目录

o            GoogleObjective-C Style Guide 中文版

§            译者的话

§                 ewanke

§                 Yang.Y

§            背景介绍

§            例子

o            留白和格式

§            空格 vs. 制表符

§            行宽

§            方法声明和定义

§            方法调用

§            @public和 @private

§            异常

§            协议名

§            块（闭包）

o            命名

§            文件名

§            Objective-C++

§            类名

§            类别名

§            Objective-C方法名

§            变量名

§                 普通变量名

§                 实例变量

§                 常量

o            注释

§            文件注释

§                 版权信息及作者

§            声明部分的注释

§            实现部分的注释

§            对象所有权

o            Cocoa和 Objective-C 特性

§            成员变量应该是 @private

§            明确指定构造函数

§            重载指定构造函数

§            重载 NSObject 的方法

§            初始化

§            避免 +new

§            保持公共 API 简单

§            #importand #include

§            使用根框架

§            构建时即设定 autorelease

§            autorelease优先 retain 其次

§            init和 dealloc 内避免使用访问器

§            按声明顺序销毁实例变量

§            setter应复制 NSStrings

§            避免抛异常

§            nil检查

§            BOOL若干陷阱

§            属性（Property）

§                 命名

§                 位置

§                 字符串应使用 copy 属性（Attribute）

§                 原子性

§                 点引用

§            没有实例变量的接口

§            自动 synthesize 实例变量

o            Cocoa模式

§            委托模式

§            模型/视图/控制器（MVC）

·        Python风格指南 - 内容目录

o            扉页

o            背景

o            Python语言规范

§            Lint

§            导入

§            包

§            异常

§            全局变量

§            嵌套/局部/内部类或函数

§            列表推导(List Comprehensions)

§            默认迭代器和操作符

§            生成器

§            Lambda函数

§            条件表达式

§            默认参数值

§            属性(properties)

§            True/False的求值

§            过时的语言特性

§            词法作用域(Lexical Scoping)

§            函数与方法装饰器

§            线程

§            威力过大的特性

o            Python风格规范

§            分号

§            行长度

§            括号

§            缩进

§            空行

§            空格

§            Shebang

§            注释

§            类

§            字符串

§            文件和sockets

§            TODO注释

§            导入格式

§            语句

§            访问控制

§            命名

§            Main

o            临别赠言

·        Shell风格指南 - 内容目录

o            扉页

o            背景

§            使用哪一种Shell

§            什么时候使用Shell

o            Shell文件和解释器调用

§            文件扩展名

§            SUID/ SGID

o            环境

§            STDOUTvs STDERR

o            注释

§            文件头

§            功能注释

§            实现部分的注释

§            TODO注释

o            格式

§            缩进

§            行的长度和长字符串

§            管道

§            循环

§            case语句

§            变量扩展

§            引用

o            特性及错误

§            命令替换

§            test，[和[[

§            测试字符串

§            文件名的通配符扩展

§            Eval

§            管道导向while循环

o            命名约定

§            函数名

§            变量名

§            常量和环境变量名

§            源文件名

§            只读变量

§            使用本地变量

§            函数位置

§            主函数main

o            调用命令

§            检查返回值

§            内建命令和外部命令

o            结论

---

© CopyrightRevision f837c554.

Built with Sphinx using a theme provided by Read the Docs.

Read theDocs v: latest

1.1 C++风格指南-内容目录

https://github.com/zh-google-styleguide/zh-google-styleguide

zh-google-styleguide/zh-google-styleguide

CodeIssues11 Pullrequests 0 Projects0

Insights

Google 开源项目风格指南 (中文版) http://zh-google-styleguide.readthedocs.org

https://zh-google-styleguide.readthedocs.io/en/latest/

Google开源项目风格指南

latest

·      Google开源项目风格指南 (中文版)

·      C++风格指南 - 内容目录

·      Objective-C风格指南 - 内容目录

·      Python风格指南 - 内容目录

·      Shell风格指南 - 内容目录

Reach over7 million devs each month when you advertise with Read the Docs.

Sponsored · Ads served ethically

·      Docs »

·      Google 开源项目风格指南 (中文版)

·      Editon GitHub

1.2 C++风格指南(略)点上述链接访问网站

---

Google 开源项目风格指南 (中文版)

·      在线文档托管在ReadTheDocs : 在线阅读最新版本

·      中文风格指南 GitHub 托管地址：zh-google-styleguide

Note

声明.

本项目并非 Google 官方项目, 而是由国内程序员凭热情创建和维护.

如果你关注的是 Google 官方英文版, 请移步 Google Style Guide

每个较大的开源项目都有自己的风格指南: 关于如何为该项目编写代码的一系列约定 (有时候会比较武断). 当所有代码均保持一致的风格, 在理解大型代码库时更为轻松.

“风格” 的含义涵盖范围广, 从 “变量使用驼峰格式 (camelCase)” 到 “决不使用全局变量” 再到 “决不使用异常”. 英文版项目维护的是在 Google 使用的编程风格指南. 如果你正在修改的项目源自 Google, 你可能会被引导至 英文版项目页面, 以了解项目所使用的风格.

我们已经发布了五份 中文版的风格指南:

1.GoogleC++ 风格指南

2.GoogleObjective-C 风格指南

3.GooglePython 风格指南

4.GoogleJSON 风格指南

5.GoogleShell 风格指南

中文版项目采用 reStructuredText 纯文本标记语法, 并使用 Sphinx 生成 HTML / CHM / PDF 等文档格式.

·      英文版项目还包含 cpplint - 一个用来帮助适应风格准则的工具, 以及 google-c-style.el, Google 风格的 Emacs 配置文件.

·      另外, 招募志愿者翻译JavaScriptStyle Guide以及 XML Document FormatStyle Guide, 有意者请联系 Yang.Y.

---

2.内容(略)点上述链接访问网站

数据简化社区(Data SimplificationCommunity)遵从Google开源项目风格指南(中文版)/Linux内核代码风格/中英文对照版本。

---

BLinux内核代码风格(16078字)

Linux内核代码风格

文|Linux内核代码风格；数据简化DataSimp©20190105Sat

TheLinux Kernel 4.20.0

·        TheLinux kernel user’s and administrator’s guide

·        TheLinux kernel user-space API guide

·        Workingwith the kernel development community

·        Developmenttools for the kernel

·        Howto write kernel documentation

·        KernelHacking Guides

·        LinuxTracing Technologies

·        KernelMaintainer Handbook

·        TheLinux driver implementer’s API guide

·        CoreAPI Documentation

·        LinuxMedia Subsystem Documentation

·        LinuxNetworking Documentation

·        TheLinux Input Documentation

·        LinuxGPU Driver Developer’s Guide

·        SecurityDocumentation

·        LinuxSound Subsystem Documentation

·        LinuxKernel Crypto API

·        LinuxFilesystems API

·        LinuxMemory Management Documentation

·        BPFDocumentation

·        SuperHInterfaces Guide

·        ext4Data Structures and Algorithms

·        Translations

o            Chinesetranslations

§            Linux内核代码风格

§                 1)缩进

§                 2)把长的行和字符串打散

§                 3)大括号和空格的放置

§                 4)命名

§                 5)Typedef

§                 6)函数

§                 7)集中的函数退出途径

§                 8)注释

§                 9)你已经把事情弄糟了

§                 10)Kconfig 配置文件

§                 11)数据结构

§                 12)宏，枚举和RTL

§                 13)打印内核消息

§                 14)分配内存

§                 15)内联弊病

§                 16)函数返回值及命名

§                 17)不要重新发明内核宏

§                 18)编辑器模式行和其他需要罗嗦的事情

§                 19)内联汇编

§                 20)条件编译

§                 附录 I) 参考

o            Traduzioneitaliana

o            Koreantranslations

o            Japanesetranslations

·        Docs »

·        Translations »

·        Chinesetranslations »

·        Linux 内核代码风格

·        Viewpage source

---

Chinesetranslated version of Documentation/process/coding-style.rst

If you haveany comment or update to the content, please post to LKML directly. However, ifyou have problem communicating in English you can also ask the Chinesemaintainer for help. Contact the Chinese maintainer, if this translation isoutdated or there is problem with translation.

Chinesemaintainer: Zhang Le

https://www.kernel.org/doc/html/latest/translations/zh_CN/coding-style.html

---

Documentation/process/coding-style.rst 的中文翻译

如果想评论或更新本文的内容，请直接发信到LKML。如果你使用英文交流有困难的话， 也可以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版 维护者:

中文版维护者： 张乐 Zhang Le

中文版翻译者： 张乐 Zhang Le

中文版校译者： 王聪 Wang Cong

               wheelz

               管旭东 Xudong Guan

               Li Zefan

               Wang Chen

以下为正文

---

Linux内核代码风格

这是一个简短的文档，描述了 linux 内核的首选代码风格。代码风格是因人而异的， 而且我不愿意把自己的观点强加给任何人，但这就像我去做任何事情都必须遵循的原则那样，我也希望在绝大多数事上保持这种的态度。请 (在写代码时) 至少考虑一下这里的代码风格。

首先，我建议你打印一份 GNU 代码规范，然后不要读。烧了它，这是一个具有重大象征 性意义的动作。

不管怎样，现在我们开始：

1) 缩进

制表符是 8 个字符，所以缩进也是 8 个字符。有些异端运动试图将缩进变为 4 (甚至 2！) 字符深，这几乎相当于尝试将圆周率的值定义为 3。

理由：缩进的全部意义就在于清楚的定义一个控制块起止于何处。尤其是当你盯着你的屏幕连续看了 20 小时之后，你将会发现大一点的缩进会使你更容易分辨缩进。

现在，有些人会抱怨 8 个字符的缩进会使代码向右边移动的太远，在 80 个字符的终端 屏幕上就很难读这样的代码。这个问题的答案是，如果你需要 3 级以上的缩进，不管用 何种方式你的代码已经有问题了，应该修正你的程序。

简而言之，8 个字符的缩进可以让代码更容易阅读，还有一个好处是当你的函数嵌套太 深的时候可以给你警告。留心这个警告。

在switch 语句中消除多级缩进的首选的方式是让 switch 和从属于它的 case 标签对齐于同一列，而不要 两次缩进 case 标签。比如：

switch (suffix){

case 'G':

case 'g':

        mem <<= 30;

        break;

case 'M':

case 'm':

        mem <<= 20;

        break;

case 'K':

case 'k':

        mem <<= 10;

        /* fall through */

default:

        break;

}

不要把多个语句放在一行里，除非你有什么东西要隐藏：

if(condition) do_this;

  do_something_everytime;

也不要在一行里放多个赋值语句。内核代码风格超级简单。就是避免可能导致别人误读的表达式。

除了注释、文档和 Kconfig 之外，不要使用空格来缩进，前面的例子是例外，是有意为 之。

选用一个好的编辑器，不要在行尾留空格。

2) 把长的行和字符串打散

代码风格的意义就在于使用平常使用的工具来维持代码的可读性和可维护性。

每一行的长度的限制是 80 列，我们强烈建议您遵守这个惯例。

长于 80 列的语句要打散成有意义的片段。除非超过 80 列能显著增加可读性，并且不会隐藏信息。子片段要明显短于母片段，并明显靠右。这同样适用于有着很长参数列表 的函数头。然而，绝对不要打散对用户可见的字符串，例如 printk 信息，因为这样就 很难对它们 grep。

3) 大括号和空格的放置

C 语言风格中另外一个常见问题是大括号的放置。和缩进大小不同，选择或弃用某种放置策略并没有多少技术上的原因，不过首选的方式，就像 Kernighan 和Ritchie 展示 给我们的，是把起始大括号放在行尾，而把结束大括号放在行首，所以：

if (x istrue) {

        we do y

}

这适用于所有的非函数语句块 (if, switch, for, while, do)。比如：

switch(action) {

caseKOBJ_ADD:

        return "add";

caseKOBJ_REMOVE:

        return "remove";

caseKOBJ_CHANGE:

        return "change";

default:

        return NULL;

}

不过，有一个例外，那就是函数：函数的起始大括号放置于下一行的开头，所以：

intfunction(int x)

{

        body of function

}

全世界的异端可能会抱怨这个不一致性是... 呃... 不一致的，不过所有思维健全的人 都知道 (a) K&R 是 正确的 并且 (b) K&R 是正确的。此外，不管怎样函数都是特殊的 (C 函数是不能嵌套的)。

注意结束大括号独自占据一行，除非它后面跟着同一个语句的剩余部分，也就是 do 语 句中的 “while” 或者if 语句中的 “else”，像这样：

do {

        body of do-loop

} while(condition);

和

if (x == y){

        ..

} else if(x > y) {

        ...

} else {

        ....

}

理由：K&R。

也请注意这种大括号的放置方式也能使空 (或者差不多空的) 行的数量最小化，同时不 失可读性。因此，由于你的屏幕上的新行是不可再生资源 (想想 25 行的终端屏幕)，你将会有更多的空行来放置注释。

当只有一个单独的语句的时候，不用加不必要的大括号。

if(condition)

        action();

和

if(condition)

        do_this();

else

        do_that();

这并不适用于只有一个条件分支是单语句的情况；这时所有分支都要使用大括号：

if(condition) {

        do_this();

        do_that();

} else {

        otherwise();

}

3.1)空格

Linux 内核的空格使用方式 (主要) 取决于它是用于函数还是关键字。(大多数) 关键字 后要加一个空格。值得注意的例外是 sizeof, typeof, alignof 和 __attribute__，这些关键字某些程度上看起来更像函数 (它们在 Linux 里也常常伴随小括号而使用，尽管在 C 里这样的小括号不是必需的，就像 struct fileinfoinfo; 声明过后的 sizeof info)。

所以在这些关键字之后放一个空格:

if, switch,case, for, do, while

但是不要在 sizeof, typeof, alignof 或者 __attribute__ 这些关键字之后放空格。例如，

s =sizeof(struct file);

不要在小括号里的表达式两侧加空格。这是一个反例 ：

s = sizeof(struct file );

当声明指针类型或者返回指针类型的函数时， * 的首选使用方式是使之靠近变量名 或者函数名，而不是靠近类型名。例子：

char*linux_banner;

unsignedlong long memparse(char *ptr, char **retptr);

char*match_strdup(substring_t *s);

在大多数二元和三元操作符两侧使用一个空格，例如下面所有这些操作符:

=  + -  <  > *  /  % |  &  ^ <=  >=  == !=  ?  :

但是一元操作符后不要加空格:

&  * +  -  ~ !  sizeof  typeof alignof  __attribute__  defined

后缀自加和自减一元操作符前不加空格:

++  --

前缀自加和自减一元操作符后不加空格:

++  --

. 和-> 结构体成员操作符前后不加空格。

不要在行尾留空白。有些可以自动缩进的编辑器会在新行的行首加入适量的空白，然后你就可以直接在那一行输入代码。不过假如你最后没有在那一行输入代码，有些编辑器 就不会移除已经加入的空白，就像你故意留下一个只有空白的行。包含行尾空白的行就 这样产生了。

当git 发现补丁包含了行尾空白的时候会警告你，并且可以应你的要求去掉行尾空白； 不过如果你是正在打一系列补丁，这样做会导致后面的补丁失败，因为你改变了补丁的上下文。

4) 命名

C 是一个简朴的语言，你的命名也应该这样。和 Modula-2 和 Pascal 程序员不同， C 程序员不使用类似 ThisVariableIsATemporaryCounter 这样华丽的名字。C 程序员会 称那个变量为 tmp ，这样写起来会更容易，而且至少不会令其难于理解。

不过，虽然混用大小写的名字是不提倡使用的，但是全局变量还是需要一个具描述性的名字。称一个全局函数为 foo 是一个难以饶恕的错误。

全局变量 (只有当你 真正 需要它们的时候再用它) 需要有一个具描述性的名字，就像全局函数。如果你有一个可以计算活动用户数量的函数，你应该叫它 count_active_users() 或者类似的名字，你不应该叫它 cntuser() 。

在函数名中包含函数类型 (所谓的匈牙利命名法) 是脑子出了问题——编译器知道那些类型而且能够检查那些类型，这样做只能把程序员弄糊涂了。难怪微软总是制造出有问题 的程序。

本地变量名应该简短，而且能够表达相关的含义。如果你有一些随机的整数型的循环计数器，它应该被称为 i 。叫它 loop_counter 并无益处，如果它没有被误解的可能的话。类似的， tmp 可以用来称呼任意类型的临时变量。

如果你怕混淆了你的本地变量名，你就遇到另一个问题了，叫做函数增长荷尔蒙失衡综合症。请看第六章 (函数)。

5) Typedef

不要使用类似 vps_t 之类的东西。

对结构体和指针使用 typedef 是一个 错误 。当你在代码里看到：

vps_t a;

这代表什么意思呢？

相反，如果是这样

structvirtual_container *a;

你就知道 a 是什么了。

很多人认为 typedef 能提高可读性 。实际不是这样的。它们只在下列情况下有用：

1.完全不透明的对象 (这种情况下要主动使用 typedef 来 隐藏 这个对象实际上 是什么)。

例如： pte_t 等不透明对象，你只能用合适的访问函数来访问它们。

Note

不透明性和 “访问函数” 本身是不好的。我们使用pte_t 等类型的原因在于真 的是完全没有任何共用的可访问信息。

2.清楚的整数类型，如此，这层抽象就可以 帮助 消除到底是 int 还是 long 的混淆。

u8/u16/u32 是完全没有问题的 typedef，不过它们更符合类别 (d) 而不是这里。

Note

要这样做，必须事出有因。如果某个变量是 unsigned long ，那么没有必要

typedefunsigned long myflags_t;

不过如果有一个明确的原因，比如它在某种情况下可能会是一个 unsigned int 而在其他情况下可能为 unsigned long ，那么就不要犹豫，请务必使用 typedef。

3.当你使用 sparse 按字面的创建一个新 类型来做类型检查的时候。

4.和标准 C99 类型相同的类型，在某些例外的情况下。

虽然让眼睛和脑筋来适应新的标准类型比如 uint32_t 不需要花很多时间，可 是有些人仍然拒绝使用它们。

因此，Linux 特有的等同于标准类型的 u8/u16/u32/u64 类型和它们的有符号类型是被允许的——尽管在你自己的新代码中，它们不是强制要求要使用的。

当编辑已经使用了某个类型集的已有代码时，你应该遵循那些代码中已经做出的选择。

5.可以在用户空间安全使用的类型。

在某些用户空间可见的结构体里，我们不能要求 C99 类型而且不能用上面提到的 u32 类型。因此，我们在与用户空间共享的所有结构体中使用 __u32 和类似 的类型。

可能还有其他的情况，不过基本的规则是永远不要 使用 typedef，除非你可以明 确的应用上述某个规则中的一个。

总的来说，如果一个指针或者一个结构体里的元素可以合理的被直接访问到，那么它们就不应该是一个 typedef。

6) 函数

函数应该简短而漂亮，并且只完成一件事情。函数应该可以一屏或者两屏显示完 (我们 都知道 ISO/ANSI 屏幕大小是 80x24)，只做一件事情，而且把它做好。

一个函数的最大长度是和该函数的复杂度和缩进级数成反比的。所以，如果你有一个理论上很简单的只有一个很长 (但是简单) 的 case 语句的函数，而且你需要在每个 case 里做很多很小的事情，这样的函数尽管很长，但也是可以的。

不过，如果你有一个复杂的函数，而且你怀疑一个天分不是很高的高中一年级学生可能甚至搞不清楚这个函数的目的，你应该严格遵守前面提到的长度限制。使用辅助函数， 并为之取个具描述性的名字 (如果你觉得它们的性能很重要的话，可以让编译器内联它们，这样的效果往往会比你写一个复杂函数的效果要好。)

函数的另外一个衡量标准是本地变量的数量。此数量不应超过 5－10 个，否则你的函数 就有问题了。重新考虑一下你的函数，把它分拆成更小的函数。人的大脑一般可以轻松的同时跟踪 7 个不同的事物，如果再增多的话，就会糊涂了。即便你聪颖过人，你也可 能会记不清你 2 个星期前做过的事情。

在源文件里，使用空行隔开不同的函数。如果该函数需要被导出，它的EXPORT宏 应该紧贴在它的结束大括号之下。比如：

intsystem_is_up(void)

{

        return system_state == SYSTEM_RUNNING;

}

EXPORT_SYMBOL(system_is_up);

在函数原型中，包含函数名和它们的数据类型。虽然 C 语言里没有这样的要求，在 Linux 里这是提倡的做法，因为这样可以很简单的给读者提供更多的有价值的信息。

7) 集中的函数退出途径

虽然被某些人声称已经过时，但是 goto 语句的等价物还是经常被编译器所使用，具体 形式是无条件跳转指令。

当一个函数从多个位置退出，并且需要做一些类似清理的常见操作时，goto 语句就很方 便了。如果并不需要清理操作，那么直接 return 即可。

选择一个能够说明 goto 行为或它为何存在的标签名。如果 goto 要释放 buffer, 一个不错的名字可以是 out_free_buffer: 。别去使用像 err1: 和 err2: 这样的GW_BASIC名称，因为一旦你添加或删除了 (函数的) 退出路径，你就必须对它们重新编号，这样会难以去检验正确性。

使用 goto 的理由是：

·      无条件语句容易理解和跟踪

·      嵌套程度减小

·      可以避免由于修改时忘记更新个别的退出点而导致错误

·      让编译器省去删除冗余代码的工作;)

int fun(inta)

{

        int result = 0;

        char *buffer;

 

        buffer = kmalloc(SIZE, GFP_KERNEL);

        if (!buffer)

                return -ENOMEM;

 

        if (condition1) {

                while (loop1) {

                        ...

                }

                result = 1;

                goto out_free_buffer;

        }

        ...

out_free_buffer:

        kfree(buffer);

        return result;

}

一个需要注意的常见错误是 一个 err 错误 ，就像这样：

err:

        kfree(foo->bar);

        kfree(foo);

        return ret;

这段代码的错误是，在某些退出路径上 foo 是 NULL。通常情况下，通过把它分离 成两个错误标签 err_free_bar: 和 err_free_foo: 来修复这个错误：

err_free_bar:

       kfree(foo->bar);

err_free_foo:

       kfree(foo);

       return ret;

理想情况下，你应该模拟错误来测试所有退出路径。

8) 注释

注释是好的，不过有过度注释的危险。永远不要在注释里解释你的代码是如何运作的：更好的做法是让别人一看你的代码就可以明白，解释写的很差的代码是浪费时间。

一般的，你想要你的注释告诉别人你的代码做了什么，而不是怎么做的。也请你不要把注释放在一个函数体内部：如果函数复杂到你需要独立的注释其中的一部分，你很可能 需要回到第六章看一看。你可以做一些小注释来注明或警告某些很聪明 (或者槽糕) 的 做法，但不要加太多。你应该做的，是把注释放在函数的头部，告诉人们它做了什么，也可以加上它做这些事情的原因。

当注释内核 API 函数时，请使用 kernel-doc 格式。请看 Documentation/doc-guide/ 和scripts/kernel-doc 以获得详细信息。

长(多行) 注释的首选风格是：

/*

 * This is the preferred style for multi-line

 * comments in the Linux kernel source code.

 * Please use it consistently.

 *

 * Description: A column of asterisks on the left side,

 * with beginning and ending almost-blanklines.

 */

对于在 net/ 和 drivers/net/ 的文件，首选的长 (多行) 注释风格有些不同。

/* The preferredcomment style for files in net/ and drivers/net

 * looks like this.

 *

 * It is nearly the same as the generallypreferred comment style,

 * but there is no initial almost-blank line.

 */

注释数据也是很重要的，不管是基本类型还是衍生类型。为了方便实现这一点，每一行应只声明一个数据 (不要使用逗号来一次声明多个数据)。这样你就有空间来为每个数据写一段小注释来解释它们的用途了。

9) 你已经把事情弄糟了

这没什么，我们都是这样。可能你的使用了很长时间 Unix 的朋友已经告诉你 GNU emacs 能自动帮你格式化 C 源代码，而且你也注意到了，确实是这样，不过它 所使用的默认值和我们想要的相去甚远(实际上，甚至比随机打的还要差——无数个猴子 在 GNUemacs 里打字永远不会创造出一个好程序) (译注：InfiniteMonkey Theorem)

所以你要么放弃 GNU emacs，要么改变它让它使用更合理的设定。要采用后一个方案， 你可以把下面这段粘贴到你的 .emacs 文件里。

(defunc-lineup-arglist-tabs-only (ignored)

  "Line up argument lists by tabs, notspaces"

  (let* ((anchor (c-langelem-posc-syntactic-element))

         (column (c-langelem-2nd-posc-syntactic-element))

         (offset (- (1+ column) anchor))

         (steps (floor offset c-basic-offset)))

    (* (max steps 1)

       c-basic-offset)))

 

(add-hook'c-mode-common-hook

          (lambda ()

            ;; Add kernel style

            (c-add-style

             "linux-tabs-only"

             '("linux"(c-offsets-alist

                        (arglist-cont-nonempty

                         c-lineup-gcc-asm-reg

                        c-lineup-arglist-tabs-only))))))

 

(add-hook'c-mode-hook

          (lambda ()

            (let ((filename (buffer-file-name)))

              ;; Enable kernel mode for theappropriate files

              (when (and filename

                         (string-match(expand-file-name "~/src/linux-trees")

                                       filename))

                (setq indent-tabs-mode t)

                (setq show-trailing-whitespacet)

                (c-set-style"linux-tabs-only")))))

这会让 emacs 在 ~/src/linux-trees 下的 C 源文件获得更好的内核代码风格。

不过就算你尝试让 emacs 正确的格式化代码失败了，也并不意味着你失去了一切：还可 以用 indent。

不过，GNU indent 也有和 GNU emacs 一样有问题的设定，所以你需要给它一些命令选项。不过，这还不算太糟糕，因为就算是 GNU indent 的作者也认同K&R 的权威性 (GNU 的人并不是坏人，他们只是在这个问题上被严重的误导了)，所以你只要给 indent 指定选项-kr -i8 (代表 K&R，8 字符缩进)，或使用 scripts/Lindent 这样就可以以最时髦的方式缩进源代码。

indent 有很多选项，特别是重新格式化注释的时候，你可能需要看一下它的手册。不过记住： indent 不能修正坏的编程习惯。

（余略）

附录 I) 参考

The CProgramming Language, 第二版 作者：Brian W. Kernighan 和 DenniM. Ritchie. Prentice Hall, Inc., 1988. ISBN 0-13-110362-8 (软皮), 0-13-110370-9 (硬皮).

ThePractice of Programming 作者：Brian W. Kernighan 和 Rob Pike.Addison-Wesley, Inc., 1999. ISBN 0-201-61586-X.

GNU 手册 - 遵循 K&R 标准和此文本- cpp, gcc, gcc internals and indent, 都可以从 http://www.gnu.org/manual/找到

WG14 是C 语言的国际标准化工作组，URL: http://www.open-std.org/JTC1/SC22/WG14/

Kernelprocess/coding-style.rst，作者 [email protected]发表于 OLS 2002： http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/

---

© CopyrightThe kernel development community.

Built with Sphinx using a theme provided by Read the Docs.

(注2：选自Linux内核代码风格[4])

 

转载本公号文章请注明作者、出处、时间等信息，如“此文转自©微信公号：数据简化DataSimp，作者：秦陇纪等，时间：2016.3.15Tue译编。”字样，详情邮件咨询[email protected]，转载请保留本信息。本公号文章保留一切权利，如有引文/译注/出处不明或遗漏、版权问题等，请给公号回复消息留言，或发邮件到[email protected]。欢迎数据科学和人工智能学界、产业界同仁赐稿，投稿邮箱[email protected]，范围：AI/语言处理/数据/智能等科学技术论文。

免责说明：以上内容来自Google C++ Style Guide Table of Contents，已获作者授权。文章只为学术新闻信息传播，注明出处文字参考文献可溯源。本公众号不持有任何倾向性，亦不表示认可其观点或其所述。

 

改革开放40周年，谨向改革者致敬。我国教育太粗浅落后，文字化基础教育应该缩减到十年内，应该全民普及本科教育，发展研究和合作教育。书从何来、读书做甚？应反思并校正当今社会脱离低层、权力黑箱、信息封闭、泛管教化、毫无民主、阉割人性之弊。秦陇纪提议开学后9月10日设置学习节，号召温故知新、终身学习；9月28日孔子阳历诞辰设为教师节，号召全人类树立温故知新素养；整个9月份定位公民学习月，加强传统、文艺、科技、产品、时事的知识学习。十一国庆节后，设置国情宣传周、选举人演讲周、投票选举月，十月份定位国家公民月。全年做生活实践、校园实验、社会实习，文化辅之；3-9月份则以感受、认知、实践、实验、协作、实习为主。

—END—

 

---

 

参考文献(868字)

1. zh-google-styleguide/zh-google-styleguide.Google 开源项目风格指南 (中文版).[EB/OL]; github, https://github.com/zh-google-styleguide/zh-google-styleguide, visiting data: 2019-01-05.

2. © CopyrightRevision f837c554. Built with Sphinx using a theme provided by Read the Docs. Google开源项目风格指南.[EB/OL]; Read the Docs.,https://zh-google-styleguide.readthedocs.io/en/latest/, visiting data: 2019-01-05.

3. Google. Google C++Style Guide: Table of Contents.[EB/OL]; Google, http://google.github.io/styleguide/cppguide.html, visiting data: 2019-01-05.

4. ©Copyright The kernel development community．Linux内核代码风格．[EB/OL]；数据简化DataSimp．https://www.kernel.org/doc/html/latest/translations/zh_CN/coding-style.html，2019-01-05，访问日期：2019-01-05．

x.秦陇纪．数据简化社区Python官网Web框架概述；数据简化社区2018年全球数据库总结及18种主流数据库介绍；数据科学与大数据技术专业概论；人工智能研究现状及教育应用；信息社会的数据资源概论；纯文本数据溯源与简化之神经网络训练；大数据简化之技术体系．[EB/OL]；数据简化DataSimp(微信公众号)，http://www.datasimp.org，2017-06-06．

数据简化社区Google和Linux代码风格指南(21195字)

(标题下「数据简化DataSimp」文字链接，点击后继续点“关注”接收推送)

秦陇纪©2010-2019数据简化DataSimp

简介：数据简化社区Google和Linux代码风格指南。作者：谷歌、Lunix等。来源：Google开源项目风格指南(中文版)/Linux内核代码风格/数据简化社区/秦陇纪微信群聊公众号，参考文献附引文出处。公号输入栏回复关键字“代码风格”或文末链接“阅读原文”可下载本文24k字1图22页PDF资料；标题下蓝链接“数据简化DataSimp”关注后，菜单项有文章分类页。

主编译者：秦陇纪，数据简化DataSimp/科学Sciences/知识简化新媒体创立者，数据简化社区创始人，数据简化OS设计师/架构师，ASM/Cs/Java/Python/Prolog程序员，英语/设计/IT教师。每天大量中英文阅读/设计开发调试/文章汇译编简化，时间精力人力有限，欢迎支持加入社区。版权声明：科普文章仅供学习研究，公开资料©版权归原作者，请勿用于商业非法目的。秦陇纪2018数据简化DataSimp综合汇译编，投稿合作、转载授权/侵权、原文引文错误等请联系[email protected]沟通。社区媒体：“数据简化DataSimp、科学Sciences、知识简化”新媒体聚集专业领域一线研究员；研究技术时也传播知识、专业视角解释和普及科学现象和原理，展现自然社会生活之科学面。秦陇纪发起，期待您参与各领域；欢迎分享、赞赏、支持科普~~

---

Appx(1236字).数据简化DataSimp社区简介

信息社会之数据、信息、知识、理论持续累积，远超个人认知学习的时间、精力和能力。必须行动起来，解决这个问题。应对大数据时代的数据爆炸、信息爆炸、知识爆炸，解决之道重在数据简化(Data Simplification)：简化减少知识、媒体、社交数据，使信息、数据、知识越来越简单，符合人与设备的负荷。(秦陇纪，2010)

数据简化DataSimp年度会议(DS2010-2019)，聚焦数据简化技术(Data Simplification Techniques)：对各类数据从采集、处理、存储、阅读、分析、逻辑、形式等方面做简化，应用于信息及数据系统、知识工程、各类数据库、物理空间表征、生物医学数据，数学统计、自然语言处理、机器学习技术、人工智能等领域。欢迎数据科学技术、简化实例相关论文投稿加入数据简化社区，参加会议出版专著。请投会员邮箱[email protected]，详情访问社区网站www.datasimp.org。填写申请表加入数据简化DataSimp社区成员，应至少有一篇数据智能、编程开发IT文章：①原创数据智能科技论文；②数据智能工程技术开源程序代码；③翻译美欧数据智能科技论文；④社区网站发帖人管理员版主志愿者义工；⑤完善黑白静态和三彩色动态社区S圈型LOGO图标。DataSimplification/Sciences/Knowledge Simplification Public Accounts——[email protected], 2018.12.12Wed,Xi'an, Shaanxi, China.

LIFE

Lifebegins at the end of your comfort zone.——Neale Donald Walsch

THEDAY

Thestrength of purpose and the clarity of your vision，alongwith the tenacity to pursue it，is your underlying driver ofsuccess.——Ragy Tomas

投稿QQ群223518938数据简化DataSimp社区；技术公众号“数据简化DataSimp”留言，或(备注：姓名/单位-职务/学校-专业/手机号)加微信账号QinlongGEcai，进“数据简化DataSimp社区”投稿群或“科学Sciences学术文献”读者群等群聊。关注如下三个公众号(搜名称也行)，关注后底部菜单有文章分类页链接。

数据技术公众号“数据简化DataSimp”：

科普公众号“科学Sciences”：

社会教育知识公众号“知识简化”：

(转载请写出处：©数据简化DataSimp2010-2018汇译编，欢迎技术、传媒伙伴投稿、加入数据简化社区！“数据简化DataSimp、科学Sciences、知识简化”投稿反馈邮箱[email protected]。)

普及科学知识，分享到朋友圈

转发/留言/打赏后“阅读原文”下载PDF

阅读原文

微信扫一扫
关注该公众号