可读性、可维护性和可变更性
做好代码规范、提高代码质量，能显著增强代码的可读性、可维护性和可变更性。本文将这三大要素合称为代码的读写可维护性，努力提高代码的读写可维护性，是做好代码规范的必要非充分条件。代码规范和架构设计是软件的灵魂所在，代码质量偏低，就像是人失去了三魂七魄中的一魄，就会丧失活力，影响正常运行，增加软件交付后维护成本，出现推迟完成、超出预算、特性缺失等现象。
任何语言都需要强调编码风格的一致性。只要是团队开发，每个人都以相同的方式编写代码就是至关重要的。这样大家才能方便地互相看懂和维护对方的代码。
如果不想为以后挖坑，做好代码规范是程序员和团队负责人、项目经理的必修课。如何保证当前项目开发过程中压力正常，而不是在后期面对过多的压力、以至于噩梦缠身？最简单的办法就是照看好你的代码，也就是落实好公司的代码规范工作。每天为此付出一丁点的努力，便可以避免代码「腐烂」，并保证代码产品日后不至于变得难以理解（可读性）和维护（可维护性）。
代码的可读性是指代码让人容易阅读、跟踪和理解的程度。提高代码的可读性可以为代码阅读者节约时间（避免阅读时浪费过多无谓的时间）和精力（Debug、扩展功能或是性能优化的前提条件是你要读懂这段代码）。以下是摘选的可供参考的策略：
软件可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。笔者这里将其分为两大类：编写时可维护性和运行时可维护性。
JavaScript Module AMD 标准执行者（如 require.js）和 CMD 标准执行者（如 sea.js）要求谨慎使用全局变量，将变量限制于一个个模块之中，使得 JavaScript 代码变得更有条理且更便于维护。
代码的可写性包括「代码的可变更性」，代码的可变更性是软件理论的核心，OOSE 花了极大篇幅都在讲软件的变更；敏捷开发则天然地要求软件产品具有高逼格的可变更性。 代码的可写性是建立在代码的可维护性上的，而代码的可写性与可维护性又都建立在代码的可读性上。如果代码难以阅读，那么 BUG 的修正将变得难以入手，新功能的添加就更是无从入手了。 不过前人已经为我们指明了许多方向，例如设计模式、RDD、TDD、DDD 等。使用设计模式可以显著提高代码的可写性，尽管设计模式看上去难以理解且高深莫测，但通过多阅读优秀代码、优秀框架，多通过社区、群、博客、邮件组和小面积聚会与在此道经验富于己者交流，能让自己的水平快速上升。最关键的是多实践，实践是检验真理的唯一标准，也是掌握技术的唯一法门 「（程序员）富有探寻事物本质之精神」便是此理。程序员几乎无一例外地会将自己看到的能使自己进步的知识与技巧立即（或不久之后）进行尝试（实践）。
代码重构是代码可写性的一种特殊情况，把不稳定的积木塞塞紧。软件开发的整个过程也是一个不断迭代、不断优化、不断重构的过程。代码重构旨在不改变现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性（可写性）和维护性（可维护性）。 重构的目的是最大限度避免软件走向生命周期的终结（维护开发成本高于开发一个全新产品的成本时，老的软件便步入了生命周期的晚期）。通过不断重构，纠正和改进软件设计，使代码更易为人所理解，有助于寻找到隐藏的代码缺陷，使系统对新需求的变更保持较强的适应能力（可写性）。 关于重构的知识就此打住，强烈建议感兴趣的读者购买《重构：改善既有代码的设计》和《大话重构》这两本书。
代码检查应采取自动化检测与人工代码审查相结合的方式进行，后者倾向于更为重要的设计错误上（如 BUG、竞态条件和潜在死锁等）。 代码检查的目的是理解代码，改进代码，确保代码能正常工作，而不是批评任何人。 关于代码检查清单，可以阅读这篇文章；关于代码审查的专业知识与技能不是本文关注的重点，可以先阅读这篇文章，然后购买相关的专业书籍进行学习。
以下是一张可供参考的编码规范示例。
C# 编码规范 Java 编码规范 HTML 编码规范 其他