Названі аргументи (параметри) як допомогу для читання

Давно я багато програмував в ADA, і було нормально називати аргументи при виклику функції - SomeObject.DoSomething (SomeParameterName => someValue);

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

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

contentFetcher.DownloadNote (примітка, посібник: правда);

Я думаю, що я міг би створити Enums замість того, щоб використовувати true або false (в цьому випадку посібник, автоматичний).

Що ви думаєте про час від часу використання названих аргументів, щоб полегшити читання коду?

Це було запропоновано при розробці C ++, і Stroustrup обговорює це у своєму "Дизайні та еволюції C ++", стор. 153 і далі. Пропозиція була добре сформована і спиралася на попередній досвід роботи з Ада. Він не був прийнятий.

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

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

З ним можна також обробляти за допомогою об'єктів, а не викликів функцій. Замість виклику GetWindow з десятком параметрів створіть клас Window з десятком приватних змінних та додайте сетерів за необхідності. Прив’язуючи сетери, можна написати щось подібне my_window.SetColor(green).SetBorder(true).SetBorderSize(3);. Також можливі різні функції з різними типовими значеннями, які викликають функцію, яка насправді виконує роботу.

Якщо ви просто переживаєте про ефект документації contentFetcher.DownloadNote(note, manual : true);, ви завжди можете написати щось подібне contentFetcher.DownloadNote(note, /* manual */ true);, тому це навіть не дуже допомагає в документації.

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

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

Якщо у методів є лише 1 або 2 параметри, і з назви методу зрозуміло, що таке параметр, то названий параметр нічого не додає. Це ідеальний випадок.

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

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

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

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

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

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

Я думаю, що це корисніше в мовах, що не входять в ООС, де у вас може бути одна функція, яка повинна виконувати щось декількома дещо різними способами, а спосіб, яким він визначає, що робити, заснований на значеннях параметрів. У світі OOP ми би просто перевантажили цю функцію, але коли це неможливо, то ви повернетесь, передаючи купу прапорів (або купу значень, і чи є вони передані - чи це прапор).

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