引入的第三方成熟库或工程不符合既定规范可以网开一面。 （1）第三方库 第三方库通常不是由本团队开发完成的，而且一般情况下代码量巨大且几乎只使用但不需要维护。出于时间成本考虑，我们不会投入精力去维护第三方库的屎山代码。 事实上许多知名的第三方库都有自己的一套编程规范，而且经历过长时间的维护，更重要的是作者水平一般也比较高。绝大数的情况没这个需求。 （2）当前项目的历史遗留代码 当编程人员接手历史遗留屎山项目，或者编程人员的上级管理更换导致代码风格变换，再或者技术总监更新编程规范版本时，会出现代码风格和当前项目冲突的情况出现。 这时候编程人员通常不需要立刻整改整个工程，因为这将是一个浩瀚的工程，既平白投入大量时间又容易引入bug。 这时候该怎么做呢？ 相对合理的做法是暂时容忍项目中存在风格不一致的代码，在加入新代码，或者因需求变动或bug修改而要变动某一块代码时，顺手升级代码风格，经过严格测试后再合入现有工程。