Додатковий рядок у блоці та додатковий параметр у чистому коді

Контекст

У Чистому коді на сторінці 35 написано

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

Я повністю згоден, це має багато сенсу.

Пізніше, на сторінці 40, йдеться про аргументи функції

Ідеальна кількість аргументів для функції дорівнює нулю (niladic). Далі йде один (монадичний), за ним близько два (діадічний). По можливості слід уникати трьох аргументів (тріадичних). Більше трьох (поліадичних) вимагає дуже спеціального обґрунтування - і тоді їх не можна використовувати. Аргументи важкі. Вони забирають багато концептуальної сили.

Я повністю згоден, це має багато сенсу.

Проблема

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

Або я використовую два рядки в блоці , один для створення речі, один для додавання його до результату:

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

Або я додаю аргумент до функції для списку, куди буде додана річ, зробивши її "на один аргумент гірше".

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

Питання

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

Ці вказівки - це компас, а не карта. Вони вказують на вас у розумному напрямку . Але вони насправді не можуть вам точно сказати, яке рішення є «найкращим». У якийсь момент вам потрібно перестати йти у напрямку, на який вказує ваш компас, адже ви прибули до місця призначення.

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

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

Якщо це можливо зробити краще, це зауваживши, що «перетворення всіх елементів зі списку в інший список» є загальною схемою, яку часто можна абстрагувати за допомогою функціональної map()операції. В C #, я думаю, це називається Select. Щось на зразок цього:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

Ідеальна кількість аргументів для функції дорівнює нулю (niladic)

Ні! Ідеальна кількість аргументів для функції - це один. Якщо він дорівнює нулю, то ви гарантуєте, що функція має доступ до зовнішньої інформації, щоб мати змогу виконувати дію. "Дядько" Боб зрозумів це дуже неправильно.

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

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

Але це дуже довго звитий (C #) код. Просто зробіть це так:

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

Порада "Чистий код" абсолютно неправильна.

Використовуйте два або більше рядків у циклі. Приховувати однакові два рядки у функції має сенс, коли вони є деякими випадковими математиками, для яких потрібен опис, але він нічого не робить, коли рядки вже є описовими. "Створити" та "Додати"

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

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

або

foreach(var flurp in ConvertToFlurps(badaBooms))...

Як зазначають інші, порада про те, що найкраща функція - це те, що не має аргументів, перекошується в ООП у кращому випадку, а в гіршому - погана порада.

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

І я пропоную третій, найкращий варіант:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

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

Версія з одним аргументом краща, але не в першу чергу через кількість аргументів.

Найважливіша причина, що це краще - це те, що він має менший зв'язок , що робить його більш корисним, простіше міркувати, простіше провести тестування і менше шансів перетворитися на копії + вставлені клони.

Якщо ви надасте мені з CreateFlurp(BadaBoom), я можу використовувати це з будь-яким типом контейнера для збору: Простий Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, і так далі. Але CreateFlurpInList(BadaBoom, List<Flurp>)завтра я повернуся до вас завтра з проханням, CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)щоб мій перегляд моделей міг отримати повідомлення про те, що список змінився. Гидота!

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

досить часто я опиняюсь, що створюю список з іншого списку

Це лише питання використання наявних інструментів. Найкоротша, найефективніша та найкраща версія:

var Flurps = badaBooms.ConvertAll(CreateFlurp);

Це не лише менший код для запису та тестування, він також швидший, тому що List<T>.ConvertAll()досить розумний, щоб знати, що в результаті буде така ж кількість елементів, як і вхід, і попередньо розподілити список результатів до потрібного розміру. У той час як ваш код (обидві версії) потребував розширення списку.

Пам’ятайте про загальну мету: полегшення коду для читання та обслуговування.

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

Наприклад, у вашому випадку, замінивши всю реалізацію на var

flups = badaBooms.Select(bb => new Flurp(bb));

може бути можливість. Або ви можете зробити щось на кшталт

flups.Add(new Flurp(badaBoom))

Іноді найчистіше і найчитабельніше рішення просто не впишеться в одну лінію. Так у вас буде два рядки. Не ускладнюйте розуміння коду, просто виконайте якесь довільне правило.

Ваш другий приклад (на мою думку) зрозуміти значно важче, ніж перший. Це не тільки те, що у вас є другий параметр, це те, що параметр модифікується функцією. Подивіться, що Чистий код повинен сказати з цього приводу. (Немайте книги під рукою прямо зараз, але я впевнений, що в основному це "не робити цього, якщо ви зможете цього уникнути").