Чи є хорошою практикою використання попереджувальних попереджень у коді?

Я використовую @SuppressWarnings("unchecked")і в @SuppressWarnings("null")основному вище методи, щоб дозволити збір коду без будь-яких попереджень, але я сумніваюся. Знайшли це питання щодо Стакковержа . Джон Скіт написав на нього відповідь, яку мені здається інтригуючою.

Згідно з ним,

Іноді Java generics просто не дозволяє робити те, що ви хочете, і вам потрібно ефективно сказати компілятору, що те, що ви робите, дійсно буде законним під час виконання.

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

Крім того, що робити, якщо хтось інший змінить мій код пізніше та додасть сумнівну функціональність, не видаляючи SuppressWarnings? Як цього можна уникнути та / або існує якась інша альтернатива цьому?

Чи слід використовувати @SuppressWarnings("unchecked")і @SuppressWarnings("null")?

Оновлення №1

Що стосується неперевірених підказів типу, згідно з цією відповіддю (на яку @gnat вказував у коментарях нижче), придушення цих попереджень є необхідним.

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

У разі придушення інших попереджень, все ще в трохи сірій зоні.

Оновлення №2

Відповідно до Документів Oracle (також згадуваних у деяких відповідях нижче):

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

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

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

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

Редагувати

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

Придушення попереджень - це те, що потрібно робити дуже обережно.

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

if (x = someFunction ()) { ... }

дає попередження, але

if ((x = someFunction ())) { ... }

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

if ((x = someFunction ()) != 0) { ... }

або за допомогою двох рядків.

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

Однак деякі люди просто відключають попередження, щоб позбутися попереджень, тому що вони занадто ледачі, щоб з’ясувати та виправити причину законного попередження спочатку. Або вони навіть не намагаються написати код, який не містить попереджень. Це вкрай нездорово робити.

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

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast