コードレビューガイドラインは、通常、コードの品質とプロジェクトの締め切りのバランスを考慮して、プロジェクトの特定の要件に合わせて調整されます。

ただし、一般的に、コードを確認するときに次のように予想されます。

1.バグを特定して報告します
2.コードの品質の向上

バグは、誤ったロジック、仕様の誤解になる可能性があります。エッジの欠落ケースは非常に頻繁です。
コードレビューはコードの品質を改善すると予想されます。これは、コードの別の視点を提供するためです。
コードがあることを確認する機会です

 - 維持可能で、他の人にとっては理解しやすく、プロジェクト全体と一致しています。
 - リソースの使用に関する効率的、高速、軽量。


悪いレビューは、実体ではなくスタイルに焦点を当てる傾向があります。
一般的に優先順位を与える必要があります。
 - コードが機能することを確認します
 - 仕様要件が満たされていること
 - そのエッジケースは適切に処理されます
 -  *次に *コードの品質とパフォーマンスの向上
Code review guidelines are typically tailored to the specific requirements of a project, taking into consideration the balance between code quality and project deadlines.

But generally, you are expected when reviewing code to:

1. Identify and report bugs
2. Improving code quality

Bugs can be incorrect logic, spec misunderstanding. Missing edges cases are quite frequent.
Code review is expected to improve code quality since it gives another perspective on a piece of code.
It's the opportunity to make sure that the code is

- maintenable, easy to understand for others, consistent with the overall project.
- efficient, fast and lightweight on resource usage.


Bad reviews tend to focus on style rather than substance.
Generally priority should be given to:
- making sure that the code works
- that the specification requirements are met
- that edge cases are properly handled
- *then* improving code quality and performance