4代码复审重要性

软件源代码漏洞及缺陷扫描技术软件源代码质量的重要性121如何区分优秀源代码和劣质源代码2企业代码如何进行归档3垃圾代码的危害性4几个简单地源代码漏洞5代码的安全级别补充目录代码规范和代码复审的重要性软件源代码漏洞及缺陷扫描技术软件源代码漏洞及缺陷扫描技术代码规范和代码复审的重要性代码风格规范的重要性代码设计规范的重要性代码复审的重要性3代码风格规范代码风格最早出现的，也较为传统的是K&R风格。所谓K&R即指《TheCProgrammingLanguage》一书的作者Kernighan和Ritchie二人，这是世界上第一本介绍C语言的书，而K&R风格即指他们在该书中书写代码所使用的风格。K&R风格在处理大括号时，使用了一种较为紧凑的格式，将左括号留在前一行的末尾，并尽可能地压缩。4代码风格规范的必要性（1）规范的代码可以促进团队合作

（2）规范的代码可以减少bug处理（3）规范的代码可以降低维护成本（4）规范的代码有助于代码审查（5）养成代码规范的习惯，有助于程序员自身的成长5代码风格规范——换行代码太长分成多行例如下面这行代码，虽然结构很简单，但是它实在太长了，所以被分成了两行：6代码风格规范——换行寻找最佳换行位置写程序不能像写文章那样，什么时候顶到了边界就换，而必须按照其语法规则，在可以换行的位置断开。例如，对于包含一个超长表达式的语句来说，我们可以在某两个表达式项之间将其断开，如下所示：7代码风格规范——换行寻找最佳换行位置有的时候，我们并不一定非要在临近右边界的时候才去换行，如果存在更为合理的分法，就应当采用，例如下面的情况：按理说这样的断行并没有什么问题，它在表达式的两项之间断开，并将运算符留在了上一行的行末。但是，我相信如果换一种断行方式的话，能够更加清楚地表达出原来的逻辑：8代码风格规范——换行寻找最佳换行位置同样的道理，为了将逻辑体现得更为清晰，我们甚至可以将函数调用中的每一个参数都分行书写，如同下面这样：当参数数量较多，参数较长或者包含表达式的时候，这种排版比起单独写成一行更为直观醒目。9代码风格规范——换行寻找最佳换行位置对于LINQ查询表达式来说，将每个子句单独写成一行也是好的习惯。因为这同时符合了T-SQL语言的文化传统。例如：10代码风格规范——换行每行只写一条语句11代码风格规范——换行分行定义变量我们再来看一种情况，这类代码出现的几率更为频繁，它是将相同数据类型的几个变量声明放在了同一条语句中：12代码风格规范——避免代码过于拥挤使用空行分隔代码块在命名空间引用（C#）、import引用（Java）、include包含之后（C++）、以及require引用（PHP）之后添加空行：13代码风格规范——避免代码过于拥挤使用空行分隔代码块用空行分隔逻辑块：14代码风格规范——使用空格降低代码密度让我们来比较一下下面的几行代码：C语言的运算符几乎都只由“符号”构成，与变量名之间不需要用空格充当分隔符。这样一来，由于缺少空格的稀释，C语言的代码就像被浓缩过似15代码风格规范——使用空格降低代码密度单目运算符单目运算符（UnaryOperators）与它的操作数之间应紧密相接，不需要空格。例如：16代码风格规范——使用空格降低代码密度双目、三目运算符在双目、三目运算符（Binary/TernaryOperators）的左右两侧分别添加空格。例如：17代码风格规范——使用空格降低代码密度括号括号（包括小括号、中括号与大括号）的内侧应该紧靠操作数或其他运算符，不需要添加额外的空格。例如：18代码风格规范——使用空格降低代码密度括号括号（包括小括号、中括号与大括号）的内侧应该紧靠操作数或其他运算符，不需要添加额外的空格。例如：19代码风格规范——使用空格降低代码密度括号与空格在这里，我建议采用VisualStudio中的默认规则：在函数调用时不添加空格，而在一些类似的带括号的语法结构中添加空格。请看下面这段代码：20代码风格规范——缩进在有关代码风格的问题中，最为显眼的可以说就是代码的缩进（Indent）了。所谓缩进，是通过在每一行的代码左端空出一部分长度，更加清晰地从外观上体现出程序的层次结构。为了更好地描述这一点，先请大家欣赏下列这段代码：21代码风格规范——缩进正确缩进的例子：22代码风格规范——缩进包含和嵌套关系引起的缩进23代码风格规范——缩进因换行而产生的缩进24代码风格规范——缩进使用空格还是Tab如何缩进一向是一个有争议的问题。使用Tab及Shift+Tab键缩进在操作上非常方便，而使用空格可以保证代码在任何编辑器下都能正确显示缩进格式。25代码风格规范——大括号大括号的位置代码风格中，如何摆放大括号一直是人们热衷的话题。其实，我们用开放的态度去看待它，具体使用何种方式并不重要，重要的是，要保持方式风格的统一，不能在同一个项目中出现不同的风格。（1）K&R大括号位置风格（2）另外一种大括号位置风格26代码风格规范——大括号空大括号结构为什么会出现空的复合体？（1）来自于废弃的空函数（2）因开发时的疏忽造成的空复合体（3）有意而为之这样总结下来，似乎空复合体完全不应该出现在代码中，然而有一种情况下它的确可以而且应当存在，这就是构造函数。构造函数与其他的函数不同，即使没有任何一行代码内容，它本身的存在与否也有着极其重要的意义——直接决定这个类型是否能够被实例化。因此，当我们不希望某个类被外部实例化的时候，哪怕我们并不需要自定义构造函数，我们仍需要为该类型添加一个非公开的空构造函数。为了避免日后将这个空函数当成是没有用的废弃函数，我们有必要特别加以说明27代码风格规范——大括号仅包含单个语句的结构体28代码设计规范代码设计规范不光是程序书写的格式问题，而且牵涉到程序设计、模块之间的关系、设计模式等方方面面。如果你只是为了“爽”而写程序，那么可以忽略下面的原则，如果你写的程序会被很多人使用，并且你自己会加班调试你自己的程序，那最好还是遵守下面的规定。29代码设计规范代码设计规范不光是程序书写的格式问题，而且牵涉到程序设计、模块之间的关系、设计模式等方方面面。如果你只是为了“爽”而写程序，那么可以忽略下面的原则，如果你写的程序会被很多人使用，并且你自己会加班调试你自己的程序，那最好还是遵守下面的规定。30代码设计规范——函数现代程序设计语言中的绝大部分功能，都在程序的函数（Function，Method）中实现，关于函数最重要的原则是：只做一件事，但是要做好函数最好有单一的出口，看下面的例子：31代码设计规范——错误处理80%的程序代码，都是对各种已经发生和可能发生的错误的处理。如果错误发生，那就让程序死的地方离错误产生的地方越近越好。32代码设计规范——错误处理参数处理在Debug版本中，所有的参数都要验证其正确性。在正式版本中，从外部（用户或别的模块）传递过来的参数要验证其正确性。33代码设计规范——错误处理断言如何验证正确性？那就要用Assert（断言）。断言和错误处理是什么关系？当你觉得某事肯定如何，你可以使用断言。Assert（p！=NULL）;然后可以直接使用变量p。如果你认为某事可能会发生，这时就要用错误处理。如：34代码设计规范——类（Class）什么时候使用类（1）使用类来封装面向对象的概念和多态（2）避免传递类型实体的值，应该用指针传递。换句话说，对于简单地数据类型，没有必要用类来实现。（3）对于有显式的构造和析构函数，不要建立全局的实体，因为你不知道它们在何时创建和消除35代码设计规范——类（Class）ClassVSStruct如果只是数据的封装，用Struct即可36代码设计规范——类（Class）公共/保护/私有为了安全起见，按照这样的次序来说明类中的成员：public、protected、private37代码设计规范——类（Class）数据成员（1）数据类型的成员用m_name说明（2）不要使用公共的数据成员，要用inline访问函数，这样可同时兼顾封装和效率38代码设计规范——类（Class）虚函数（1）使用虚函数来实现多态（2）只有在非常必要的时候，才使用虚函数（3）如果一个类型要实现多态，在基类中的析构函数应该是虚函数39代码设计规范——类（Class）构造函数（1）不要在构造函数做复杂的操作，简单地初始化所有数据成员即可（2）构造函数不应该返回错误（实际上也无法返回）。把可能出错的操作放在其他函数中（比如你可以自己写一个init函数）。40代码设计规范——类（Class）析构函数（1）把所有的清理工作都放在析构函数中，如果有些资源在析构函数之前就释放了，记住要重置这些成员为0或NULL（2）析构函数也不应该出错41代码设计规范——类（Class）New和Delete（1）如果可能，要实现自己的New/Delete（2）检查New的返回值（3）释放指针时候不用检查NULL42代码设计规范——类（Class）运算符（Operators）（1）只有当操作符需要的时候使用（2）运算符不要做标准语义之外的任何动作（3）运算符的实现必须非常有效率（4）当你拿不定主意的时候，用成员函数，不要用运算符43代码设计规范——类（Class）异常（Exception）（1）不要用异常作为逻辑控制来处理程序的主要流程（2）了解异常和处理异常的花销（3）当使用异常时，要注意在什么地方清理数据（4）异常不能跨过DLL或进程的边界来传递消息，所以异常不是万能的44代码设计规范——类（Class）类型继承（1）当有必要的时候，才使用类型继承（2）用Const或final等来标注只读参数（3）用Const或final等来标注不改变数据的函数45代码复审代码复审，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。代码复审的形式：（1）自我复审（2）同伴复审（最基本的复审手段）（3）团队复审46代码复审——目的代码复审的目的在于：（1）找出代码的错误（2）发现逻辑错误（3）发现算法错误（4）发现潜在的错误和回归性错误（5）发现可能改进的地方（6）教育开发人员47代码复审——步骤代码复审之前：（1）代码必须成功地编译（2）程序员必须测试过代码48代码复审——步骤代码复审内容：（1）复审者选择复审方式（2）复审者必须给出反馈意见（详细的）（3）开发者必须负责让所有问题都得到满意的解释或解答（4）对于复审的结果，双方必须达成一致的意见49代码复审——步骤代码复审之后：（1）更正明显的错误（2）记录很难很快更正的错误（3）把所有错误记录成表（“我常犯的错误”）50代码复审——核查表一、概要部分（1）代码能否符合需求和规格说明（2）代码设计是否有周全的考虑（3）代码可读性如何（4）代码容易维护吗（5）代码的每一行都执行并检查过了吗51代码复审——核查表二、设计规范部分（1）设计是否遵守已知的设计模式或项目中常用的模式（2）有没有硬编码或字符串/数字等存在（3）代码有没有依赖某一平台（4）开发者新写的代码能否用已有的库实现（5）有没有无用代码可以清除52代码复审——核查表三、代码规范部分修改的部分符合代码标准和风格吗53代码复审—