Чи розумно знімати нуль кожного окремого вказівника?

На новій роботі я отримував позначення в кодах оглядів такого коду:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender) { }

void PowerManager::SignalShutdown()
{
    msgSender_->sendMsg("shutdown()");
}

Мені сказали, що останній метод повинен читати:

void PowerManager::SignalShutdown()
{
    if (msgSender_) {
        msgSender_->sendMsg("shutdown()");
    }
}

тобто я повинен поставити NULLохорону навколо msgSender_змінної, хоча вона є приватною особою даних. Мені важко стримуватися від використання експлікатів, щоб описати, як я відчуваю цю частину "мудрості". Коли я прошу пояснення, я отримую літанію страшилок про те, як якийсь молодший програміст, якийсь рік, заплутався в тому, як повинен працювати клас, і випадково видалив учасника, якого він не мав (і встановив його NULLзгодом , мабуть), і все вибухнуло в полі одразу після випуску продукту, і ми "навчилися тяжкому шляху, довіряй нам", що краще просто всеNULL перевірити .

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

Чи доцільно для стандарту кодування вимагати, щоб спочатку перевіряли кожен вказівник, відмінений у функції, NULLнавіть приватні члени даних? .

РЕДАКТУВАННЯ : У наведеному вище прикладі msgSender_співавтор необов'язковий. Якщо це колись NULL, це вказує на помилку. Єдина причина, яку він передає в конструктор, - це те, що він PowerManagerможе бути перевірений з макетним IMsgSenderпідкласом.

ПІДСУМОК : На це питання було кілька справді чудових відповідей, дякую всім. Я прийняв цей від @aaronps головним чином завдяки його стислості. Здається, існує досить широка загальна згода, яка:

1. Обслуговування NULLохоронців для кожного окремо взятого вказівника надмірне, але
2. Ви можете перейти до всієї дискусії, використовуючи замість цього посилання (якщо можливо) або constвказівник, і
3. assertВисловлювання є більш освіченою альтернативою NULLсторожам для перевірки того, чи виконуються передумови функції.

Це залежить від "контракту":

Якщо PowerManager ОБОВ'ЯЗКОВО має бути дійсний IMsgSender, ніколи не перевіряйте його на нуль, нехай він швидше помре.

Якщо, з іншого боку, це МОЖЕ бути IMsgSender, то вам потрібно перевіряти кожен раз, коли ви користуєтесь, настільки просто.

Остаточний коментар про історію молодшого програміста, проблема насправді у відсутності процедур тестування.

Я вважаю, що код повинен читати:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender)
{
    assert(msgSender);
}

void PowerManager::SignalShutdown()
{
    assert(msgSender_);
    msgSender_->sendMsg("shutdown()");
}

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

Спільна "мудрість" ваших колег мовчки ігнорує цю помилку з непередбачуваними результатами.

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

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

Якщо msgSender ніколи не повинен бути null, слід поставити nullчек лише в конструкторі. Це справедливо і для будь-яких інших входів у клас - поставте перевірку на цілісність у точці входу до «модуля» - класу, функції тощо.

Моє правило - здійснювати перевірку цілісності між межами модуля - клас у цьому випадку. Крім того, клас повинен бути досить малим, щоб можна було подумки швидко перевірити цілісність життя членів класу - забезпечивши запобігання таким помилкам, як неправильне видалення / присвоєння нулю. Перевірка нуля, яка виконується в коді у вашій публікації, передбачає, що будь-яке недійсне використання фактично призначає нуль покажчику - що не завжди так. Оскільки "неправомірне використання" по суті означає, що будь-які припущення щодо звичайного коду не застосовуються, ми не можемо бути впевнені, щоб зафіксувати всі типи помилок вказівника - наприклад, недійсне видалення, збільшення та ін.

Крім того - якщо ви впевнені, аргумент ніколи не може бути недійсним, розгляньте використання посилань, залежно від використання класу. В іншому випадку розгляньте можливість використання std::unique_ptrабо std::shared_ptrзамість необробленого вказівника.

Ні, нерозумно перевіряти кожну відмітку покажчика на наявність вказівника NULL.

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

Якщо я зіткнувся з такою ситуацією, як ваша, я б поставив два питання:

• Чому помилка цього молодшого програміста не була спіймана перед випуском? Наприклад, в огляді коду або на етапі тестування? Виведення на ринок несправного пристрою побутової електроніки може бути настільки ж дорогим (якщо врахувати частку ринку та доброзичливість), як випустити несправний пристрій, який використовується в критичному для безпеки додатку, тому я б очікував, що компанія серйозно поставиться до тестування та інші заходи щодо забезпечення якості.
• Якщо недійсна перевірка не працює, яку помилку ви очікуєте від мене встановити, чи я можу просто написати assert(msgSender_)замість нульової перевірки? Якщо ви просто ввели нульову реєстрацію, можливо, ви попередили збій, але, можливо, ви створили б гіршу ситуацію, оскільки програмне забезпечення продовжується за умови, що операція відбулася, а насправді ця операція була пропущена. Це може призвести до того, що інші частини програмного забезпечення стануть нестабільними.

Цей приклад, здається, стосується більше часу життя об'єкта, ніж того, чи є вхідним параметром нульовий †. Так як ви говорите , що PowerManagerнеобхідно завжди мати дійсний IMsgSender, передаючи аргумент покажчиком (дозволяючи тим самим можливість нульового покажчика) вражає мене як дизайн вада ††.

У таких ситуаціях я вважаю за краще змінити інтерфейс, щоб вимоги абонента виконувалися мовою:

PowerManager::PowerManager(const IMsgSender& msgSender)
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    msgSender_->sendMsg("shutdown()");
}

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

Ви також можете написати те ж саме, використовуючи смарт-покажчик (через boost або c ++ 11), щоб явно змусити IMsgSenderжити довше, ніж PowerManager:

PowerManager::PowerManager(std::shared_ptr<IMsgSender> msgSender) 
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    // Here, we own a smart pointer to IMsgSender, so even if the caller
    // destroys the original pointer, we still have a valid copy
    msgSender_->sendMsg("shutdown()");
}

Цей спосіб є кращим, якщо можливо, IMsgSenderчас життя не може бути гарантовано більшим, ніж PowerManager'(тобто x = new IMsgSender(); p = new PowerManager(*x);).

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

Десь хтось отримав адресу для пам’яті для зберігання IMsgSender. Це відповідальність за те, щоб переконатися, що розподіл вдалося (перевірка значень повернення бібліотеки або належна обробка std::bad_allocвинятків), щоб не обходити недійсні покажчики.

Оскільки пристрій PowerManagerне є власником IMsgSender(це просто запозичити його на деякий час), воно не несе відповідальності за виділення або знищення цієї пам'яті. Це ще одна причина, чому я віддаю перевагу посиланням.

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

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

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

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

Редагувати: якщо розмірковувати над історією молодшого програміста, звучить так, що сталося те, що приватний член був встановлений на нуль, коли цього ніколи не слід було допускати. У них виникли проблеми з неправильним написанням і намагаються виправити це шляхом перевірки після читання. Це назад. На той момент, коли ви його виявите, помилка вже сталася. Прийнятне рішення для перегляду коду / компілятора для цього не є умовами захисту, а натомість getters та setters або const members.

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

void PowerManager::SignalShutdown()
{
    if (!msgSender_)
    {
       throw SignalException("Shut down failed because message sender is not set.");
    }

    msgSender_->sendMsg("shutdown()");
}

Запропоноване "виправлення" іншими членами вашої команди порушує принцип мертвих програм Tell No Lies . Помилок насправді важко знайти як є. Метод, який мовчки змінює свою поведінку на основі попередньої проблеми, не лише ускладнює пошук першої помилки, але й додає 2-й власний помилку.

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

Будь-який з цих підходів дозволить уникнути мовчазних збоїв:

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

2. Киньте виняток, якщо він є нульовим.

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

IMsgSender* const msgSender_;

Тоді вказівник не може бути змінений після ініціалізації, тож якщо він був гарний при будівництві, він буде нормальним протягом життя об'єкта, який його містить. (Об'єкт вказав на буде НЕ бути константними.)

Це відверто небезпечно!

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

// Pre: vertex should never be null.
void transform_vertex(Vertex* vertex, ...)
{
    // Inserted by my "wise" co-worker.
    if (!vertex)
        return;
    ...
}

Я одного разу спробував зняти таку перевірку передумови в такій функції та замінивши її на, assertщоб побачити, що буде.

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

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

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

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

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

Чи доцільно для стандарту кодування вимагати, щоб кожен вказівник, відмінений у функції, спочатку перевірявся на NULL - навіть приватні члени даних?

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

assertце шлях сюди. Порушення передумов не повинно залишатися непоміченим, інакше закон Мерфі може легко спричинити.

Наприклад, Objective-C розглядає кожен виклик методу на nilоб'єкті як неоперативний, який оцінює нульове значення. Є певні переваги такого дизайнерського рішення в Objective-C з причин, запропонованих у вашому питанні. Теоретична концепція забезпечення нульового захисту кожного виклику методу має певні заслуги, якщо вона широко оприлюднена та послідовно застосовується.

Однак, код живе в екосистемі, а не у вакуумі. Поведінка, що охороняє нуль, була б неідіоматичною та дивною у C ++, а тому слід вважати шкідливою. Підсумовуючи, ніхто так не пише код C ++, тому не робіть цього! Однак, як зустрічний приклад, зауважте, що дзвінки на free()або deleteна NULLC та C ++ гарантовано не мають змоги.

У вашому прикладі, мабуть, варто було б розмістити твердження в конструкторі, що msgSenderє недійсним. Якщо конструктор називається метод на msgSenderвідразу ж, щось не таке твердження не буде необхідності, оскільки вона розбила б прямо там в будь-якому випадку. Однак, оскільки він просто зберігається msgSender для подальшого використання, з огляду на стек стеження того, SignalShutdown()як з'явилося значення , було б очевидно NULL, тому твердження в конструкторі значно спростить налагодження.

Ще краще, що конструктор повинен прийняти const IMsgSender&посилання, чого не може бути NULL.

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

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

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

Ви також повинні використовувати надійний інструмент для коректності коду, наприклад, покриття чи зміцнення. І вам слід звертатися до всіх попереджень компілятора.

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

Використання вказівника замість посилання скаже мені, що msgSenderце лише варіант, і тут нульова перевірка була б правильною. Фрагмент коду занадто повільний, щоб вирішити це. Можливо, є інші елементи, PowerManagerякі є цінними (або перевіреними) ...

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

Це залежить від того, що ви хочете статися.

Ви писали, що працюєте над «пристроєм побутової електроніки». Якщо яким - то чином, помилка , вводиться шляхом установки msgSender_на NULL, ви хочете

• пристрій для роботи, пропускаючи, SignalShutdownале продовжуючи решту своєї роботи, або
• пристрій виходить з ладу, змушуючи користувача перезапустити його?

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

Звичайно, якщо ви виберете варіант 1, життєво важливим фактором є assert(як рекомендують інші), щоб знизити ймовірність появи такого помилки непомітно під час розвитку. Нульовий охоронець тільки там для пом'якшення відмови у використанні продукції.if

Особисто я також віддаю перевагу підходу "до краху" для виробництва, але я розробляю бізнес-програмне забезпечення, яке можна легко виправити та оновити в разі помилок. Для побутової електроніки це може бути не так просто.