Чи є гарною практикою уникати попереджень та повідомлень?

Я, як правило, працюю з попередженнями та повідомленнями PHP, оскільки працюю над багатьма проектами, де це вже в реальному виробництві. Тепер, якщо я включу попередження та повідомлення на цих веб-сайтах, які продаються в реальному часі, вони будуть перевантажені ними.

Проекти, над якими я працюю вдома, на місцевих, я, як правило, намагаюся відганяти ВСІ попередження та повідомлення. Іноді рішення про те, щоб не отримувати повідомлення, не існує, тому мені просто доведеться розглянути повідомлення, поки я не вирішу їх повністю відключити.

Зрештою, я не знаю, витрачаю ли я свій час, намагаючись позбутися всіх попереджень і повідомлень, або що насправді роблю це для більшого блага.

Звідси моє запитання, чи є гарною практикою взагалі уникати попереджень та повідомлень, чи це насправді не має значення?

php warnings

— Audite Marlow
джерело

"Іноді не існує рішення, щоб не було повідомлення" Минув час, коли я використовував PHP, але я не пам'ятаю, щоб натрапити на випадки, коли ви могли уникнути повідомлення / попередження або принаймні придушити його локально@ .

— CodesInChaos

Найбільш переконливий аргумент, який я бачив, - це те, що існують з причини - уможливлення того, що ми ігноруємо потік попереджень, змушує нас ігнорувати реальні проблеми, які, можливо, були відхилені ». Іншими словами, якщо під час звичайних операцій немає попереджень чи повідомлень , будь-яке попередження або повідомлення є ознакою потенційної неприємності; якщо все лише шум, ви почнете помічати неприємності лише після SHTF (і, напевно, після того, як це зробить клієнт).

— Пісквор

Використання @ для придушення сповіщень, хоча це звичайно, зазвичай вважається поганою справою. Гірше, ніж просто вимкнути всі повідомлення, тому що ви приховали потенційну проблему. За 15 років програмування php я ще не стикався з випадком, коли мені довелося придушити повідомлення в контрольному коді.

— Церад

Ви просто вимикаєте показ цих повідомлень чи це робите error_reporting(0);? Я завжди використовую, error_reporting(E_ALL);і єдина різниця між розвитком і виробництвом - ini_set('display_errors', 'on');проти ini_set('display_errors', 'off');. Я завжди прагну виправити сповіщення та попередження, поки код ще свіжий у моїй свідомості. Я часті журнали у своїй виробничій системі, щоб побачити, чи є додаткові попередження та повідомлення, які я, можливо, пропустив.

— MonkeyZeus

Я дуже згоден з тим, що сказав @Cerad @. Після років і років програмування PHP я не використовував цього оператора. Не раз. Ніколи. Він не тільки приховує потенційні проблеми, але й впливає на продуктивність: поза кадром PHP вимикає повідомлення про помилки перед тим, як викликати код -> викликає код -> повертає його до початкового значення. Ці кроки дорогі, якщо @у коді є десятки чи сотні .

— Раду Мурзея

Відповіді:

якщо я вмикаю попередження та повідомлення на цих веб-сайтах, що живуть, вони будуть перевантажені ними.

У вас завжди повинні бути включені попередження на найвищому рівні в розробці, тестуванні та якості, але не у виробництві. Насправді, якщо це додаток для собачого кодування, тобто додаток, який ви використовуєте самостійно, тоді ви також повинні мати їх увімкнутими у виробництві.

В основному: увімкніть їх у тих випадках, коли людина, яка їх бачить, може щось зробити з ними (розробник у розробці та тестуванні може їх виправити самостійно, тестувач в QA може подати помилку, і якщо розробник також користувач, тоді він також може виправити це у виробництві), але не вмикайте їх, коли людина, яка бачить, не може нічого з цим зробити (користувач у виробництві, який навіть не вміє програмувати).

В ідеалі ви також хочете ввімкнути трактування попереджень як помилок, але це працює лише в тому випадку, якщо з них нічого не буде ;-) Але майте це на увазі як мета! Якщо можливо ввімкнути / вимкнути це на кожному файлі, увімкніть його для всіх нових файлів і ввімкніть його для всіх файлів, не містять попереджень, і ніколи не вимикайте його знову, як тільки він увімкнено.

Отже, що робити з перевантаженням?

Ви складаєте список кожного попередження та повідомлення та дотримуєтесь наступних правил:

Ніколи, ніколи, ні за яких обставин не додайте до списку нове попередження. Кожен новий фрагмент коду, кожне редагування, кожна зміна, кожен виправлення, кожен випуск не повинні вводити нові попередження, вони можуть лише коли-небудь виправляти їх.
Щоразу, коли ви торкаєтеся фрагмента коду, виправляйте будь-які попередження у цьому фрагменті коду. (Правило Boyscout: завжди залишайте кемпінг у кращому стані, ніж ви знайшли.) Таким чином, неважливий код може залишатися повним попереджень, але важливий код з часом стає чистішим. "Шматок коду" може бути функцією, класом, файлом. Ви можете також послабити це правило, щоб сказати, щоб виправити хоча б одне попередження. Сенс у цьому: виправити їх, як ви їх знайдете.

Примітка: для обох цих вимог потрібно мати певну базу даних журналів та механізм фільтрації журналів. Зауважимо також, що "база даних журналів" і "механізм фільтрації журналів" можуть бути просто текстовим файлом і grep.

Це важливий біт. Без бази даних ви не дізнаєтесь, коли додасте нове попередження, а без фільтрування у вас все ще буде проблема з перевантаженням.

Примітка №2: це не працює лише для попереджень, але також працює для перевірки стилів, метрики складності, покриття коду, інструментів статичного аналізу тощо. В основному:

Не додайте нових проблем.
Виправте старі проблеми, натрапляючи на них.

Це дозволяє легко встановити пріоритети: код, який редагується часто, і, таким чином, його потрібно легко читати та підтримувати, з часом стане кращим. Код, який не чіпають часто, не покращиться, але це нормально, тому що ні в якому разі не потрібно на це дивитися. І , принаймні, не стане гірше.

Звичайно, ніщо не заважає тобі виділяти час спеціально для того, щоб нічого не робити, крім полювання та вбивства попереджень. Це дуже часто, це не є економічно вигідним, і це потрібно враховувати як інженер. "Інженер - це той, хто може скласти долар, те, що кожен дурень може побудувати з двома".

— Йорг W Міттаг
джерело

Ще один момент, чому вимкнути попередження та помилки, які не стикаються з користувачем, нефільтровані: Настільки інформативні, як попередження для розробника, вони можуть просочувати конфіденційну інформацію (назви файлів, імена інших задіяних серверів, структура використовуваних запитів sql, ... )

— Хаген фон Ейцен

Попередження у виробництві повинні надходити до журналів, а не до користувача! Помилки повинні йти до журналів, а не до користувача. Веб-сайт, який не відловлює помилки, записує їх у систему та обслуговує відповідну користувачу сторінку помилок, натомість не готовий до виробництва. PHP дуже легко робить це неправильно, але ви все одно повинні робити це правильно.

— варення

Якщо з вашого коду надходять попередження та повідомлення, то найвиразніше це виправте. З мого досвіду, у 95% це може бути доброякісним, але 5% підкреслюють справжню проблему, яка може призвести до незліченних годин, проведених на погоню.

Якщо вони походять від стороннього коду, який ви повинні використовувати з тих чи інших причин, у вас зазвичай не має великого вибору.

Інше питання, якщо ваша застаріла кодова база дійсно велика, тоді ви можете ставитися до застарілого коду як сторонньої, але вимагаєте, щоб новий код не містив попереджень.

— Олександр Погребняк
джерело

Я працюю в Java / eclipse, який явно відрізняється від php, але, як правило, я вважаю, що попередження піднімається або 1) щось, що компілюється, але я зробив очевидну помилку, або 2) щось, що зараз добре, але буде погано в дорозі

— corsiKa

@corsiKa Я був переклад коментаря до PHP , але я зрозумів , що тільки одне слово необхідно змінити.

— wizzwizz4

Якщо, звичайно, ці попередження не від StyleCop щодо вашого порядку ваших usingзаяв ...

— Dan Pantry

Це важливо. Попередження може не порушити ваші тести або навіть з’явитися в дикій природі на деякий час - але це може бути симптомом насувається помилки. В даний час я розвиваюсь головним чином на C # / C ++ і маю певну стратегію, щоб позбутися та утримати попередження з нашої бази кодів. На щастя, це не ракетна наука =).

Якщо мова, на якій ви працюєте, має змогу трактувати попередження як помилки та має різний рівень попередження, я б зробив наступне:

Зменшіть рівень попередження досить далеко, щоб не отримати попереджень. Якщо ви знаходитесь на найнижчому рівні попередження і все ще отримуєте попередження - спробуйте виправити їх. Якщо ви не можете їх виправити, тоді ви вже готові, але сподіваємось, ви зможете їх виправити. Чудово.
Оскільки у вас зараз немає попереджень (найімовірніше, низький рівень попередження), переверніть перемикач і розглядайте всі попередження як помилки.
Спробуйте підняти рівень попередження і виправити всі нові попередження. Якщо ви не можете, поверніть рівень попередження назад вниз, але не вимикайте трактування попереджень як помилок.

Я вважаю, що це не лише спрацьовує застереження з мого коду - це запобігає їх виходу .

— PerryC
джерело