Как корректно переносить длинные команды на разные строки, по аналогии с method chaining?

@Honey Badger · Регистрация: 09.02.2023

Студворк — интернет-сервис помощи студентам

Приветствую всех! Method chaining (цепочка вызовов) - основная концепция Fluent Interface. Примером использования служит LINQ, а также операторы конвейера (pipe operator), которые есть в некоторых языках - например, оператор "|>" в F#.

Однако, на сколько я знаю, есть правила, по которым можно корректно переносить длинные строки кода на разные строки в редакторе без использования специальных операторов и без разрыва команды (без создания промежуточных переменных).
Подскажите, пожалуйста, как можно корректно разделить на разные строки данную строку кода:

C#
1
return new Project(ProjectFileHelper.ExtractFilePaths(File.ReadAllText(pathToFile)).Select(path => CodeFile.CreateFromFile(path)).ToArray());

В c# специальные операторы для упрощения этой задачи отсутствуют, однако на StackOverflow мне предложили сделать метод расширения, который сможет упростить эту задачу:

C#
1
2
3
4
5
6
7
public static class PipeExtension
{
    public static TOut Pipe<TIn, TOut>(this TIn input, Func<TIn, TOut> fn)
    {
        return fn(input);
    }
}

С его помощью длинную строку можно записать вот так:

C#
1
2
3
4
5
6
7
return new Project(
    pathToFile
        .Pipe(x => File.ReadAllText(x))
        .Pipe(x => ProjectFileHelper.ExtractFilePaths(x))
        .Select(x => CodeFile.CreateFromFile(x))
        .ToArray()
    );

Согласитесь, это уже выглядит намного лучше, и намного легче читается и понимается. Однако не всякому работодателю это понравится, и не на каждом проекте разрешат добавить в проект такую функцию. Есть способ и без применения подобных хитростей, просто грамотно разложить вызов разных функций по разным строкам в соответствиии с их уровнем вложенности. Но у меня, что я ни пробовал, получается каша...

@IamRain · 18.11.2024, 12:20

Andrey-MSK,

Не по теме:

IBackgroundTaskQueue - а бывает еще ForegroundTaskQueue?

@Andrey-MSK · 18.11.2024, 12:30

IamRain,

Не по теме:

Ну назвалося так...

@wizard41 · 18.11.2024, 12:30

Honey Badger, то что ты не понимаешь суть метода TOut, который привел - это пол беды. Но то что ты его связал с переносом строк - это 100% провал.
Тебе сразу в первых же двух постах намекнули, что затронутый вопрос - это не то, о чем следует переживать. Зачем упорно продавливать этот вопрос на основании каких-то одному тебе известных правилах?
Т.е. по сути у тебя вопросы бестолковые, каждый раз. Вот и получаешь "оплеухи".

@Honey Badger · 18.11.2024, 12:49 **[ТС]**

Сообщение от wizard41

Honey Badger, то что ты не понимаешь суть метода TOut, который привел - это пол беды. Но то что ты его связал с переносом строк - это 100% провал.

То, что ты принял возвращаемое значение метода Pipe за его название - вот это 100% провал. Советую почитать что такое дженерики и Method Chaining, может быть тогда станет наконец ясна суть вопроса.
А метод Pipe преобразует возвращемое значение метода, из которого он вызывается, в аргумент следующего метода, позволяя избавиться от сильной вложенности аргументов за счет преобразования их в последовательные вызовы. Удобство записи это лишь бонус, на котором я в данном вопросе акцентировал внимание.

@wizard41 · 18.11.2024, 13:04

Honey Badger, трудный ты какой-то.
Мне не надо ничего советовать читать - все что надо, давно уже прочитано.

Сообщение от Honey Badger

позволяя избавиться от сильной вложенности аргументов

все верно, однако как это коррелирует с некими "правилами", по которым якобы нужно делать перенос?
Т.е. замена одного на другое как-то спасла ситуацию? Ну бред же.

Добавлено через 1 минуту

Сообщение от Honey Badger

принял возвращаемое значение метода Pipe за его название

обыкновенная опечатка - не то скопировал.

@Honey Badger · 18.11.2024, 13:32 **[ТС]**

Сообщение от wizard41

трудный ты какой-то.

Я нормальный. Нормально задал нормально сформулированный вопрос, и нормально всем отвечаю, спорю лишь по фактам и не забываю поблагодарить за помощь. Бери пример.

Сообщение от wizard41

Ну бред же.

Бред - это лазить на форуме по темам которые тебе не интересны и писать в них комментарии которые не помогают разобраться в вопросе, стремясь лишь унизить автора.

Сообщение от wizard41

как это коррелирует с некими "правилами", по которым якобы нужно делать перенос?
Т.е. замена одного на другое как-то спасла ситуацию?

Спасла, потому что позволила подвести способ записи под принцип, принятый в LINQ, что как раз и является стандартизацией.

@wizard41 · 18.11.2024, 13:46

Honey Badger, выходит, тебя "унизили" первые отвечающие. Общий посыл этих ответов был таков: ты обращаешь внимание совсем не на то, на что следует.
Если ты эту чушь будешь демонстрировать на каком-либо собесе, то твоя 'забота' о мнимом зрительном удобоваримом восприятии кода вывалится в полный швах. Это последнее, о чем тебя спросят где-либо, если вообще спросят. А вот на то, что ты готов поступиться производительностью/временем или еще чем-нибудь ради надуманных правил - на это точно обратят внимание, и не в твою пользу.

Сообщение от Honey Badger

Я нормальный

Нормальный - прислушивается к тому, что говорят люди из отрасли, куда ты так хочешь попасть.

@kotelok · 18.11.2024, 14:19

Сообщение от Honey Badger

Согласитесь, это уже выглядит намного лучше, и намного легче читается и понимается.

Не. Ваш изначальный код, пусть даже он не отформатирован и имеет лишнюю вложенность, понятен сразу любому разработчику (а если хоть как-то отформатировать переносами/отступами, то ещё и читаться будет легко).

Тот же код, записанный через неизвестный метод расширения, вынуждает идти изучать документацию/сигнатуру этого метода. И запоминать.

И название 'Pipe' само по себе никаких подсказок не даёт о сути происходящего. Ну т.е. в изначальном коде, даже какие-то свои методы/классы имеют названия, по которым хотя бы примерно можно понять их назначение. А 'Pipe' - что оно значит в данном контексте?

@Honey Badger · 18.11.2024, 14:36 **[ТС]**

Сообщение от wizard41

Общий посыл этих ответов был таков: ты обращаешь внимание совсем не на то, на что следует

Нет, общий посыл этих ответов был в том, что люди просто высказывали свое мнение. Мне не жалко, пусть высказывают. Мне же нужны факты. А вот сослаться на несколько существующих стандартов (хоть то же соглашение о написании кода на C#) и объяснить, что (предположим) в каждом из них разный стандарт - это ответ по делу, который можно обсуждать.

Сообщение от wizard41

А вот на то, что ты готов поступиться производительностью/временем или еще чем-нибудь ради надуманных правил

Уууууу... Времена компов, которые могли заметить добавление пары лишних делегатов давно в прошлом, и потому первостепенная задача программиста - сделать код понятным и читаемым. То же ООП, например. Знаешь, во сколько раз оно замедляет программу? Тем не менее ООП используется повсеместно. Поэтому тут ты однозначно не прав.

Сообщение от wizard41

Нормальный - прислушивается к тому, что говорят люди из отрасли, куда ты так хочешь попасть.

Я это и делаю. Сказать что "никаких стандартов нет" и "нигде, где я работал, стандарты не использовались" - это не одно и то же. Первое - мнение, второе - факт, пусть и небольшой. Кроме того, сидеть на форуме для программистов еще не значит принадлежать к людям из отрасли, поэтому случайные мнения меня мало интересуют, мне нужны факты.

@wizard41 · 18.11.2024, 14:47

Сообщение от Honey Badger

То же ООП, например. Знаешь, во сколько раз оно замедляет программу?

Мда... Похоже, очень рано тебе лезть в это все. Связывать несвязываемое - редкий дар.
Дело твое, Honey Badger, в конце концов пробивать дорогу лбом а не умом - не запретишь.

@Honey Badger · 18.11.2024, 14:48 **[ТС]**

Сообщение от kotelok

Тот же код, записанный через неизвестный метод расширения, вынуждает идти изучать документацию/сигнатуру этого метода.

Достаточно ввести название метода в произвольном месте чтобы увидеть в интеллисенсе, что это универсальный метод расширения, подходящий к любому типу данных. Логика его проста до безобразия. Если вы знаете LINQ, то и этот метод не вызовет у вас никаких сложностей.

Сообщение от kotelok

И название 'Pipe' само по себе никаких подсказок не даёт о сути происходящего.

Это название не я придумал. Это отсылка к так называемому Pipe operator, который в некоторых языках добавлен именно в целях удобной комбинации методов (например, оператор |> из F#).

@kotelok · 18.11.2024, 14:58

Сообщение от Honey Badger

Достаточно ввести название метода в произвольном месте чтобы увидеть/quote]
Ну так в этом и суть.

Изначальный код - просто прочитал и сразу всё понятно.

Вариант через дополнительный метод-расширение 'Pipe' - чтобы понять, что он делает, надо предпринять дополнительные действия. Это неудобно.

P.S.: если когда-то такой метод появится в стандартных библиотеках .NET, т.к. он будет востребован и удобен, тогда другое дело. А так - усложнение кода.

@Honey Badger · 18.11.2024, 15:26 **[ТС]**

Сообщение от kotelok

Вариант через дополнительный метод-расширение 'Pipe' - чтобы понять, что он делает, надо предпринять дополнительные действия. Это неудобно.

Чтобы понять, что делает совершенно любой метод из библиотеки, нужно предпринять дополнительные действия. Но эти действия окупятся тем, что используя методы из библиотеки вы сможете писать код короче и выразительнее, не тратя время на самостоятельную разработку существующей логики.

Сообщение от kotelok

А так - усложнение кода.

Строго говоря я и задал вопрос именно потому, что меня интересует как же изначальный код "хоть как-то отформатировать переносами/отступами". Если вам есть что добавить к тому, что обсуждалось в начале, буду признателен. А то тут дискуссия немного в другую сторону уже ушла.

P.S. Только что наткнулся на следующую инфу: для c# можно скачать из NuGet библиотеку, которая добавляет методы расширения Pipe с нужными перегрузками. Автор работает над тем, чтобы функциональность добавили и в язык. Возможно, скоро появится...) https://dev.to/winstonpuckett/... sions-5d0j

@Wolfdp · 19.11.2024, 04:10

Ух... чуть накину на вентилятор. В идеале стоит расписывать вообще так

C#
1
2
3
4
var strData = File.ReadAllText(pathToFile);
var paths = ProjectFileHelper.ExtractFilePaths(strData); // под вопросом, если возращает IEnumerable, возможно не имеет смысла, и тупо расписываем очередность Linq
var arr = paths.Select(CodeFile.CreateFromFile).ToArray();
return new Project(arr);

Теперь почему ТАК:
- возможность адекватно продебажить(!) В момент когда этот код потребует отладки, все эти Pipe и прямая передача результата в метод вызовет боль. Меня колега долго переубеждал расписывать, и таки был прав (но я был вредный, и отказывался менять привычки).
- в логах, когда упадет на строке #123 с каким-нибудь "очевидным" NullReferenceException, а там будет ваша вермишель из цепочки методов.... Ну удачи угадать что стало причиной. Подход через отдельные строки сразу даст понимание где проблема.
- компилятор один фиг неявно определяет локальные переменные, когда мы тупо засовываем результат метода в другой метод. Т.е. с точки зрения перфоманса мы ничего не теряем. А вот запаковывание в Pipe это уже доп-расходы на вызов метода и всякие замыкания.
- такой подход в целом читаем (при условии что нейминг локальных переменных осознанный).
- если отладка или внедрение подразумевают различные временные правки точечных частей кода -- это гораздо проще делать, когда он "построчный". Грубо говоря если я захочу подсунуть вместо файла свои данные, мне достаточно после ReadAllText подсунуть strData = "mock data"; //TODO: REMOVE AFTER DEBUG!!!. Во-первых это элементарно добавляеться-убирается. Во-вторых это прям сразу броситься в глаза при комите, если забуду убрать.

Не по теме:

Сообщение от Andrey-MSK

Длинное объявление конструктора

Ещё б студию наконец научили сворачивать такое. Бесит что при рассмотрении списка методов, часть в одну строку, часть -- на пол экрана.

@Honey Badger · 19.11.2024, 06:16 **[ТС]**

Сообщение от Wolfdp

Ух... чуть накину на вентилятор

Вентилятор еще спит, скорее всего))

Сообщение от Wolfdp

возможность адекватно продебажить(!) В момент когда этот код потребует отладки, все эти Pipe и прямая передача результата в метод вызовет боль.

Не могу согласиться, по крайней мере пока не увижу реальный пример.
Во-первых, вызов каждого метода (не важно из LINQ или собственных методов) пишется на отдельной строке именно потому, что каждый из них можно отдельно закомментировать или оставить комментарий к нему, не нарушив работоспособность цепочки.
Во-вторых, результаты, возвращенные каждым из этих методов, показаны в отладчике. Если вы отдаете себе отчет в том, что каждый из методов должен вернуть в случае использования темповых переменных, то и это у вас проблем вызвать не должно.

Сообщение от Wolfdp

в логах, когда упадет на строке #123 с каким-нибудь "очевидным" NullReferenceException, а там будет ваша вермишель из цепочки методов

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

Сообщение от Wolfdp

А вот запаковывание в Pipe это уже доп-расходы на вызов метода и всякие замыкания.

Расходов почти нет, т.к. во-первых, мы обрабатываем единственное конкретное значение - например, в моем примере это путь к файлу на диске, который сначала открывается, затем парсится, затем построчно передается конструктору класса Project. Каждый следующий метод работает с результатами предыдущего, т.е. это чистые функции не использующие замыканий, и потому они компилируются в статические методы. Во-вторых, такие функции как Pipe во многих случаях оптимизируются компилятором до прямых вызовов, а даже если это не удается, то они почти не добавляют накладных расходов, т.к. это всего лишь ссылки. Пара лишних миллисекунд ничего не меняет.

Сообщение от Wolfdp

различные временные правки точечных частей кода -- это гораздо проще делать, когда он "построчный"

Сообщение от Wolfdp

это прям сразу броситься в глаза при комите, если забуду убрать

Про комменты уже сказал, а на счет удобства - каждому свое. Мне намного комфортнее с последовательными вызовами. Это намного легче и пишется, и читается. Кроме того никто не мешает разрабатывать и отлаживать функцию с использованием темповых переменных, если нужно, а затем за три секунды переписать в виде цепочки.

Сообщение от Wolfdp

Ещё б студию наконец научили сворачивать такое

Да она вроде умеет. Ctrl+M, Ctrl+O (свернуть всё).

@Wolfdp · 19.11.2024, 12:39

Святая простота... Ничего, поработав в команде с чужим кодом придет понимание. Сейчас не вижу смысла пытаться переубеждать.

@Wolfdp · 19.11.2024, 14:31

Сообщение от Wolfdp

- в логах, когда упадет на строке #123 с каким-нибудь "очевидным" NullReferenceException, а там будет ваша вермишель из цепочки методов.... Ну удачи угадать что стало причиной. Подход через отдельные строки сразу даст понимание где проблема.

Вот себя любимого таки поправлю. Берем такой пример

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
using System;
 
var parameters = new object();
var service1 = new Service();
var service2 = new Service();
if (Random.Shared.Next() % 2 == 0)
    service1.Off = true;
else
    service2.Off = true;
 
 
try
{
    parameters
        .Pipe(service1.Do)
        .Pipe(service2.Do);
}
catch(Exception ex)
{ 
    Console.WriteLine(ex);
}
 
public static class PipeExtension
{
    public static TOut Pipe<TIn, TOut>(this TIn input, Func<TIn, TOut> fn)
    {
        return fn(input);
    }
}
 
class Service
{
    public bool Off { get; set; } = false;
    public object Do(object value) => Off 
        ? throw new Exception()
        : this;
}

Вывод на консоль

Code
1
2
3
4
System.Exception: Exception of type 'System.Exception' was thrown.
   at Service.Do(Object value) in D:\Temp\code\Draft\Draft\Program.cs:line 34
   at PipeExtension.Pipe[TIn,TOut](TIn input, Func`2 fn) in D:\Temp\code\Draft\Draft\Program.cs:line 27
   at Program.<Main>$(String[] args) in D:\Temp\code\Draft\Draft\Program.cs:line 14

Как видим нифига не понятно какой сервис оказался выключенным. Чуть ~~магии~~ меняем

C#
1
2
3
    parameters
        .Pipe(x => service1.Do(x))
        .Pipe(x => service2.Do(x));

Code
1
2
3
4
5
System.Exception: Exception of type 'System.Exception' was thrown.
   at Service.Do(Object value) in D:\Temp\code\Draft\Draft\Program.cs:line 34
   at Program.<>c__DisplayClass0_0.<<Main>$>b__1(Object x) in D:\Temp\code\Draft\Draft\Program.cs:line 16
   at PipeExtension.Pipe[TIn,TOut](TIn input, Func`2 fn) in D:\Temp\code\Draft\Draft\Program.cs:line 27
   at Program.<Main>$(String[] args) in D:\Temp\code\Draft\Draft\Program.cs:line 14

Т.к. у нас появился дополнительный код создания делегата, теперь у нас +1 строка в стектрейсе (что доказывает мысль насчет перфоманса, ну да ладно). Предвосхищая определенные тезисы, замечу что VisualStudio по умолчанию подсвечивает код так

Как корректно переносить длинные команды на разные строки, по аналогии с method chaining?

P.S. В целом можно писать как душе угодно, в случае когда за кодом работаете только вы. Хоть в одну строчку. Даже самые упорные личности как правило достигают просвещения и начинают применять иные подходы (особенно после 10+ часов отладки проекта, сразу познаешь бытие и накой эти Unit-тесты). В команде вас ждет два варианта:
- каждый пишет как пожелает, и вы все тихо ненавидите друг-друга.
- у вас есть тимлид, который гоняется с тапком за каждым, кто не следуют code style.

@Honey Badger · 19.11.2024, 14:55 **[ТС]**

Сообщение от Wolfdp

Берем такой пример

Интересно. Можно попросить полный код? Тут явно не всё. Хочу воспроизвести у себя.

@Wolfdp · 19.11.2024, 21:03

Сообщение от Honey Badger

Можно попросить полный код? Тут явно не всё

Полнее некуда. Создаете консольное приложение на .net core 8, пихаете всё в файл Program.cs и развлекаетесь.

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@IamRain 4693 / 2701 / 734 Регистрация: 02.08.2011 Сообщений: 7,218
	18.11.2024, 12:20
	Andrey-MSK, Не по теме: IBackgroundTaskQueue - а бывает еще ForegroundTaskQueue? 0

@Andrey-MSK 3308 / 2196 / 386 Регистрация: 14.08.2018 Сообщений: 7,387 Записей в блоге: 4
	18.11.2024, 12:30
	IamRain, Не по теме: Ну назвалося так... 0

@wizard41 3376 / 2678 / 573 Регистрация: 04.09.2018 Сообщений: 8,493 Записей в блоге: 3
	18.11.2024, 12:30
	Honey Badger, то что ты не понимаешь суть метода TOut, который привел - это пол беды. Но то что ты его связал с переносом строк - это 100% провал. Тебе сразу в первых же двух постах намекнули, что затронутый вопрос - это не то, о чем следует переживать. Зачем упорно продавливать этот вопрос на основании каких-то одному тебе известных правилах? Т.е. по сути у тебя вопросы бестолковые, каждый раз. Вот и получаешь "оплеухи". 0

@Wolfdp 3781 / 1755 / 371 Регистрация: 15.06.2012 Сообщений: 6,516 Записей в блоге: 3
	19.11.2024, 12:39
	Святая простота... Ничего, поработав в команде с чужим кодом придет понимание. Сейчас не вижу смысла пытаться переубеждать. 0