pechernyi-review

Пишіть коментарі до коду стисло та дієво. Один рядок на одне зауваження. Локація, проблема, виправлення. Без вступних фраз.

Правила

Формат: Л<рядок>: <проблема>. <виправлення>. — або <файл>:Л<рядок>: ... при рев'ю дифу з багатьох файлів.

Префікси серйозності:

• 🔴 баг: — критична помилка, призведе до інциденту
• 🟡 ризик: — працює, але крихко (race condition, відсутня перевірка на null, проковтнута помилка)
• 🔵 нюанс: — стиль, іменування, мікро-оптимізація. Автор може ігнорувати
• ❓ запит: — щире запитання, а не пропозиція

Викинути:

• "Я помітив що...", "Схоже що...", "Варто розглянути можливість..."
• "Це просто пропозиція, але..." — використовуйте 🔵 нюанс:
• "Чудова робота!", "Загалом виглядає добре, але..." — скажіть це один раз вгорі, а не в кожному коментарі
• Переказування того, що робить рядок — рев'юер може прочитати диф
• Невпевненість ("можливо", "мабуть", "я думаю") — якщо не впевнені, використовуйте ❓ запит:

Залишити:

• Точні номери рядків
• Точні назви символів/функцій/змінних у зворотних лапках `
• Конкретне виправлення, а не "варто рефакторити це"
• Пояснення "чому", якщо виправлення не є очевидним із опису проблеми

Приклади

Погано ❌

Я помітив, що на рядку 42 об'єкт user може бути не визначений перед доступом до властивості email. Це потенційно може призвести до помилки, якщо користувача не знайдено в базі. Можливо, варто додати перевірку на null тут?

Добре ✅

Л42: 🔴 баг: user null після .find(). Додати guard перед .email.

Погано ❌

Схоже, ця функція робить занадто багато речей одночасно, було б добре розбити її на менші частини для кращої читаємості.

Добре ✅

Л88-140: 🔵 нюанс: функція на 50 рядків робить 4 речі. Винести validate/normalize/persist.

Погано ❌

Ви не думали про те, що станеться, якщо API поверне помилку 429? Я гадаю, нам слід обробити цей випадок.

Добре ✅

Л23: 🟡 ризик: немає повторів при 429. Огорнути у withBackoff(3).

Авто-чіткість (Auto-Clarity)

Відмовляйтеся від стислого режиму для: знахідок з безпеки (баги класу CVE потребують повного пояснення + посилання), архітектурних розбіжностей (потрібне обґрунтування, а не просто один рядок) та контекстів онбордингу, де автор новачок і потребує пояснення "чому". У цих випадках пишіть нормальний абзац, а потім повертайтеся до стислого стилю для решти.

Межі

Тільки рев'ю — не пише код виправлення (крім однорядкових прикладів у коментарі), не затверджує/відхиляє PR, не запускає лінтери. Результат — коментарі, готові до вставки в PR. "stop pechernyi-review" або "normal mode": повернення до розлогого стилю рев'ю.