Англійська мова для пояснення нульових перевірок і опціональних ланцюгових рішень

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

Ключовий словник

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

• “Ми додали тут перевірку на нуль, оскільки це поле заповнюється лише після завершення користувачем процесу реєстрації, отже, для нових облікових записів воно може бути законно нульовим.” *

** Додаткове ланцюгування ** — синтаксис (як ?. в JavaScript/TypeScript), який безпечно отримує доступ до вкладеної властивості, повертаючи undefined замість відкидання, якщо проміжне значення є нульовим або не визначеним. “Використання опціонального ланцюга — user?.profile?.avatarUrl — є відповідним, оскільки будь-який з цих трьох рівнів може бути законно відсутнім залежно від стану облікового запису.”

** Оборонне кодування ** — написання коду, який захищає від несподіваних або недійсних станів, навіть тих, які « не повинні » відбутися згідно з поточним типом контракту. “Це більше оборонне, ніж строго необхідно, враховуючи наші типи, але я б залишив перевірку — це значення походить від зовнішнього API, якому ми не повністю довіряємо, щоб відповідати його документованій схемі.”

** Non- null assertion ** — асерція, яка стосується тільки системи типів (наприклад, ! у TypeScript), яка повідомляє компілятору, що значення не є нульовим, без фактичної перевірки під час виконання; вона приглушує помилку типу, але не запобігає аварії, якщо ви помиляєтеся. “Я б уникнув не- нульового твердження тут — воно вимикає перевірку типу, але якщо припущення колись буде неправильним, воно буде викинуто під час виконання з менш корисною помилкою, ніж явна перевірка дала б.”

** Резервне значення ** — типове значення, яке буде використано, якщо значення виявиться нульовим або не визначеним, обраним спеціально для контексту, а не як загальний символ заміщення. “Замість показу « не визначено » в інтерфейсі користувача, ми повертаємось до « Невідомий користувач » — резервне значення, яке є специфічним для того, що користувач насправді бачить, а не просто технічним типовим.»

Звичайні фрази

• «Чи може це значення бути нульовим тут, або ця перевірка не потрібна, враховуючи наші типи?»
• «Це оборонне кодування для значення, яке ми не повністю контролюємо (зовнішній API / дані спадщини).»
• «Я б уникав не-нульового твердження — явна перевірка дає кращу помилку, якщо припущення неправильне»
• “What should the fallback be here if this value is missing?”
• “Ця нульова перевірка є зайвою — тип вже гарантує, що це не може бути нульовим в цей момент.”

Приклади висловлювань

Обґрунтування нульової перевірки в описі PR:

• “Додано перевірку на нуль на order.shippingAddress перед цим блоком. Замовлення, створені до міграції, що вимагає адреси (до 2024 року), все ще можуть мати нульову адресу в базі даних, навіть якщо тип більше не дозволяє її для нових замовлень. ”*

З повагою, відкидаю не потрібну перевірку в рецензії:

• “Я думаю, що ця перевірка може бути зайвою — на даний момент у функції user вже було перевірено вищезгаданим середовищем, отже TypeScript вже має знати, що воно не є нульовим. Я щасливий бути неправильним, якщо є шлях, який я пропустив»

Пояснення вибору між необов’ язковим з’ єднанням і раннім поверненням:

• “Я використовував опціональне з’ єднання замість раннього повернення, оскільки відсутність profile не є станом помилки для цього компонента — це просто означає, що ми відображаємо аватар- замінник. Раннє повернення було б доречним, якщо відсутній профіль означав, що щось дійсно пішло не так»

Обговорення вибору резервного значення у розробці або перегляді коду: *“Замість того, щоб повертатися до порожнього рядка для назви вікна, я б запропонував « Невідомий користувач » — порожній рядок може виглядати як помилка відтворення для когось, хто тестує інтерфейс користувача, тоді як « Невідомий користувач » чітко повідомляє, що дані відсутні з законних причин.” *

Професійні поради

• Обґрунтуйте перевірку нульових значень, назвавши ** чому значення може бути нульовим ** (історія міграції даних, зовнішній API, додатковий поток користувача) — « просто для безпеки » є слабшим обґрунтуванням, ніж конкретна причина.
• Коли ви ставите під сумнів нульову перевірку у перегляді, формулюйте це як запитання (« Чи може це насправді бути нульовим?»), а не як твердження — ви можете пропустити шлях коду, і ця форма запрошує скоріше виправлення, ніж оборону.
• Віддавати перевагу додатковому ланцюжку з резервом над ненульовими твердженнями, коли відсутнє значення є нормальним, не помилковим станом — резервуйте ненульові твердження для випадків, про які ви справді впевнені.
• Розрізняйте “це не повинно статися, але ми захищаємося від цього в будь-якому випадку” від “це може легітимно статися” явно у вашому обґрунтуванні - вони вимагають різних відповідей (записування/попередження проти мовного резерву).
• Виберіть резервні значення, які ** мають сенс у контексті **, а не типові — добре обраний резерв повідомляє про поточний стан всім, хто побачить його пізніше.

Практичні вправи

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

Навигація незгодні конструктивно - фрази для нульових перевірок і опціонального ланцюгування

Погляньмо правді в очі: дискусії навколо нульових перевірок і додаткового ланцюгування можуть швидко стати наповнені розчаруванням. Часто розробники стрибуть прямо до критики («Чому ви не перевірили null?») без розгляду *причин * за рішенням або пропонування конструктивних альтернатив. Ключовим є те, щоб оформити ці розмови як спільне вирішення проблем, зосереджуючись на безпеці і підтримці, а не просто вказуючи на сприйняті помилки. Важливим елементом є використання точної мови, яка уникає обвинувальних тонів.

Тут пригодиться нюансований словник. Замість того, щоб сказати « Це поганий код, оскільки він не обробляє null », спробуйте такі фрази: « Я хвилююся щодо потенційних ризиків NullPointerException » або « Давайте дослідимо, як ми можемо додати шар захисного програмування, щоб враховувати потенційні відсутні дані ». Аналогічно, коли обговорюється додатковий зв’ язок ( ?. ), уникайте таких тверджень, як « Це занадто складно ». Замість цього ви можете сказати: « Додатковий зв’ язок пропонує короткий спосіб обробки потенційних нульових значень — давайте переконаємося, що ми повністю розуміємо наслідки і документуємо їх відповідно ». Підкреслення * переваги * підходу разом з ризиком завжди є більш ефективним. Визнаючи, що різні розробники можуть мати різні перспективи оптимальних рішень, сприяє більш позитивному діалогу.

Також важливо визнати контекст, в якому був написаний код. Швидке повідомлення Slack може бути таким: «Привіт @john, я просто хотів позначити цю область — чи можемо ми коротко обговорити стратегії для обробки потенційних значень null тут? Я особливо зацікавлений у розумінні того, як це вписується в загальний потік даних.” Це демонструє готовність залучати і розуміти процес мислення розробника.

Нарешті, при написанні описів PR, прагніть до ясності і точності. Замість простого повідомлення « Додано нульові перевірки », напишіть щось на зразок: « Впроваджено захисні методи програмування, включаючи додатковий ланцюг для елегантної обробки потенційних значень null у структурі даних профілю користувача. Це зменшує ризик NullPointerException під час подальших операцій.” Цей рівень деталізації демонструє професіоналізм і прихильність до якості коду, незалежно від технічних нюансів.