Чи є визначення змінної для назви аргументу методу гарною практикою?

Для читабельності я часто опиняюсь тим, що визначаю тимчасові змінні під час виклику функцій, таких як наступний код

var preventUndo = true;
doSomething(preventUndo);

Коротка версія цього до цього буде,

doSomething(true);

Але коли я повертаюся до коду, мені часто цікаво, на що trueйдеться. Чи існує умова для такого роду головоломки?

Пояснення змінних

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

Код хорошої якості повідомляє про намір читача; і як професійний розробник читабельність та ремонтопридатність - ваші цілі №1.

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

editButton.Enabled = (_grid.SelectedRow != null && ((Person)_grid.SelectedRow).Status == PersonStatus.Active);

порівняно з дещо довшим, але, можливо, зрозумілішим:

bool personIsSelected = (_grid.SelectedRow != null);
bool selectedPersonIsEditable = (personIsSelected && ((Person)_grid.SelectedRow).Status == PersonStatus.Active)
editButton.Enabled = (personIsSelected && selectedPersonIsEditable);

Булеві параметри

Ваш приклад насправді підкреслює, чому булеві інтерфейси в API часто є поганою ідеєю - з боку виклику вони нічого не роблять, щоб пояснити, що відбувається. Поміркуйте:

ParseFolder(true, false);

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

ParseFolder(ParseBehaviour.Recursive, CompatibilityOption.Strict);

Редагувати:

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

Не пишіть код, який вам не потрібен.

Якщо вам doSomething(true)важко зрозуміти, вам слід додати коментар:

// Do something and prevent the undo.
doSomething(true);

або, якщо мова його підтримує, додайте ім'я параметра:

doSomething(preventUndo: true);

В іншому випадку покладайтеся на свій IDE, щоб дати вам підпис названого методу:

Випадки, коли це корисно

Введення додаткової змінної може бути корисним:

1. Для налагодження:

   var productId = this.Data.GetLastProductId();
   this.Data.AddToCart(productId);
   

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

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

   // Even with indentation, this is unreadable.
   var doSomething(
       isSomethingElse ? 0 : this.getAValue(),
       this.getAnotherOne() ?? this.default,
       (a + b + c + d + e) * f,
       this.hello ? this.world : (this.hello2 ? this.world2 : -1));
   

3. Якщо оцінка параметра занадто складна. Приклад коду, який я бачив:

   // Wouldn't it be easier to have several if/else's (maybe even in a separate method)?
   do(something ? (hello ? world : -1) : (programmers ? stackexchange : (com ? -1 : 0)));
   

Чому б не в інших випадках?

Чому не слід створювати додаткові змінні у простих випадках?

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

2. Але через ризик відмежування імені ви надаєте змінній на ім'я параметра.

   Приклад:

   Скажімо, початковий код:

   void doSomething(bool preventUndo)
   {
       // Does something very interesting.
       undoHistory.removeLast();
   }
   
   // Later in code:
   var preventUndo = true;
   doSomething(preventUndo);
   

   Пізніше розробник працював над doSomethingповідомленнями про те, що нещодавно історія скасування запровадила два нові методи:

   undoHistory.clearAll() { ... }
   undoHistory.disable() { ... }
   

   Зараз, preventUndoздається, не дуже зрозуміло. Чи означає це, що буде попереджено лише останню дію? А може це означає, що користувач більше не зможе використовувати функцію скасування? Або що історія скасування буде очищена? Чіткіші назви були б:

   doSomething(bool hideLastUndo) { ... }
   doSomething(bool removeAllUndo) { ... }
   doSomething(bool disableUndoFeature) { ... }
   

   Отже, тепер у вас є:

   void doSomething(bool hideLastUndo)
   {
       // Does something very interesting.
       undoHistory.removeLast();
   }
   
   // Later in code, very error prone, while the signature of the method is clear:
   var preventUndo = true;
   doSomething(preventUndo);
   

А як із переліками?

Деякі інші люди запропонували використовувати переписки. Хоча вона вирішує найближчу проблему, вона створює більшу. Давайте подивимось:

enum undoPrevention
{
    keepInHistory,
    prevent,
}

void doSomething(undoPrevention preventUndo)
{
    doTheJob();
    if (preventUndo == undoPrevention.prevent)
    {
        this.undoHistory.discardLastEntry();
    }
}

doSomething(undoPrevention.prevent);

Проблеми з цим:

1. Це занадто багато коду. if (preventUndo == undoPrevention.prevent)? Серйозно ?! Я не хочу писати подібні слова ifкожен раз.

2. Додавання елемента до enum пізніше дуже спокусливо, якщо я використовую той самий enum деінде. Що робити, якщо я його модифікую так:

   enum undoPrevention
   {
       keepInHistory,
       prevent,
       keepButDisable, // Keeps the entry in the history, but makes it disabled.
   }
   

   Що буде зараз? Чи буде doSomethingметод працювати, як очікувалося? Щоб запобігти цьому, потрібно буде написати цей метод таким чином з самого початку:

   void doSomething(undoPrevention preventUndo)
   {
       if (![undoPrevention.keepInHistory, undoPrevention.prevent].contains(preventUndo))
       {
           throw new ArgumentException('preventUndo');
       }
   
       doTheJob();
       if (preventUndo == undoPrevention.prevent)
       {
           this.undoHistory.discardLastEntry();
       }
   }
   

   Варіант, в якому використовуються булеви, починає виглядати так приємно!

   void doSomething(bool preventUndo)
   {
       doTheJob();
       if (preventUndo)
       {
           this.undoHistory.discardLastEntry();
       }
   }
   

Також не слід писати методи з булевими прапорами.

Цитуючи Роберта К. Мартіна, у своїй книзі «Чистий кодекс» (ISBN-13 978-0-13-235088-4) йдеться про те, що «Передача булевої функції у функцію - це справді жахлива практика».

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

DoSomething()
{...

DoSomethingUndoable()
{....

Якщо ви подивитесь на два класи, щоб побачити, наскільки вони поєднані, одна з категорій - це з'єднання даних , яке посилається на код у одному класі методів виклику іншого класу та просто передавання даних, наприклад, за який місяць ви хочете отримати звіт та інший категорія - це керування сполученням , викликом методів і передачею чогось, що контролює поведінку методу. Приклад, який я використовую в класі - це verboseпрапор або reportTypeпрапор, але preventUndoтакож є чудовим прикладом. Як ви недавно продемонстрували, керування з'єднанням важко читати код виклику та розуміти, що відбувається. Це також робить код виклику вразливим до змін, doSomething()які використовують один і той же прапор для управління і скасуванням, і архівуванням, або додаванням іншого параметра доdoSomething() керувати архівуванням, таким чином порушуючи свій код тощо.

Проблема полягає в тому, що код занадто щільно пов'язаний. Передача булінгу для контролю поведінки, на мій погляд, є ознакою поганого API. Якщо ви володієте API, змініть його. Два методи, doSomething()і doSomethingWithUndo(), було б краще. якщо ви не володієте ним, напишіть два способи обгортки самостійно в код, яким ви володієте, і один з них дзвонить, doSomething(true)а другий дзвонить doSomething(false).

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

Змінна повинна бути названа за їх роллю в нинішньому обсязі. Не область, куди вони надсилаються.

Що я б робив у JavaScript - це функція приймати об’єкт як єдиний параметр, подібний до цього:

function doSomething(settings) {
    var preventUndo = settings.hasOwnProperty('preventUndo') ? settings.preventUndo : false;
    // Deal with preventUndo in the normal way.
}

Потім зателефонуйте за допомогою:

doSomething({preventUndo: true});

Мені подобається використовувати мовні функції, щоб я зрозуміти себе. Наприклад, у C # ви можете вказати параметри за назвою:

 CallSomething(name: "So and so", age: 12, description: "A random person.");

У JavaScript я зазвичай вважаю за краще використовувати об'єкт параметрів як аргумент з цієї причини:

function doSomething(args) { /*...*/ }

doSomething({ name: 'So and so', age: 12, description: 'A random person.' });

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

Я вважаю, що це найпростіше і найпростіше для читання:

enum Undo { ALLOW, PREVENT }

doSomething(Undo u) {
    if (Undo.ALLOW == u) {
        // save stuff to undo later.
    }
    // do your thing
}

doSomething(Undo.ALLOW);

MainMaе це не любить. Можливо, нам доведеться погодитися не погодитися, або ми можемо використовувати рішення, яке пропонує Джошуа Блох:

enum Undo {
    ALLOW {
        @Override
        public void createUndoBuffer() {
            // put undo code here
        }
    },
    PREVENT {
        @Override
        public void createUndoBuffer() {
            // do nothing
        }
    };

    public abstract void createUndoBuffer();
}

doSomething(Undo u) {
    u.createUndoBuffer();
    // do your thing
}

Тепер, якщо ви коли-небудь додасте Undo.LIMITED_UNDO, ваш код не буде компілюватися, якщо ви не реалізуєте метод createUndoBuffer (). І в doSomething () немає if (Undo.ALLOW == u). Я робив це обома способами, і другий метод досить важкий і трохи важко зрозуміти, коли перерахунок "Скасувати" розшириться на сторінки та сторінки коду, але це змушує задуматися. Зазвичай я дотримуюся більш простого методу заміни простого булевого перерахунку на 2 значення, поки у мене немає підстав для зміни. Коли я додаю третє значення, я використовую свій IDE для "Find-usages" і тоді все виправляю.

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

Я можу придумати дві альтернативи, які не передбачають додаткової змінної:

1. Використовуйте додатковий коментар

doSomething(/* preventUndo */ true);

2. Використовуйте двозначне перерахунок замість булевого

enum Options
{
    PreventUndo,
    ...
}

...

doSomething(PreventUndo);

Ви можете використовувати альтернативу 2, якщо ваша мова підтримує переписки.

EDIT

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

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

if (preventUndo)
{
    ...
}

ти маєш

if (undoOption == PreventUndo)
{
    ...
}

або

switch (undoOption)
{
  case PreventUndo:
  ...
}

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

Я згоден з тим, що сказав @GlenPeterson:

doSomething(Undo.ALLOW); // call using a self evident enum

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

//Two methods    

doSomething()  // this method does something but doesn't prevent undo

doSomethingPreventUndo() // this method does something and prevents undo

Оскільки ви питаєте в основному про JavaScript, використовуючи coffeescript, ви можете мати такий аргумент, як синтаксис, дуже просто:

# declare method, ={} declares a default value to prevent null reference errors
doSomething = ({preventUndo} = {}) ->
  if preventUndo
    undo = no
  else
    undo = yes

#call method
doSomething preventUndo: yes
#or 
doSomething(preventUndo: yes)

компілює до

var doSomething;

doSomething = function(_arg) {
  var preventUndo, undo;
  preventUndo = (_arg != null ? _arg : {}).preventUndo;
  if (preventUndo) {
    return undo = false;
  } else {
    return undo = true;
  }
};

doSomething({
  preventUndo: true
});

doSomething({
  preventUndo: true
});

Повеселіться на http://js2coffee.org/, щоб спробувати можливості

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

var doSomethingOptions = new Array();

doSomethingOptions["PREVENTUNDO"] = true;
doSomethingOptions["TESTMODE"] = false;

doSomething( doSomethingOptions );

// ...

function doSomething( doSomethingOptions ){
    // Check for null here
    if( doSomethingOptions["PREVENTUNDO"] ) // ...
}

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

Інша можливість - мати об’єкт, і це також можливо в Javascript. Я не на 100% впевнений, що це синтаксично правильно. Подивіться на такі моделі, як Фабрика, для подальшого натхнення.

function SomethingDoer( preventUndo ) {
    this.preventUndo = preventUndo;
    this.doSomething = function() {
            if( this.preventUndo ){
                    // ...
            }
    };
}

mySomethingDoer = new SomethingDoer(true).doSomething();

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

Я думаю, що корисно зауважити, що ця проблема в основному відвертається, коли мова програмування підтримує названі аргументи / аргументи ключових слів, як-от у C # 4 та Python, або де аргументи методу переплітаються в назві методу, як у Smalltalk або Objective-C.

Приклади:

// C# 4
foo.doSomething(preventUndo: true);

# Python
foo.doSomething(preventUndo=True)

// Objective-C
[foo doSomethingWith:bar shouldPreventUndo:YES];

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

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

int preventUndo = true;
doSomething(preventUndo);

Хороший компілятор для мов низького рівня, таких як C ++, оптимізує машинний код вище 2 рядка, як показано нижче:

doSomething(true); 

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

Також корисно використовувати змінну у випадку, якщо вона стане змінною пізніше і може приймати й інші значення.