代码检视是确保代码质量的重要环节，它有助于开发人员编写易于理解的代码。
微软和谷歌等公司在代码检视中积累了丰富的履历，夸大了代码的可读性对于团队协作的重要性。今世码清晰、布局良好时，其他开发人员能够更快地理解代码的功能和目的，从而提高团队的整体效率。此外，良好的代码可读性也有助于新成员快速融入团队，因为他们可以更容易地理解现有的代码库。
史蒂夫·迈克康奈尔的《代码大全》，被福布斯技能委员会（Forbes Technology Council）誉为“有史以来最好的软件开发基础书” 。
《代码大全》书中提到了提高代码可读性的多种方法，包罗利用故意义的变量名、避免嵌套过深的语句、利用函数和模块、面向对象编程、避免重复代码、利用设计模式、编写解释和文档、利用调试工具、进行代码审查、学习和利用更高级的编程语言和技能等等。
软件工程的焦点就是管理复杂度。规模更大的项目，如果不对复杂性做出限制，那么项目的每个步骤都大概瓦解失控。以往，无数大型项目都在砸下巨量资金后失败了，缘故原由就是其过于复杂，已经无人能理解毕竟发生了什么，就如同过于庞大的巨兽被自身重量所压垮。
复杂性其实贯穿于软件开发的各个阶段，复杂性在编码过程中，如果底层代码的质量不好，超大规模体系也大概就由此瓦解。所以必须立足底层，立足细节抓代码质量，关注每个语句、例程和类，步步为营，以此为基础才能扩大规模，同时继续保持代码质量，即在设计和架构层级控制复杂性，对复杂性控制要广泛而深入地体如今软件开发的各个阶段。
唐纳德·克努特（Donald Knuth），他在编程界被广泛以为是“计算机程序设计艺术”的首创人之一。克努特曾说过：“Programs are meant to be read by humans and only incidentally for computers to execute.” 这句话夸大了代码的可读性对于人类的重要性，意味着代码首先应该是为了让人理解而编写的，而机器执行只是其次。
这是《A practical guide to object-oriented metrics》中的一个统计图，作者分析了一个数据库体系，黄色柱状体是缺陷的百分比，红色柱状体是代码的比例，横坐标标识了不同圈复杂度。最左边代码圈复杂度在0-5的时候，代码量占了总量的40%，缺陷数占了10%，而最右边圈复杂度为15+， 代码量占比10%，但缺陷数量占了缺陷总数的40%+。从左向右的可以看到代码的圈复杂度越高，缺陷的比例也越高。
通常我们不能一次性编写出完全满足需求的代码；或者需求在不断的变化；维护代码的人往往不是原始开发的人员，这些都要求我们编写的代码是可被另一个人所理解和修改的。
2.1.1. 维护规范
代码检视是维护编码规范的关键机制。
代码的可读性、可维护性需要详细的规约来保持。我们往往通过编码规范来维护和保持代码的易于理解和避免一些常见的错误（或被称为最佳实践）。因此各大公司都有了自己的编码规范，比如我们熟知的google的编码规范。同时行业也为了维护行业的同一性，也给出了行业的编码规范，像MISRA C 2012、AUTOSAR C++14 等等。更多的关于规范的信息，可参考《一图看懂软件缺陷检查涉及的内容》。
通过代码检视，可以确保所有代码都遵循了既定的编码标准和最佳实践。这有助于保持代码库的一致性，减少由于风格不一致或不遵循规范导致的维护标题。
目前的编码规范通常会包含两部分：
一致的代码风格。整个项目中保持一致的编码风格，可以减少开发者在阅读不同部分代码时的认知负担，因为他们不需要适应不同的风格。这包罗：
