C语言代码风格之1.docx

2010-12-28 19:51 C代码风格 1. 缩进和空白 1、关键字if, while, for与其后的控制表达式的(括号之间插入一个空格分隔，但括号内的表达式应紧贴括号。例如： while?(1);2、双目运算符的两侧插入一个空格分隔，单目运算符和操作数之间不加空格，例如i?=?i?+?1、+i、!(i?1)、-x、&a1等。 3、后缀运算符和操作数之间也不加空格，例如取结构体成员s.a、函数调用foo(arg1)、取数组成员ai。 4、,号和;号之后要加空格，这是英文的书写习惯，例如for?(i?=?1;?i?10;?i+)、foo(arg1,?arg2)。 5、以上关于双目运算符和后缀运算符的规则不是严格要求，有时候为了突出优先级也可以?吹酶舸找恍鏵or?(i=1;?i?5.0 &?x?0.0)再比如： foo(sqrt(x*x?+?y*y), ai-1?+?bi-1?+?ci-1)7、较长的字符串可以断成多个字符串然后分行书写，例如： printf(This is such a long sentence that it cannot be held within a linen);C编译器会自动把相邻的多个字符串接在一起，以上两个字符串相当于一个字符串This is such a long sentence that it cannot be held within a linen。 8、有的人喜欢在变量定义语句中用Tab字符，使变量名对齐，这样看起来也很好，但不是严格要求的。 int a, b; double c;内核关于缩进的规则有以下几条。 1、要用缩进体现出语句块的层次关系，使用Tab字符缩进，不能用空格代替Tab。在标准的Linux终端上，一个Tab看起来是8个空格的宽度，有些编辑器可以设置一个Tab看起来是几个空格的宽度，建议设成8，这样大的缩进使代码看起来非常清晰。规定不能用空格代替Tab主要是不希望空格和Tab混在一起做缩进，如果混在一起用了，在某些编辑器里把Tab的宽度改了就会看起来非常混乱。 2、if/else、while、do/while、for、switch这些可以带语句块的语句，语句块的和应该和关键字写在一起，用空格隔开，而不是单独占一行。例如应该这样写： if?(.)? 语句列表 ?else?if?(.)? 语句列表 很多人习惯这样写： if?(.) 语句列表 else?if?(.) 语句列表 内核的写法和K&R一致，好处是不必占用太多空行，使得一屏能显示更多代码。这两种写法用得都很广泛，?灰谕桓鱿钅恐心鼙滞骋痪涂梢粤恕?3、函数定义的和单独占一行，这一点和语句块的规定不同，例如： int?foo(int?a,?int?b) 语句列表 4、switch和语句块里的case、default对齐写，也就是说语句块里的case、default相对于switch不往里缩进。例如： switch? case A: 语句列表 case B: 语句列表 default: 语句列表 自己命名的标号（用于goto）必须顶头写不缩进，而不管标号下的语句缩进到第几层。 5、代码中每个逻辑段落之间应该用一个空行分隔开。例如每个函数定义之间应该插入一个?招校肺募直淞慷搴秃逯湟灿貌迦肟招校纾?#include #include int g; double h; int foo(void) 语句列表 int bar(int a) 语句列表 int main(void) 语句列表 6、一个函数的语句列表如果很长，也可以根据相关性分成若干组，用空行分隔，这条规定?皇茄细褚螅话惚淞慷逵锞渥槌梢蛔椋竺嬉涌招校瑀eturn之前要加空行，例如： int main(void) int a, b; double c; 语句组1 语句组2 return 0; 2. 注释 单行注释应采用/*?comment?*/的形式，用空格把界定符和文字分开。多行注释最常见的是这种形式： /* ?*?Multi-line ?*?comment ?*/也有一些更花哨的形式： /* Multi-line comment */或者： /* * Multi-line * * comment * */使用注释的场合主要有以下几种。 1、整个源文件的顶部注释。说明此模块的相关信息，例如文件名、作者和版本历史等，顶?沸床凰踅缒诤嗽创雓ernel/sched.c的开头： /* * kernel/sched.c * * Kernel scheduler and related syscalls * * Copyright (C) 1991-2002 Linus Torvalds * * 1996-12-23 Modified by Dave Grothe to fix bugs in semaphores and * make semaphores SMP safe * 1998-11-19 Implemented schedule_timeout() and related stuff * by Andrea Arcangeli * 2002-01-04 New ultra-scalable O(1) scheduler by Ingo Molnar: * hybrid priority-list and round-robin design with * an array-switch method of distributing timeslices * and per-CPU runqueues. Cleanups and useful suggestions * by Davide Libenzi, preemptible kernel bits by Robert Love. * 2003-09-03 Interactivity tuning by Con Kolivas. * 2004-04-02 Scheduler domains code by Nick Piggin */2、函数注释。说明此函数的功能、参数、返回值、错误码等，写在函数定义上侧，和此函?逯洳涣艨招校沸床凰踅?3、相对独立的语句组注释。对这一组语句做特别说明，写在语句组上侧，和此语句组之间?涣艨招校氲鼻坝锞渥榈乃踅恢隆猓得饔锞渥榈淖鸵欢丛谟锞渥樯厦妫?能写在语句组下面。 4、代码行右侧的简短注释。对当前代码行做特别说明，一般为单行注释，和代码之间至少?靡桓隹崭窀艨桓鲈次募兴械挠也嘧妥詈媚苌舷露云搿芾?2.1 “带更多注释的Hello World”讲过注释可以穿插在一行代码中间，但是不建议这么用。 CodingStyle中特别指出，函数内的注释要尽可能少用。注释只是用来说明你的代码能做什么（比如函?涌诙澹皇撬得髟跹龅模灰胄吹米愎磺逦跹鍪且荒苛巳坏模绻?你需要用注释才能解释清楚，那就表示你的代码可读性很差，除非是特别需要提醒注意的?胤讲攀褂煤谧汀?5、复杂的结构体定义比函数更需要注释。例如内核源代码kernel/sched.c中定义了这样一个结构体： /* * This is the main, per-CPU runqueue data structure. * * Locking rule: those places that want to lock multiple runqueues * (such as the load balancing or the thread migration code), lock * acquire operations must be ordered by ascending &runqueue. */ struct runqueue spinlock_t lock; /* * nr_running and cpu_load should be in the same cacheline because * remote CPUs use both these fields when doing load calculation. */ unsigned long nr_running; #ifdef CONFIG_SMP unsigned long cpu_load3; #endif unsigned long long nr_switches; /* * This is part of a global counter where only the total sum * over all CPUs matters. A task can increase this counter on * one CPU and if it got migrated afterwards it may decrease * it on another CPU. Always updated under the runqueue lock: */ unsigned long nr_uninterruptible; unsigned long expired_timestamp; unsigned long long timestamp_last_tick; task_t *curr, *idle; struct mm_struct *prev_mm; prio_array_t *active, *expired, arrays2; int best_expired_prio; atomic_t nr_iowait; #ifdef CONFIG_SMP struct sched_domain *sd; /* For active balancing */ int active_balance; int push_cpu; task_t *migration_thread; struct list_head migration_queue; int cpu; #endif #ifdef CONFIG_SCHEDSTATS /* latency stats */ struct sched_info rq_sched_info; /* sys_sched_yield() stats */ unsigned long yld_exp_empty; unsigned long yld_act_empty; unsigned long yld_both_empty; unsigned long yld_cnt; /* schedule() stats */ unsigned long sched_switch; unsigned long sched_cnt; unsigned long sched_goidle; /* try_to_wake_up() stats */ unsigned long ttwu_cnt; unsigned long ttwu_local; #endif ; 6、复杂的宏定义和变量定义也需要注释。 3. 标识符命名 标识符命名应遵循以下原则： 1.标识符的命名要清晰明了，可以使用完整的单词和大家易于理解的缩写。短的单词可以通过去元音形成缩写，较长的单词可以取单词的头几个字母形成缩写，也可以采用大家基本?贤乃跣础鏲ount写成cnt，block写成blk，length写成len，window写成win，message写成msg，temporary可以写成temp，也可以进一步写成tmp。 2.内核风格规定变量、函数和类型采用全小写加下划线的方式命名，常量（宏定义和枚举常量）采用全大写加下划线的方式命名。上面举例的函数名radix_tree_insert、类型名struct radix_tree_root、常量名RADIX_TREE_MAP_SHIFT等。有一种变量命名风格叫匈牙利命名法（Hungarian notation），用变量名的前缀记录变量的类型，例如iCnt、pMsg、lpszBlk等，Linus在CodingStyle中毫不客气地讽刺了微软发明的这一风格：“Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.”代码风格本来就是一个很有争议的问题，如果你接受本章介绍的内核风格（也是本书所有范例代码的风格），就不要使用大小写混合的变量命名方式17，更不要使用匈牙利命名法。3.全局变量和全局函数的命名一定要详细，不惜多用几个单词多写几个下划线，例如函数名radix_tree_insert，因为它们在整个项目的许多源文件中都会用到，必须让使用者明确这个变量或函数是干?裁从玫摹植勘淞亢椭辉谝桓鲈次募械饔玫哪诓亢拿梢约蚵砸恍荒芴?，不要使用单个字母做变量名，只有一个例外：用i、j、k做循环变量是可以的。 4.针对中国程序员的一条特别规定：禁止用汉语拼音作为标识符名称，可读性极差。 大小