Розділити обчислення вартості повернення та виписку про повернення однорядковими методами?

У мене з колегою було обговорено питання про порушення returnтвердження та твердження, яке обчислює повернене значення у два рядки.

Наприклад

private string GetFormattedValue()
{
    var formattedString = format != null ? string.Format(format, value) : value.ToString();
    return formattedString;
}

замість

private string GetFormattedValue()
{
    return format != null ? string.Format(format, value) : value.ToString();
}

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

Моє запитання полягає в тому, якщо все-таки є дійсним питання писати код менш зрозумілим, просто щоб полегшити налагодження? Чи є якісь додаткові аргументи для варіанта з розділеним розрахунком та returnвисловленням?

Введення пояснення змінних - це добре відомий рефакторинг, який іноді може допомогти зробити складні вирази легшими для читання. Однак у наведеному випадку

• додаткова змінна не "пояснює" нічого, що не зрозуміло з оточуючої назви методу
• вислів стає ще довшим, тому (трохи) менш читабельним

Більше того, новіші версії налагоджувача Visual Studio можуть у більшості випадків показувати повернене значення функції, не вводячи зайву змінну (але будьте обережні, ознайомтеся з цим старшим повідомленням SO та різними відповідями ).

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

З огляду на факти, які:

а) На остаточний код немає впливу, оскільки компілятор оптимізує змінну в сторону.

b) Окремий розділ розширює можливість налагодження.

Я особисто прийшов до висновку, що це хороша практика відокремлювати їх 99% часу.

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

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

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

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

У відповідь на ваші запитання:

Моє запитання полягає в тому, якщо все-таки є дійсним питання писати код менш зрозумілим, просто щоб полегшити налагодження?

Так. Насправді, частина вашого попереднього твердження мені здається (без образи) трохи недалекоглядною (див. Жирний шрифт нижче) " Його аргументом було те, що колишній варіант простіше налагодити - що є досить маленькою заслугою , оскільки VisualStudio дозволяє нам дуже детально перевірити висловлювання, коли виконання припинено через пункт пробою ».

Полегшення налагодження (майже) ніколи не викликає « малих заслуг », оскільки, за деякими оцінками, 50% часу програміста витрачається на налагодження ( Reverseble Debugging Software ).

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

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

ПРИМІТКА: Правила бізнесу можуть бути краще подані в базі даних, оскільки вони можуть часто змінюватися. Тим не менш, чітке кодування в цій області все ще має першорядне значення. ( Як побудувати двигун бізнес-правил )

Я б пішов ще далі:

private string GetFormattedValue()
{
    if (format != null) {
        formattedString = string.Format(format, value);
    } else {
        formattedString = value.ToString()
    }
    return formattedString;
}

Чому?

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

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

Моя краща альтернатива - якщо ви "отримуєте повернення якомога швидше натовпу", а не проти багаторазового повернення методу:

private string GetFormattedValue()
{
    if (format != null) {
        return string.Format(format, value);
    }

    return value.ToString();
}

Отже, ви можете переглянути останнє повернення, щоб побачити, що таке за замовчуванням.

Важливо бути послідовним - і всі ваші методи дотримуються тієї чи іншої конвенції.

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

Люди також недооцінюють час, який вони проводять налагодження. Вони недооцінюють, скільки часу вони можуть витратити, переслідуючи довгу помилку. З тестуванням я знаю відразу, коли додав помилку. Це дозволяє мені виправити помилку негайно, перш ніж вона може повзати та сховатися. Є кілька речей, які більш засмучують чи витрачають час, ніж налагодження. Чи не було б це пекло набагато швидше, якби ми просто не створили помилок в першу чергу?

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

Щодо фокусу вашого питання, переміщення повернутого оператора на посилання змінною ...

Це запитання робить два припущення, з якими я не згоден:

1. Що другий варіант зрозуміліший чи простіший для читання (я кажу, що навпаки правда), і

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

Виконуючи щось із названої змінної рідко коли-небудь ускладнює читання, майже завжди відбувається навпаки. Конкретний спосіб, коли хтось це робить, може спричинити проблеми, як, наприклад, коли оверлонд самодокументації робить це, var thisVariableIsTheFormattedResultAndWillBeTheReturnValue = ...очевидно, це погано, але це окрема проблема. var formattedText = ...добре.

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

Загалом, і ви запитували загальне правило (ваш приклад був саме таким, приклад узагальненої форми), всі пункти, зроблені на користь варіанту 1 (2-лайнера), є правильними. Це хороші вказівки. Але вказівки повинні бути гнучкими. Наприклад, проект, над яким я зараз працюю, має максимум 80 символів на рядок, тому я розбиваю багато рядків, але я зазвичай знаходжу рядки 81-85 символів, які було б незручно розділити або зменшити читабельність, і я залишаю їх межа.

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