CodeReviewGuidelines

有人说阅读代码比编写代码难两倍。 在此页面上，您可以找到一些可以帮助您进行更好代码审查的提示。 请注意，这些不是绝对规则——最终决定权始终在您手中。

展示示例

谈论代码的最简单方法就是直接展示代码。 当您希望作者修复某些内容、以不同的方式重写代码、以不同的方式格式化代码等时，最好直接在评论中写下您希望代码的样子。 这比让作者猜测您的描述含义更快，并且也能让我们通过查看示例更快地学习。

不确定是否有效

有时您会看到一段看起来可疑的代码，或者过于复杂，以至于您不确定它在所有情况下是否都能正常工作。 在这种情况下，您应该小心检查它，花时间分析和测试它，而不是简单地要求作者向您证明它有效。 如果您没有测试的手段——需要您没有的专业设置，您没有时间等——不要审查它。 当您要求作者解释时，让作者将解释放在代码中的注释中可能是一个好主意——如果它让您感到困惑，将来也可能会让其他人感到困惑。 此外，添加一个单元测试来证明它在边界情况下能正常工作可能是一个好主意。

不要重复自己

当代码中存在明显的重复、复制粘贴的模式时，请要求作者将其抽象成一个单独的函数。 最好的方法是在评论中展示如何做到这一点。 专注于使用现有函数保持代码一致性，并提出简化方案。

当作者编写的代码可以被现有的实用函数替换时，请指向该函数。 最好展示如何在那里使用它。

当作者提交的代码与项目其他部分的代码类似时，这是一个很好的机会让您进行一些重构。 提交您自己的补丁来清理代码。 如果您没有时间，请确保报告一个关于它的错误，以便您或其他人稍后可以执行它。 这种易于修复的错误是新成员开始为您的项目贡献的绝佳方式，因此在错误跟踪器中保留一些它们会很好。

旧的错误

通常，在阅读补丁的代码时，您会发现与补丁本身无关的旧错误——它们只是碰巧在补丁的差异上下文中。 当您看到这样的错误时，请在错误跟踪器中报告它，或者提交一个修复它的补丁。 但不要告诉作者在他们的补丁中包含修复——毕竟，这与别的事情有关。

不要扩大范围

有时，一个补丁可以稍微修改一下以解决更一般的问题，指出这一点是好的，但不要阻止该补丁。 如果它解决了问题并使项目更好，那么包含它是好的，其他问题可以在单独的补丁中解决。 如果您看到机会，请随时提交后续补丁或在错误或蓝图描述中描述它，但不要要求原始作者通过阻止他的补丁来实现您的想法。

留下建设性的评论

社区中的并非每个人都是英语母语者，因此请确保您的评论对补丁作者更改他的代码有意义和帮助，同时也要礼貌和尊重。

审查并非真正关于分数。 关键在于评论。 在审查代码时，务必确保您的评论对补丁作者有用且有帮助。 尽量避免留下评论只是为了表明您已经审查过某些内容，如果它们实际上没有增加任何有意义的内容。

随时准备讨论

永远不要拒绝一个补丁然后就离开（特别是当您知道您将无法使用更长的时间时）。 务必返回到您的不利审查中与作者讨论并重新评估它们。 如果您无法达成一致，请将讨论转移到邮件列表中，并让社区的其他成员参与其中。

进一步阅读

这个邮件列表主题包含关于糟糕审查模式的非常有趣的讨论，[[Category: ContribDocs