15213 代码风格（翻译）
代码的可读性与代码的功能一样重要。因此，在 15 - 213 （和你上的其他的 CS 课程一样），我们会密切关注你的代码风格并将其作为影响成绩的一个因素。
“什么才是好的代码风格”是一个每学期都会出现的问题。为了尝试解答这个问题，这门课的教职员工创建了这个文档。最基本的要求是代码要一致并且有逻辑，使读者清楚地知道你的代码的目的。我们希望你的代码风格具有良好的可读性和合理性，并且在整个的工程中都坚持这样的风格。我们将关注的关键点如下：
(html comment removed: more )
良好的注释文档
好的代码大部分应该能够 自我描述 ：变量名和函数名应该大致上能够反映你想做什么。注释不应该描述代码做了什么，而是描述为什么是这样；代码做了什么应该是自明的。（当你考虑什么是自明时，假设读者比你更加了解 C 语言。）
一般来说代码值得注释的地方有：
- 文件的头部：每个文件都应该包含描述本文件的目的和在整个工程中的作用的注释。你也可以把你的姓名和邮箱放在这里。
- 函数的头部：每个函数前应该有一两句话描述这个函数的作用，实际参数 和返回值，所有与调用者有关的错误情况，所有相关的 副作用 和所有本函数做出的假设。
- 长代码块：如果一个代码块特别长，在其上方写一些注释能帮助读者了解他们要读的代码是什么，这样如果这段代码与他们无关他们就可以跳过。
- 不易读懂的代码：如果不容易使一段代码做到自明，加一些描述代码做了什么的注释是可以接受的。特别是 指针算数运算 经常需要解释性的注释。
合理使用空格
合理使用空格能够极大地增加代码的可读性。每次你开始一段行的代码块（一个函数，“if” 语句，“for”或“while”循环等），都应该增加一个缩排等级。
你可以使用自己的缩排风格，但是必须一致：如果你使用四个空格来缩排，就不应该再使用 tab 键。我们不推荐你使用 tab 键，而是推荐只使用空格来缩排。（如果你在配置编辑器使其缩排一致时需要帮助，你可以随时向教职员工寻求帮助。）
一行代码的长度
尽管一行代码的长度有许多标准，我们要求它不超过 80 个字符，这样我们能能够便利地查看和打印你的代码。想要快速检查 file.c 没有超过 80 个字符，你可以运行 “wc -L file.c” 得到它的最大行长度。
合理的变量名
变量名应该是对变量所存值得描述。目的自明的局部变量（如循环计数器或数组索引）可以命名为单个字母。形式参数 可以是一个（合理选择的）单词。全局变量可能应该为两个或以上的单词。
魔法数字
魔法数字是你的代码中具有除自身值以外的含义的数字。例如，如果你用 "fgets(stdin, buf, 256)" 来读取数据到一个缓冲区，那么 256 就是一个“魔法数字”，因为他表示了缓冲区的长度。另一方面，当你用"for(int i = 0, i < MAX, i += 2)" 来以偶数计数时时，2 不是一个魔法数字，因为它仅表示你每次加了 2。
你应该使用 #define 来阐明魔法数字的含义。在上面的例子中，你应该做 "#define BUFLEN 256" 并且在“buf”的声明和“fgets”的调用中使用“BUFLEN”常数。
不要“死代码”
“死代码”指的是不论在正常或异常情况下，程序运行时都不会执行的代码。它们包括调试时使用的但是注释了的“printf”语句。你提交的程序不应该有“死代码”。
程序的模块性
你应该努力使你的代码模块化。在一个较低的层面上，这意味着你不应该重复可以被提取出来组成一个新的函数的代码块，并且如果可能，执行多个任务的较长的函数应该被分成几个子函数。在一个较高的层面上，这意味着执行不同功能的代码应该被分隔成不同的模块；例如，如果你的代码需要用散列表，那么（直接）操作散列表的代码应该与使用散列表的代码分隔开，并且散列表的访问应该只能通过几个精心选择的函数来进行。
失败条件 / 错误检查
写代码时，我们通常只考虑成功的情况。考虑失败的情况也同样重要。有很多情况能使你的程序出错：用户的输入不符合你预期的格式，malloc 可能返回 NULL，用户输入的文件名可能不存在，用户指明了一个文件但是没有访问权限，磁盘可能已满，可能会没有网络……还有很多其他的情况。思考你的程序如何能够解决这些错误或者当不能解决时如何展示给用户是很重要的。例如，如果 ，malloc 在你的程序的关键位置出错，可能你只能打印出致命错误信息然后退出。但是如果用户在一个交互程序中指明了一个无效的文件，告诉用户它们输入的文件名是无效的并且给他们纠正错误的机会是更好的。
特别是，网络服务器（你也将会在 15 - 410 操作系统中学到）需要格外 强健。不论一个 用例 （或过程）尝试做什么，你的服务器（或内核）都不应该崩溃。这些情况下的错误处理更困难一些，因为你确保用例端看来致命的错误不会停止服务器的进程。
合理的内存和文件处理
如果你分配了内存（malloc，calloc），你应该在使用过后释放它。你的程序不应该造成 内存泄漏。文件的关闭是很重要的，特别是对于输出文件。原因是输出通常被缓冲。
一致性
次风格指南故意给你留下了许多选择的机会（例如，大括号应该放哪，单行“if”语句是否合理，每一级应该缩排多少）。不论你做什么选择，你都应该做到一致。无规律的风格改变最使你的读者分心了。