如果对代码质量有兴趣，并希望能让Drupal新手能快速跟进编码标准，就需要对所有开发者的代码进行审查。需要强调的是，所有的开发者都需要被审查。

把代码审查工作集成到开发过程之中，是强制审查的一个好办法。可以使用Gitlab（免费版本）这样的工具来防止开发者向重要分支提交代码，这样就强制开发者自行分支，最后提交合并申请。接下来就可以进行审查。审查者可以（对不合标准的情况）加入注释，等开发者做出相应变更后，最后才接受合并请求。

下面列出一些对Drupal代码进行审查时一些相关内容，包括资料和工具（这里我们假设使用Git作为版本故那里工作），

1. 阅读、理解并遵守编码标准。
2. 在开发站点安装、启用和使用Coder模块。
3. 纯粹主义者（处女座？）可以使用Coder Tough Love。
4. 如果你使用Jenkins)这样的持续集成系统，注意检查新的提交产生的日志和警告。注意让开发沙箱打开错误提示，让开发者能注意到出现的错误。如果你不这么做的话，Drupal日志中会出现大量的错误。
5. 回到持续集成的话题上，这里可以添加一个或者更多SonarQube这样的代码质量检查工具。其实已经有一个配置好了的Vagrant)用来创建一个上述符合要求的虚拟机。可以参考持续集成：Drupal/PHP的发布和静态代码分析。
6. 如果在复查过程中发现了无关代码，也就是说，开发者提交的代码中有一部分同声明的内容是无关的，那么一定是出了问题。这很可能是因为开发者所在分支过时导致的。解决这一问题，需要开发者获取最新代码进行合并，修复冲突内容，然后重新提交合并申请。
7. 查找未移除的调试代码，例如dd(),drupal_debug()以及其他类似的输出函数。
8. 查找Git冲突符号，例如”<<<”、”>>>”以及”===”。这些符号一般是因为发生了冲突而产生的。
9. 查看是否缺少注释，Stanzas(完成小功能的小块代码)应该以空行分隔，并进行注释。对于开发者本人来说一目了然的东西，可能很难为其他人所了解。
10. 要在正确的位置安装模块。一般来说公开的模块放在sites/all/modules/contrib，自开发模块则保存在sites/all/modules/custom。
11. 主题文件一般放在sites/all/themes下，审查主题代码需要注意，功能性代码应该在模块中实现，而不是主题中，这样才能保证随着主题的切换，功能还可以保持不变。这是个新手很容易犯的错误。例如模块相关的JavaScript就不应该保存在主题目录中，而应该是跟模块在一起。（译者：觉得放在Libraries中更好）。
12. 注意模块包命名的一致性。对于自开发模块，建议以项目名称作为包名称，这样就保证了模块的清晰划分。对于公开模块，不要做任何改动。

这是我在做代码审查时发现的最常见问题。如果你有其他补充，欢迎添加到评论中，我会补充到列表之中去。