Якщо є метод

bool DoStuff() {
    try {
        // doing stuff...
        return true;
    }
    catch (SomeSpecificException ex) {
        return false;
    }
}

чи варто його швидше називати IsStuffDone()?

Обидва імені може бути неправильно інтерпретовано користувачем: Якщо ім'я, DoStuff()чому воно повертає булеве? Якщо назва - IsStuffDone()невідомо, чи метод виконує завдання чи лише перевіряє його результат.

Чи існує умова для цього випадку? Або альтернативний підхід, оскільки цей вважається недосконалим? Наприклад, у мовах, які мають вихідні параметри, такі як C #, булева змінна статусу може бути передана методу як одна, і тип повернення методу був би void.

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

У .NET у вас часто є пари методів, коли один з них може кинути виняток ( DoStuff), а інший повертає булевий статус і, при успішному виконанні, фактичний результат за допомогою параметра out ( TryDoStuff).

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

Якщо Tryу вашій мові префікс рідкісний, ви, ймовірно, не повинні його використовувати.

Що робити, якщо ви просто кинули виняток з викликового коду?

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

• Якщо жодних винятків не буде, киньте дії А
• Якщо (наприклад) a FileNotFoundExceptionкинуто, вживайте дії B
• Якщо викинуто будь-який інший виняток, вживати заходів C

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

DoStuff() достатньо, і повертане значення функції повинно бути задокументовано, і вам не потрібно згадувати це у назві функції, шукаючи багато доступних API:

PHP

// this method update and return the number affected rows 
// called update instead of updateAndGetAffectedCount
$affected = $query->update(/* values */);

C-Різкий

// Remove item from the List
// returns true if item is successfully removed; otherwise, false.
public bool Remove( T item )

У Java API колекції визначає метод додавання, який повертає булева. Це в основному повертає, чи змінив колекцію додаток. Так що для a List, як правило, повертається true, оскільки елемент був доданий, тоді як для a Setвін може повернути помилковий, якщо елемент вже був, оскільки Sets дозволяють отримати кожен унікальний елемент не більше одного разу.

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

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

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

boolean doStuff() - returns true when successful

Важливо - задокументувати, що означає булева.

Зазвичай у мене є методи повернення OperationResult(або OperationResult<T>) та встановлення IsSuccessвластивості на OperationResultналежному рівні. Якщо метод "звичайний" недійсний, тоді повертається OperationResult, якщо метод "звичайний" повертає об'єкт, тоді повертається OperationResult<T>та встановлює Itemвластивість на OperationResultвідповідний спосіб. Я б також запропонував використовувати OperationResultтакі методи як .Failed(string reason)і .Succeeded(T item). OperationResultшвидко стає звичним типом у ваших системах, і розробники знайомляться з цим.

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

Наприклад, у мові Objective-C та iOS / Mac OS X SDK імена зазвичай йдуть уздовж рядків:

- (returndatatype) viewDidLoad {
- (returndatatype) isVisible {
- (returndatatype) appendMessage:datatype variablename with:datatype variablename {

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

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

Я хотів би запропонувати використовувати префікс "Спробувати". Це добре відома закономірність ситуацій, коли метод може досягти успіху чи ні. Цей шаблон іменування використовувався Microsoft в .NET Framework (наприклад, TryParseInt).

Але, можливо, мова йде не про називання. Йдеться про те, як ви проектуєте параметри вводу / виводу методу.

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

У C # я вважаю за краще використовувати параметр out. Використовуючи вихід, я маркую параметр як бічний параметр. Особливо те, що C # 6 підтримуватиме вбудовану змінну оголошення.

DoStuff(out var isStuffDone); // The out parameter name clearly states its purpose.
DoStuff(out var _); // I use _ for naming parameters that I am ignoring.

Я б вибрав ім'я, грунтуючись на основній ролі методу. Той факт, що цей метод повертає булеве значення, не містить префікса "Є". Будемо мати якийсь код Java, в якому досить широко використовується префікс 'Is'. Погляньте java.io.File.delete(). Він повертається boolean, але його не називають isFileDeleted(). Причина полягає в тому, що головна роль методу - видалення файлу. Хтось називає цей метод з наміром видалити файл.

Булева інформація є просто для того, щоб озвучити результат роботи. З іншого боку давайте подивимось java.util.Map.isEmpty(). Очевидно, ви викликаєте такий метод, щоб дізнатися, чи колекція порожня. Ви не хочете, щоб якісь речі були зроблені. Ви просто хочете з’ясувати, який зараз стан.

Тож особисто я б точно дотримувався DoStuff().

Це дещо дуже важливе питання для мене. Багато разів, коли я зберігаю застарілий код, я натрапляю на те, що я називаю особисто "методом брехні". Назва пропонує дію A, але тіло робить дію B. Найбільш химерний приклад використання методу геттера, що змінює дані в базі даних.