Коли і чому слід використовувати void (замість, наприклад, bool / int)

Іноді я стикаюся з методами, коли розробник вирішив повернути щось, що не є критично важливим для функції. Я маю на увазі, дивлячись на код, він, мабуть, працює так само добре, як voidі після хвилини роздуму, я запитую "Чому?" Це звучить знайомо?

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

Залежно від ситуації, повернення значка intможе дати абоненту знати кількість рядків або об'єктів, на які впливає метод (наприклад, 5 записів, збережених у MSSQL). Якщо такий метод, як "InsertSomething", повертає булевий, я можу мати метод, призначений для повернення у trueвипадку успіху false. Абонент може вибирати чи не діяти на цій інформації.

З іншої сторони,

• Чи може це призвести до менш чіткої мети виклику методу? Погане кодування часто змушує мене двічі перевірити вміст методу. Якщо він щось повертає, він говорить вам, що метод такого типу, що вам потрібно щось робити з повернутим результатом.
• Інша проблема, якщо впровадження методу вам невідоме, що розробник вирішив повернути, що не є критично важливим? Звичайно, ви можете прокоментувати це.
• Повертане значення повинно бути оброблене, коли обробка могла закінчитися в кінцевій дузі методу.
• Що відбувається під кришкою? Чи отримав викликаний метод falseчерез помилку, яку викинули? Або він повернув помилку через оцінений результат?

Який у вас досвід з цим? Як би ви діяли з цього приводу?

У разі повернення значення bool для вказівки на успіх або невдачу методу, я віддаю перевагу Tryпарадигмі -prefix, яка використовується в різних методах .NET.

Наприклад, void InsertRow()метод може кинути виняток, якщо вже існує рядок з тим самим ключем. Питання в тому, чи обґрунтовано припускати, що абонент гарантує, що їх рядок є унікальним перед викликом InsertRow? Якщо відповідь "ні", то я б також вказав, bool TryInsertRow()що повертає помилкове значення, якщо рядок вже існує. В інших випадках, таких як помилки підключення db, TryInsertRow все-таки може викинути виняток, припускаючи, що підтримка підключення db є відповідальністю абонента.

IMHO, що повертає "код статусу", походить від історичних часів, перш ніж винятки стали звичним явищем для мов середнього та вищого рівня, таких як C #. Сьогодні краще викинути виняток, якщо якась несподівана помилка завадила досягти успіху вашому методу. Таким чином, ви впевнені, що помилка не залишиться непоміченою, і абонент може впоратися з нею як слід. Тож у цих випадках цілком чудово для методу повернути нічого (тобто void) замість булевого прапора статусу або цілого коду статусу. (Звичайно, слід задокументувати, які винятки метод може кинути і коли.)

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

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

Відповідь Петра добре висвітлює винятки. Інші питання тут стосуються розділення команд-запитів

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

Кілька випадків порушення принципу CQS - це гарна ідея. Зазвичай це стосується безпеки продуктивності або потоку.

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

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