Правила проверки кода

Действия перед началом проверки PR

Убедитесь, что вы знакомы с пакетами, которые изменяет PR.
Убедитесь, что у вас есть достаточно непрерывного времени для проверки PR, используйте 300 строк кода на час для оценки.
Убедитесь, что вы можете следить за обновлениями PR в течение следующих нескольких рабочих дней.
Прочитайте описание PR, если оно не легко понимается, попросите разработчика улучшить его.
Для PR, связанных с исправлением ошибок, если нет тестового случая, попросите разработчика добавить тесты.
Для PR, связанных с производительностью, если нет результатов бенчмарка, попросите разработчика добавить результаты бенчмарка.

Могу ли я понять цель каждого юнит-теста?
Юнит-тесты действительно проверяют, что код выполняет намеченную функциональность?
Юнит-тесты охватывают все важные блоки кода и специально обработанные ошибки?
Могут ли процедурные тесты быть переписаны в табличные тесты?
Соблюдает ли код стиль, описанный в руководстве?
Не дублируется ли один и тот же код более двух раз?
Существуют ли комментарии, описывающие цель кода?
Существуют ли комментарии к хакам, временным решениям и обходным путям?* Не выполняет ли эта функция больше, чем предполагает её название?
Не может ли поведение этой функции быть предсказано по её названию?
Существуют ли тесты, и являются ли они полными?
Юнит-тесты охватывают ли все важные ветки кода?
Могут ли тесты быть переписаны в табличные тесты?

Будьте добры к разработчику, а не к коду.
Ставьте вопросы, а не делайте утверждения.
Обращайтесь с уважением, терпением и пониманием к тем, кто знает меньше вас.
Помните о поощрении, если качество кода превышает ваши ожидания.
Разработчикское решение может быть не неправильным, если оно отличается от вашего.
Ссылайтесь на документацию по стилю кода, когда это необходимо.