Чи потрібно додати регістр за замовчуванням під час використання корпусів комутаторів?

Під час недавнього перегляду коду мене попросили помістити регістри defaultу всі файли, де б switchне використовувався блок, навіть якщо в цьому нічого робити default. Це означає, що я маю поставити defaultсправу і нічого не писати в ній.

Це правильно робити? Якій меті це послужило б?

Здається, є три випадки, коли defaultзаява не потрібна:

1. жодних інших випадків не залишається, оскільки існує обмежений набір значень, які вводяться в switch case. Але це може змінитися з часом (навмисно чи випадково), і було б добре, default caseякщо щось зміниться - ви могли б увійти або попередити користувача про неправильне значення.

2. ви знаєте, як і де switch caseбуде використовуватися заповіт і які значення будуть входити до нього. Знову ж це може змінитися, і може знадобитися додаткова обробка.

3. інші випадки не потребують особливої ​​обробки. Якщо це так, я думаю, вас попросять додати default case, оскільки це прийнятий стиль кодування, і це робить ваш код більш читабельним.

Перші два випадки ґрунтуються на припущеннях. Тож (якщо припустити, що ви працюєте в не дуже маленькій команді, оскільки регулярно переглядаєте код), ви не можете дозволити собі робити ці припущення. Ви не знаєте, хто буде працювати з вашим кодом або здійснювати дзвінки до функцій / методів виклику у вашому коді. Аналогічно, вам може знадобитися працювати з чужим кодом. Наявність однакового стилю кодування полегшить роботу з чиїмсь (включаючи ваш) код.

Чи правильно це робити? Якій меті це послужило б?

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

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

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

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

Багато в чому це питання те саме, що часто запитують: Чи потрібно мені elseпункт в кінці an if/ else ifдрабинки, який охоплює кожен варіант .

Відповідь, синтаксично кажучи, ні, ви цього не робите. Але є все-таки ...

defaultРозділ може бути там в протягом (як мінімум) по двох причинах:

1. Як обробник помилок - впевнений, сюди ніколи не слід потрапляти! - це вимога, яку можна зробити, але що робити, якщо це зробити? Пошкодження даних, або, що ще гірше, відсутність перевірки даних - це шляхи до відмови програми, якщо вони неправильно зафіксовані. У цьому випадку це не повинно бути порожнім пунктом!
2. Покриття дизайну / коду - навіть у найпростішій формі діаграми є два маршрути із if-оператора та завжди otherwiseіз випадку. Немає жодної причини, щоб не включати їх у вихідний код.

Моя філософія завжди досить проста - оцініть найгірший сценарій з двох варіантів та йдіть до найбезпечнішого. У випадку порожнього elseабо defaultпункту найгіршими варіантами є:

• Включіть їх: додаткові три-чотири рядки "зайвого" коду.
• Не включайте їх: Дані шахрайства або несподіваний стан не захоплені, що може спричинити збій програми.

Надмірний? Можливо ... але тоді моє програмне забезпечення може вбити людей, якщо воно піде не так. Я б краще не ризикував.

На відміну від рекомендацій MISRA-C {див. Профіль для належності} рекомендується defaultпункт для кожногоswitch

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

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

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

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

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

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

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

Якщо ви дійсно впевнені, що вас не цікавлять жодні інші випадки, за замовчуванням: break; // не хвилюється, але типовий за замовчуванням повинен бути чимось на зразок типового: киньте нову помилку ("несподіване значення");

Так само ніколи не слід "пропускати" нетривіальну конструкцію випадку, не додаючи коментаря до ефекту, який ви збираєтеся пропустити. Java помилилася на стадії проектування.

Розглянемо

enum Gender
{
       MALE ,
       FEMALE ;
}

і

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Я можу стверджувати, що це чудово, ніж у випадку MALE, випадку FEMALE і випадку за замовчуванням, який видає виняток.

Під час фази тестування комп'ютер перевірить, чи g FEMALE. Під час виробництва перевірку буде опущено. (Так, мікрооптимізація!)

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