(转)谷歌编程风格指南_C语言版
来源:互联网 发布:淘宝清洗已过期 编辑:程序博客网 时间:2024/05/21 01:31
一、头文件
通常,每一个.cc文件( C++的源文件)都有一个对应的.h文件(头文件),也有一些例外,如单元测试代码和只包含main()的.cc文件。 正确使用头文件可令代码在可读性、文件大小和性能上大为改观。 下面的规则将引导你规避使用头文件时的各种麻烦。
1.自包含头文件(感觉这部分得好好消化下,目前没思路)
头文件应该自包含(即自需要编译他们自己),以及以.h结尾。非头文件想要被包含的话,应该以.inc结尾。
所有的头文件都应该自包含。用户和重构工具不应该遵从特殊条件去包含头文件。特别地,一个头文件应该有头部保护,包含它需要的所有头文件。
如果一个模版或者内联函数在.h文件中做了声明,相同的头文件就会提供它的定义。这些定义会被包含到使用它的.c文件中,否则程序就会连接失败。不要把定义分开到
2.#define的保护
所有头文件都应该使用#define防止头文件被多重包含( multipleinclusion) ,命名格式应该是:H
为保证唯一性,头文件的命名应基于所在项目源码树的全路径。例如,项目foo中的头文件foo/src/bar/baz.h,应该按如下方式保护:
#ifndef FOO_BAR_BAZ_H_#define FOO_BAR_BAZ_H_...#endif //FOO_BAR_BAZ_H_
前置声明(C++专有)
内联函数(C++专有)
-inl.h文件(C++专有)
包含文件的名称及次序
将包含次序标准化可增强可读性、避免隐藏依赖,次序如下:关联头文件、C库、C++库、其他库的.h、项目内的.h。
项目内头文件应按照项目源代码目录树结构排列,并且避免使用UNIX文件路径.(当前目录)和..(父目录)。例如, google-awesome-project/src/base/logging.h应像这样被包含:
#include "base/logging.h"
dir/foo.cc 的主要作用是执行或测试dir2/foo2.h的功能,foo.cc中包含头文件的次序如下:
1.dir2/foo2.h2.C系统文件3.C++系统文件4.其他库头文件5.本项目内头文件
这种排序方式可有效减少隐藏依赖,如果 dir2/foo2.h 遗漏了任何必要的包含,那编译 dir/foo.cc 时就会中断。这个规则保证了编译中断会率先出现在那些处理当前文件的人面前,而不是别的包中的无关的人。
dir/foo.cc和dir2/foo2.h通常位于相同目录下(像 base/basictypes_unittest.cc和 base/basictypes.h),但也可在不同目录下。
相同目录下头文件按字母序是不错的选择。
举例来说,google-awesome-project/src/foo/internal/fooserver.cc的包含次序如下:
#include "foo/public/fooserver.h"#include <sys/types.h>#include <unistd.h>#include <hash_map>#include <vector>#include "base/basictypes.h"#include "base/commandlineflags.h"#include "foo/public/bar.h
二、作用域
名称污染。本节大部分是C++的知识,对于C,可以借鉴的是这个名词“名称污染”。就像模块内部的变量最好用结构体括起来,防止污染。
三、类
四、函数
参数顺序
编写短小函数
记住一点,编写短小函数。
五、Google特有的风情
六、其他C++特性
sizeof
尽可能用sizeof(varname)代替sizeof(type)。 使用sizeof(varname)是因为当变量类型改变时代码自动同步,有些情况下sizeof(type)或许有意义,还是要尽量避免,如果变量类型改变的话不能同步。
Struct data;memset(&data, 0, sizeof(data));memset(&data, 0, sizeof(Struct));// 不好的方式
七、命名
重要的一致性规则是命名管理,命名风格直接可以直接确定命名实体是:类型、变量、函数、常量、宏等等,无需查找实体声明,我们大脑中的模式匹配引擎依赖于这些命名规则。命名规则具有一定随意性,但相比按个人喜好命名,一致性更重要,所以不管你怎么想,规则总归是规则。
- 通用命名规则
函数命名、变量命名、文件命名应具有描述性,不要过度缩写。
尽可能给出描述性名称,不要节约空间,让别人很快理解你的代码更重要,不要使用模糊的缩写或随意的字符。
int price_count_reader; // No abbreviation.int num_errors; // "num" is a widespread convention.int num_dns_connections; // Most people know what "DNS" stands for.int n; // Meaningless.int nerr; // Ambiguous abbreviation.int n_comp_conns; // Ambiguous abbreviation.int wgc_connections; // Only your group knows what this stands for.int pc_reader; // Lots of things can be abbreviated "pc".int cstmr_id; // Deletes internal letters.
- 文件命名
文件名要全部小写,可以包含下划线()或短线(-),按项目约定来,如果没有的话最好用”“。 可接受的文件命名:
my_useful_class.ccmy-useful-class.ccmyusefulclass.ccmyusefulclass_test.cc // _unittest and _regtest are deprecated.
C++文件以.cc结尾,头文件以.h结尾。
不要使用已经存在于/usr/include下的文件名,如db.h。
通常,尽量让文件名更加明确,http_server_logs.h就比logs.h要好,定义类时文件名一般成对出现,如foo_bar.h和foo_bar.cc,对应类FooBar。
- 类型命名
类型命名每个单词以大写字母开头,不包含下划线: MyExcitingClass、 MyExcitingEnum。
所有类型命名——类、结构体、类型定义( typedef)、枚举——使用相同约定,例如:
// classes and structsclass UrlTable { ...class UrlTableTester { ...struct UrlTableProperties { ...// typedefstypedef hash_map<UrlTableProperties *, string> PropertiesMap;// enumsenum UrlTableErrors { ..
- 变量命名
变量名一律小写,单词间以下划线相连,如
my_exciting_local_variable
普通变量命名:
举例:
string table_name; // OK - uses underscore.string tablename; // OK - all lowercase.string tableName; // Bad - mixed case.
全局变量:
对全局变量没有特别要求,少用就好,可以以g_或其他易与局部变量区分的标志为前缀。
- 常量命名
在名称前加k: kDaysInAWeek。
所有编译时常量(无论是局部的、全局的还是类中的)和其他变量保持些许区别,k后接大写字母开头的单词:
const int kDaysInAWeek = 7
- 函数命名
函数名以大写字母开头,每个单词首字母大写(这是大驼峰命名法或者叫帕斯卡命名法)。单词间没有下划线。如果有大写字母缩写词,倾向于把它当作单个词(例如 StartRpc()而不是 StartRPC()):
AddTableEntry()DeleteUrl()OpenFileOrDie()
- 枚举命名
枚举值可以像常量那样,也可以像宏那样,kEnumName 或者 ENUM_NAME。
独立枚举值倾向于像常量那样命名,但是也接受像宏那样命名。像UrlTableErrors这样的枚举名称属于类型,因此大小写混合。
enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, kErrorMalformedInput,};enum AlternateUrlTableErrors { OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2,};
从2009年1月之前,枚举值的风格都和宏一样。这样比较容易导致命名冲突,因此改为推荐常量枚举命名风格。如果可以的话,新代码尽量使用常量风格来命名。没必要去把老代码都改为常量风格,除非引起了编译错误。
- 宏命名
你并不打算使用宏,对吧?如果使用,像这样:
MY_MACRO_THAT_SCARES_SMALL_CHILDREN。
参考第四篇预处理宏, 通常是不使用宏的, 如果绝对要用, 其命名像枚举命名一样全部大写、 使用下划线:
#define ROUND(x) ...#define PI_ROUNDED 3.0
八、注释
注释虽然写起来很痛苦,但对保证代码可读性至为重要,下面的规则描述了应该注释什么、注释在哪儿。当然也要记住,注释的确很重要,但最好的代码本身就是文档( selfdocumenting),类型和变量命名意义明确要比通过注释解释模糊的命名好得多。注释是为别人(下一个需要理解你的代码的人) 而写的,认真点吧, 那下一个人可能就是你!
- 注释风格
使用//或/* */,统一就好。
//或/* */都可以, //只是用的更加广泛,在如何注释和注释风格上确保统一。
- 文件注释
在每一个文件开头加入版权公告。
文件注释描述了文件的内容。基本所有的文件都应该要有文件注释:
许可和作者
每个文件都应该有许可证,为项目选择合适的许可证版本,如Apache 2.0、BSD、 LGPL、 GPL; 如果你为一个文件做出巨大改变,可以加上自己名字。
文件内容:
通常,.h文件要对所声明的类的功能和用法作简单说明,.cc文件包含了更多的实现细节或算法讨论,如果你感觉这些实现细节或算法讨论对于阅读有帮助,可以把.cc中的注释放到.h中,并在.cc中指出文档在.h中。
不要单纯在.h和.cc间复制注释,复制的注释偏离了实际意义。
- 函数注释
函数声明: 注释于声明之前,描述函数功能及用法,注释使用描述式( “Opens the file”)而非指令式( “Open the file”);注释只是为了描述函数而不是告诉函数做什么。通常,注释不会描述函数如何实现,那是定义部分的事情。
函数声明处注释的内容:
1) inputs(输入) 及 outputs(输出) ;
2) 对类成员函数而言:函数调用期间对象是否需要保持引用参数,是否会释放这些参数;
3) 如果函数分配了空间,需要由调用者释放;
4) 参数是否可以为NULL;
5) 是否存在函数使用的性能隐忧( performance implications) ;
6) 如果函数是可重入的( re-entrant) ,其同步前提( synchronization assumptions)是什么?
举例如下:
// Returns an iterator for this table. It is the client's// responsibility to delete the iterator when it is done with it,// and it must not use the iterator once the GargantuanTable object// on which the iterator was created has been deleted.//// The iterator is initially positioned at the beginning of the table.//// This method is equivalent to:// Iterator* iter = table->NewIterator();// iter->Seek("");// return iter;// If you are going to immediately seek to another place in the// returned iterator, it will be faster to use NewIterator()// and avoid the extra seek.Iterator* GetIterator() const;
但不要有无谓冗余或显而易见的注释,下面的注释就没有必要加上“returns false otherwise”,因为已经暗含其中了:
// Returns true if the table cannot hold any more entries.bool IsTableFull();
函数定义:
每个函数定义时要以注释说明函数功能和实现要点,如使用的漂亮代码、实现的简要步骤、如此实现的理由、为什么前半部分要加锁而后半部分不需要。不要从.h文件或其他地方的函数声明处直接复制注释,简要说明函数功能是可以的,但重点要放在如何实现上。
- 变量注释
通常变量名本身足以很好说明变量用途,特定情况下,需要额外注释说明。
全局变量(常量):
和数据成员相似,所有全局变量(常量)也应注释说明含义及用途,如:
// The total number of tests cases that we run through in this regression test.const int kNumTestCases = 6;
- 实现注释
对于实现代码中巧妙的、晦涩的、有趣的、重要的地方加以注释。
代码前注释:
出彩的或复杂的代码块前要加注释,如:
// Divide result by two, taking into account that x// contains the carry from the add.for (int i = 0; i < result->size(); i++) {x= (x << 8) + (*result)[i];(*result)[i] = x >> 1;x &= 1;}
行注释:
比较隐晦的地方要在行尾加入注释,可以在代码之后空两格加行尾注释,如:
// If we have enough memory, mmap the data portion too.mmap_budget = max<int64>(0, mmap_budget - index_->length());if (mmap_budget >= data_size_ && !MmapData(mmap_chunk_bytes, mlock)) return; // Error already logged.
注意,有两块注释描述这段代码,当函数返回时注释提及错误已经被记入日志。
前后相邻几行都有注释,可以适当调整使之可读性更好:
DoSomething(); // Comment here so the comments line up.DoSomethingElseThatIsLonger(); // Two spaces between the code and the comment.{ // One space before comment when opening a new scope is allowed, // thus the comment lines up with the following comments and code. DoSomethingElse(); // Two spaces before line comments normally.}vector<string> list{// Comments in braced lists describe the next element .. "First item", // .. and should be aligned appropriately. "Second item"};DoSomething(); /* For trailing block comments, one space is fine. */
- 标点、拼写和语法
留意标点、拼写和语法,写的好的注释比差的要易读的多。
注释一般是包含适当大写和句点( .)的完整的句子,短一点的注释(如代码行尾的注释)可以随意点, 依然要注意风格的一致性。 完整的句子可读性更好, 也可以说明该注释是完整的而不是一点不成熟的想法。
虽然被别人指出该用分号( semicolon) 的时候用了逗号( comma) 有点尴尬。清晰易读的代码还是很重要的,适当的标点、拼写和语法对此会有所帮助。
- TODO注释
对那些临时的、短期的解决方案,或已经够好但并不完美的代码使用TODO注释。
这样的注释要使用全大写的字符串TODO,后面括号( parentheses) 里加上你的大名、邮件地址等,还可以加上冒号( colon):目的是可以根据统一的TODO格式进行查找:
// TODO(kl@gmail.com): Use a "*" here for concatenation operator.// TODO(Zeke) change this to use relations.// TODO(bug 12345): remove the "Last visitors" feature
如果加上是为了在“将来某一天做某事”,可以加上一个特定的时间( “Fix by November 2005”)或事件( “Remove this code when all clients can handle XML responses.”)。
九、格式
代码风格和格式确实比较随意,但一个项目中所有人遵循同一风格是非常容易的,作为个人未必同意下述格式规则的每一处,但整个项目服从统一的编程风格是很重要的,这样做才能让所有人在阅读和理解代码时更加容易。
- 行长度
每一行代码字符数不超过80。
我们也认识到这条规则是存有争议的,但如此多的代码都遵照这一规则,我们感觉一致性更重要。
优点:
提倡该原则的人认为强迫他们调整编辑器窗口大小很野蛮。很多人同时并排开几个窗口,根本没有多余空间拓宽某个窗口,人们将窗口最大尺寸加以限定,一致使用80列宽,为什么要改变呢?
缺点:
反对该原则的人则认为更宽的代码行更易阅读,80列的限制是上个世纪60年代的大型机的古板缺陷;现代设备具有更宽的显示屏,很轻松的可以显示更多代码。
结论:
80个字符是最大值。
例外:
1) 如果一行注释包含了超过80字符的命令或URL,出于复制粘贴的方便可以超过80字符;
2) 包含长路径的可以超出80列,尽量避免;
3) 头文件保护(防止重复包含)可以无视该原则。
- 非ASCII字符
尽量不使用非ASCII字符,使用时必须使用UTF-8格式。
哪怕是英文,也不应将用户界面的文本硬编码到源代码中,因此非ASCII字符要少用。特殊情况下可以适当包含此类字符,如,代码分析外部数据文件时,可以适当硬编码数据文件中作为分隔符的非ASCII字符串;更常用的是(不需要本地化的)单元测试代码可能包含非ASCII字符串。此类情况下,应使用UTF-8格式,因为很多工具都可以理解和处理其编码,十六进制编码也可以,尤其是在增强可读性的情况下——如”\xEF\xBB\xBF”是Unicode的zero-width no-break space字符,以UTF-8格式包含在源文件中是不可见的。
- 空格和Tabs
只使用空格,每次缩进2个空格。
使用空格进行缩进,不要在代码中使用tabs,设定编辑器将tab转为空格。
- 函数声明与定义
返回类型和函数名在同一行,合适的话,参数也放在同一行。
函数看上去像这样:
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { DoSomething(); ...}
如果同一行文本较多,容不下所有参数:
ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2, Type par_name3) { DoSomething(); ...}
甚至连第一个参数都放不下:
ReturnType LongClassName::ReallyReallyReallyLongFunctionName( Type par_name1, // 4 space indent Type par_name2, Type par_name3) { DoSomething(); // 2 space indent ...}
注意以下几点:
选择好的参数名字。
如果参数没用的话,参数名可以不要。
返回值总是和函数名在同一行。
函数声明和定义的返回类型的地方不要留空格。
左圆括号(open parenthesis)总是和函数名在同一行。
函数名和左圆括号间没有空格。
圆括号与参数间没有空格。
左大括号(open curly brace)总在最后一个参数同一行的末尾处,不是新的一行。
右大括号(close curly brace)总是单独位于函数最后一行。
右圆括号(close parenthesis)和左大括号间总是有一个空格。
所有形参应尽可能对齐。
缺省缩进为2个空格。
独立封装的参数保持4个空格的缩进。
class Foo { public: Foo(Foo&&); Foo(const Foo&); Foo& operator=(Foo&&); Foo& operator=(const Foo&);};class Shape { public: virtual void Rotate(double radians) = 0;};class Circle : public Shape { public: void Rotate(double radians) override;};void Circle::Rotate(double /*radians*/) {}// Bad - if someone wants to implement later, it's not clear what the// variable means.void Circle::Rotate(double) {}Attributes, and macros that expand to attributes, appear at the very beginning of the function declaration or definition, before the return type:MUST_USE_RESULT bool IsOK();
- 函数调用
尽量放在同一行,否则,将实参封装在圆括号中。 函数调用遵循如下形式:
bool result = DoSomething(argument1, argument2, argument3);
如果同一行放不下,可断为多行,后面每一行都和第一个实参对齐,左圆括号后和右圆括号前不要留空格:
bool result = DoSomething(averyveryveryverylongargument1, argument2, argument3);
参数也可以紧随函数调用之后4个空格缩进:
if (...) { ... ... if (...) { bool result = DoSomething( argument1, argument2, // 4 space indent argument3, argument4); ... }
有时为了可读性,也可以这样排版:
// Transform the widget by a 3x3 matrix.my_widget.Transform(x1, x2, x3, y1, y2, y3, z1, z2, z3);
- 条件语句
提倡不在圆括号中添加空格,关键字else另起一行。
对基本条件语句有两种可以接受的格式,一种在圆括号和条件之间有空格,一种没有。
最常见的是没有空格的格式,那种都可以,还是一致性为主。如果你是在修改一个文件,参考当前已有格式;如果是写新的代码,参考目录下或项目中其他文件的格式,还在徘徊的话,就不要加空格了。
if (condition) { // no spaces inside parentheses... // 2 space indent.} else { // The else goes on the same line as the closing brace....}
如果你倾向于在圆括号内部加空格:
if ( condition ) { // spaces inside parentheses - rare... // 2 space indent.} else { // The else goes on the same line as the closing brace....}
注意所有情况下if和左圆括号间有个空格,右圆括号和左大括号(如果使用的话)间也要有个空格:
if(condition) // Bad - space missing after IF.if (condition){ // Bad - space missing before {.if(condition){ // Doubly bad.if (condition) { // Good - proper space after IF and before {.
有些条件语句写在同一行以增强可读性,只有当语句简单并且没有使用else子句时使用:
if (x == kFoo) return new Foo();if (x == kBar) return new Bar();
如果语句有else分支是不允许的:
// Not allowed - IF statement on one line when there is an ELSE clauseif (x) DoThis();else DoThat();
通常,单行语句不需要使用大括号,如果你喜欢也无可厚非,也有人要求if必须使用大括号:
if (condition) DoSomething(); // 2 space indent.if (condition) { DoSomething(); // 2 space indent.}
但如果语句中哪一分支使用了大括号的话,其他部分也必须使用:
// Not allowed - curly on IF but not ELSEif (condition) { foo;} else bar;// Not allowed - curly on ELSE but not IFif (condition) foo;else { bar;}// Curly braces around both IF and ELSE required because// one of the clauses used braces.if (condition) { foo;} else { bar;}
- 循环和switch选择语句
switch语句可以使用大括号分块;空循环体应使用{}或continue。
switch语句中的case块可以使用大括号也可以不用,取决于你的喜好,使用时要依下文所述。
如果有不满足case枚举条件的值,要总是包含一个default(如果有输入值没有case去处理,编译器将报警)。如果default永不会执行,可以简单的使用assert:
switch (var) { case 0: { // 2 space indent ... // 4 space indent break; } case 1: { ... break; } default: { assert(false); }}
单句声明的循环体中,括号是可选的。
for (int i = 0; i < kSomeNumber; ++i) printf("I love you\n");for (int i = 0; i < kSomeNumber; ++i) { printf("I take it back\n");}
空循环,要用括号或者continue,而不能直接用个分号。
while (condition) { // Repeat test until it returns false.}for (int i = 0; i < kSomeNumber; ++i) {} // Good - empty body.while (condition) continue; // Good - continue indicates no logic.while (condition); // Bad - looks like part of do/while loop.
- 指针和引用表达式
箭头(->)前后不要有空格,指针/地址操作符(*、&)后不要有空格。
下面是指针和引用表达式的正确范例:
x = *p;p = &x;x = r->y;
注意:
在访问成员时,箭头前后没有空格;
指针操作符*或&后没有空格。
在声明指针变量或参数时,星号与类型或变量名紧挨都可以:
// These are fine, space preceding.char *c;const string &str;// These are fine, space following.char* c; // but remember to do "char* c, *d, *e, ...;"!const string& str;char * c; // Bad - spaces on both sides of *const string & str; // Bad - spaces on both sides of &
同一个文件(新建或现有)中起码要保持一致。
- 布尔表达式
如果一个布尔表达式超过标准行宽(0字符),如果断行要统一一下。 下例中,逻辑与(&&)操作符总位于行尾:
if (this_one_thing > this_other_thing && a_third_thing == a_fourth_thing && yet_another & last_one) { ...}
两个逻辑与(&&)操作符都位于行尾,可以考虑额外插入圆括号,合理使用的话对增强可读性是很有帮助的。
- 返回值
return表达式中不要使用圆括号。
return result; // No parentheses in the simple case.// Parentheses OK to make a complex expression more readable.return (some_long_condition && another_condition);return (value); // You wouldn't write var = (value);return(result); // return is not a function!
- 变量及数组初始化
选择=还是()。 需要做二者之间做出选择,下面的形式都是正确的:
int x = 3;int x(3);string name("Some Name");string name = "Some Name"
- 预处理指令
预处理指令不要缩进,从行首开始。 即使预处理指令位于缩进代码块中,指令也应从行首开始。
// Good - directives at beginning of line if (lopsided_score) {#if DISASTER_PENDING // Correct -- Starts at beginning of line DropEverything();# if NOTIFY // OK but not required -- Spaces after # NotifyClient();# endif#endif BackToNormal(); }// Bad - indented directives if (lopsided_score) { #if DISASTER_PENDING // Wrong! The "#if" should be at beginning of line DropEverything(); #endif // Wrong! Do not indent "#endif" BackToNormal(); }
- 水平留白
水平留白的使用因地制宜。不要在行尾添加无谓的留白。
通常:
void f(bool b) { // Open braces should always have a space before them. ...int i = 0; // Semicolons usually have no space before them.// Spaces inside braces for braced-init-list are optional. If you use them,// put them on both sides!int x[] = { 0 };int x[] = {0};
添加冗余的留白会给其他人编辑时造成额外负担,例如在他们合并代码的时候,即使他们可以去除掉这个空格。因此,不要引入多余的空格。如果你不小心引入了多余的空格要尽快去掉,或者在专门清理空格时去掉(确信没有其他人同时在使用该文件)。
循环和垂直留白:
if (b) { // Space after the keyword in conditions and loops.} else { // Spaces around else.}while (test) {} // There is usually no space inside parentheses.switch (i) {for (int i = 0; i < 5; ++i) {// Loops and conditions may have spaces inside parentheses, but this// is rare. Be consistent.switch ( i ) {if ( test ) {for ( int i = 0; i < 5; ++i ) {// For loops always have a space after the semicolon. They may have a space// before the semicolon, but this is rare.for ( ; i < 5 ; ++i) { ...// Range-based for loops always have a space before and after the colon.for (auto x : counts) { ...}switch (i) { case 1: // No space before colon in a switch case. ... case 2: break; // Use a space after a colon if there's code after it.
操作符:
// Assignment operators always have spaces around them.x = 0;// Other binary operators usually have spaces around them, but it's// OK to remove spaces around factors. Parentheses should have no// internal padding.v = w * x + y / z;v = w*x + y/z;v = w * (x + z);// No spaces separating unary operators and their arguments.x = -5;++x;if (x && !y) ...
- 垂直留白
垂直留白越少越好。
这不仅仅是规则而是原则问题了:不是非常有必要的话就不要使用空行。尤其是:不要在两个函数定义之间空超过2行,函数体头、尾不要有空行,函数体中也不要随意添加空行。
基本原则是:同一屏可以显示越多的代码,程序的控制流就越容易理解。当然,过于密集的代码块和过于疏松的代码块同样难看,取决于你的判断,但通常是越少越好。
一些关于空行的经验也许有用:
函数开始和结束的换行对可读性基本没什么帮助。
在连续的if-else的语句块中的空行也许能让代码更有可读性。
转载自twowinter的github。
- (转)谷歌编程风格指南_C语言版
- 快速排序(QuickSort)_C语言版
- (转)[译]Google C++编程风格指南(二)
- Google Java编程风格指南(转)
- Google C++编程风格指南(一)
- Google C++编程风格指南(二)
- Google C++编程风格指南(三)
- Google C++编程风格指南(四)
- Google C++编程风格指南(五)
- Google C++编程风格指南(六)
- Google C++编程风格指南(七)
- Google C++编程风格指南(二)
- GOOGLE C++编程风格指南(四)
- MATLAB 编程风格指南
- LISP编程风格指南
- MATLAB 编程风格指南
- MATLAB 编程风格指南
- Google_C++编程风格指南
- 常用算法题目总结二(数组篇)
- Linux下编译Matconvnet
- python的itchat模块
- 初识神经网络--识别手写数字
- STM8S---选项字节(Option Byte)写操作之IO复用
- (转)谷歌编程风格指南_C语言版
- Problem 48 Self powers
- css兼容性
- Intellij IDEA 把普通java工程转为maven工程
- 面试题66:矩阵中的路径
- SQL 2008 R2 数据库操作,不允许保存更改。您所做的更改要求删除并重新创建一下表。您对无法重新创建的表进行了更改或启用了“阻止保存要求重新创建表的更改”选项
- 5.SpringAOP基础
- node.js ——centos爬坑node.js安装、全局环境配置、pm2安装
- java注解型 事务处理