I>Соответственно вопрос только в количестве вызовов.
I>В числодробилках, рендеринге, разных системных тонкостях даже дополнительный инкремент может опаскудить вообще всё. Лямбда, которая содержит такой инкремент, добавит цимеса настолько, что мир покажется холодным и скучным, а Валгалла и Фольквангр отвернутся от тебя.

Соответсвенно, вопрос только в том, где такое критично, а где — нет. Числодробилки, рендеринги и прочая — это опять же сколько, 0.0001% задач? И то, там опять же критичны в первую очередь алгоритмы, а потом — выжимание скорости из железа.

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

Про рендеринг напомнило из смежной области: игростроения. Помнится, в ~2004 (емнип) народ на форумах не мог поверить, что не надо заниматься ручной оптимизацией большинства мест: компилятор проведет оптимизации качественнее.

Здравствуйте, __kot2, Вы писали:

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

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

Здравствуйте, IT, Вы писали:
IT>Я же говорю — недопере. Кто тебе сказал, что десяток мелких методов с невменяемой перекидкой контекста туда-сюда — это понятно и легко поддерживаемо? На самом деле всё что ты здесь пытаешься нам доказать — это то, что твои предпочтения лучше наших. С чего бы?
обычно я пытаюсь что-то доказать, если мне это нужно в работе. разумеется, мне вообще без разницы как там у вас принятно
а мысль, которую я высказал, не о том, что мне что-то удобнее делать, чем остальным, а о том, что существует старый старперский подход, и я тоже когда-то так писал и новый сильно более современный, который для старпера будет непонятен в силу отсутсвия у того навыков хорошего именования (зачем прыгать в ф-ию посмотреть что она делает, если и так по имени можно понять — одно дело у нас ф-ия sort_users, другое дело — sort_users_by_name_ascending). старпер не умеет разбивать задачи на независимые, не умеет разделять контекст, для понимания такого кода нужно держать постоянно в голове состояние всех одновременно используемых переменных и, конечно же, гораздо удобнее иметь их все на одном экране в одном методе. и да, такой код понятен, если в нем разобраться. другое дело, что во-первых, копаться в чужом коде это трата времени, а во-вторых, записанный таким образом код не поддается нормальному тестированию. а, значит, не может быть частью стабильной устойчивой системы. когда-то это было неважно. лет 20 назад. сейчас — важно.

Здравствуйте, __kot2, Вы писали:

__>а мысль, которую я высказал...

Опять лишь штампы, догмы и наклеивания ярлыков. Демагогия, короче.

Вот тебе метод на 300 строк. Иди и сделай его в 30 короче.

Здравствуйте, IT, Вы писали:
IT>Вот тебе метод на 300 строк. Иди и сделай его в 30 короче.
вот, такой подход мне нравится, всегда проще что-то обьяснить на конкретном коде
правда, мне непонятно что делает эта ф-ия. упрощает выражения? обьясните на пальцах, пожалста
я конечно могу дать общие рекомендации вынести конкретные случаи в отдельные блоки, чтобы не наступить на типичную ошибку с пролетанием в соседний блок и то, что везде по 100 раз скопипасчено

var exp = func(expr);
if (exp != expr)
return exp;


но я думаю, вы и сами в курсе этого

есть очень простой тест на качество архитектуры кода. когда вы добавляете новую сущность, сколько разных мест вам придется поправить? 1 — отлично. 2 — нормально. больше — плохо. то, что вам при добавлении нового вида expression нужно будет править transform, помимо, я так понимаю, еще десятка других мест явно намекает на непродуманность архитектуры

Здравствуйте, __kot2, Вы писали:

__>правда, мне непонятно что делает эта ф-ия. упрощает выражения? обьясните на пальцах, пожалста

Это типа визитора, только без создания сотен классов.

__>я конечно могу дать общие рекомендации вынести конкретные случаи в отдельные блоки, чтобы не наступить на типичную ошибку с пролетанием в соседний блок и то, что везде по 100 раз скопипасчено

Убрал. Но 10 строк всё равно не получилось. Как же так?

__>но я думаю, вы и сами в курсе этого

В курсе чего?

__>есть очень простой тест на качество архитектуры кода. когда вы добавляете новую сущность, сколько разных мест вам придется поправить? 1 — отлично. 2 — нормально. больше — плохо. то, что вам при добавлении нового вида expression нужно будет править transform, помимо, я так понимаю, еще десятка других мест явно намекает на непродуманность архитектуры

Последний коммит именно это и делает. Добавилась обработка ещё трёх десятков типов выражений. Поменялось только одно место, т.е. это хорошая архитектура. Не спорю.

Теперь всё же мне хочется получить ответ на предыдущий вопрос. Есть метод с хорошей архитектурой, который после устранения копипасты и добавления новых типов выражений составляет 250 строк. Как из него сделать хотя бы строк 10?

Здравствуйте, IT, Вы писали:
__>>правда, мне непонятно что делает эта ф-ия. упрощает выражения? обьясните на пальцах, пожалста
IT>Это типа визитора, только без создания сотен классов.

IT>Теперь всё же мне хочется получить ответ на предыдущий вопрос. Есть метод с хорошей архитектурой, который после устранения копипасты и добавления новых типов выражений составляет 250 строк. Как из него сделать хотя бы строк 10?
как я и говорю, мне непонятно, что конкретно он делает
если т.з. на этот метод звучит как "типа визитора, только без создания сотен классов" то я бы переписал его так:

public static void Visit(this Expression expr, Func<Expression,bool> func)
{
    DontCreateHundredClasses();
}

это полностью удовлетворяют заданию и, как видите, можно и в одну строчку уложить. в принципе, я даже не уверен что и она нужна

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

(добавил позже)
ааа, я, похоже начинаю догадываться. то есть мы хотим просто пройти по всем подвыражения одного выражения и вызывать лямбду? я прав?
ну это просто

public static void Visit(this Expression expr, Func<Expression,bool> func)
{
    for_each(subexpr : expr.sub_expressions())
        {
          Visit(subexpr, func);
      func(subexpr);
        }
}

ну и имя тогда конечно попнятнее стоит дать, а то никогда не догадаешься, что Visit лезет в подвыражения, пока в метод не посмотришь. соотв-но, четче будет что-то в духе for_every_subexpression_do()

Здравствуйте, __kot2, Вы писали:

__>если т.з. на этот метод звучит как "типа визитора, только без создания сотен классов" то я бы переписал его так:

Всё понятно. Как и ожидалось, дойдя до конкретики словоблудие просто приняло другую форму. Было — "я всё знаю", стало — "а покажите тесты".

__>ааа, я, похоже начинаю догадываться. то есть мы хотим просто пройти по всем подвыражения одного выражения и вызывать лямбду? я прав?
__>ну это просто

Это просто, но это не работает. Даже не компилируется. Когда просто, но не работает меня такое не устраивает.

Здравствуйте, IT, Вы писали:
IT>Здравствуйте, __kot2, Вы писали:
__>>если т.з. на этот метод звучит как "типа визитора, только без создания сотен классов" то я бы переписал его так:

IT>Всё понятно. Как и ожидалось, дойдя до конкретики словоблудие просто приняло другую форму. Было — "я всё знаю", стало — "а покажите тесты".
я еще в самом начале этой темы писал, что такой код невозможно тестировать, поэтому, разумеется, запрос написать тесты выглядит издевательством. на это и расчет — заставить людей использовать собственный же код. правда, тесты это все-таки не издевательство, а спецификация, записанная в наиформальнейшем виде. и без нее современный софт софтом, к сожалению, не считается. обьем спецификации говнокода почти всегда превышает обьем самого кода и единственное, что о нем может сказать аффтар при внесении изменений, что "все просто должно работать, как работало раньше, кроме там, того что мы тогда обсуждали".

IT>Это просто, но это не работает. Даже не компилируется. Когда просто, но не работает меня такое не устраивает.
я несколько лет на C# не писал, синтаксис не помню, хотя не думаю что в этой теме найдется хоть кто-то кто не поймет что я имел в виду. кроме вас, разумеется

Здравствуйте, __kot2, Вы писали:

IT>>Всё понятно. Как и ожидалось, дойдя до конкретики словоблудие просто приняло другую форму. Было — "я всё знаю", стало — "а покажите тесты".
__>я еще в самом начале этой темы писал, что такой код невозможно тестировать, поэтому, разумеется, запрос написать тесты выглядит издевательством.

Размер функции и тестирование это примерно как в огороде бузина, а в Киеве дядька. Не думаю, что если метод в два раза короче, то для него и тесты в два раза лучше.

IT>>Это просто, но это не работает. Даже не компилируется. Когда просто, но не работает меня такое не устраивает.
__>я несколько лет на C# не писал, синтаксис не помню, хотя не думаю что в этой теме найдется хоть кто-то кто не поймет что я имел в виду. кроме вас, разумеется

При чём тут C#? Expression — это стандартный класс фреймворка, для которого нет возможности получить список всех входящих в него Expressions. Т.е. как минимум придётся написать такой метод, к которому возникнут те же самый вопросы. Ибо один только switch превысит предложенный тобой максимум в 30 строк. Но даже если такой метод и был, то он бы нас не устроил, т.к. всегда кроме соображений компактности кода есть ещё и такая злая штука как нефункциональные требования. В данном случае они требуют, чтобы мы не пересоздавали ветку, если она не изменилась.

Здравствуйте, К Тёте, Вы писали:

I>>Соответственно вопрос только в количестве вызовов.
I>>В числодробилках, рендеринге, разных системных тонкостях даже дополнительный инкремент может опаскудить вообще всё. Лямбда, которая содержит такой инкремент, добавит цимеса настолько, что мир покажется холодным и скучным, а Валгалла и Фольквангр отвернутся от тебя.

КТ>Соответсвенно, вопрос только в том, где такое критично, а где — нет. Числодробилки, рендеринги и прочая — это опять же сколько, 0.0001% задач? И то, там опять же критичны в первую очередь алгоритмы, а потом — выжимание скорости из железа.

Пудозреваю, в твоих проектах это не надо делать.

Например, когда вызов функции у тебя асинхронный, это само по себе дает счет на милисекунды. Что характерно, компилятор тут вообще не помощник. Если руками заинлайнить, то профит вообще сказочный. И это ничего особенного — фронтенд, бакенд или мобайл или десктоп.

Перформанс это не "надо-не надо" а "какие возможности даёт". Алгоритмы — это и ежу понятно. Константы во всяких O(log(N)) никто не отменял, O(K*N^2) может работать быстрее, нежели O(M*log(N)). Или так — сортировка пузырьком, когда данные отсортированы, работает быстрее квиксорта и мержсорта.

То есть, вне зависимости от хорошести алгоритма, потери на вызовах могут быть и 1000% и больше.

Здравствуйте, IT, Вы писали:
IT>Здравствуйте, __kot2, Вы писали:
IT>>>Всё понятно. Как и ожидалось, дойдя до конкретики словоблудие просто приняло другую форму. Было — "я всё знаю", стало — "а покажите тесты".
__>>я еще в самом начале этой темы писал, что такой код невозможно тестировать, поэтому, разумеется, запрос написать тесты выглядит издевательством.
IT>Размер функции и тестирование это примерно как в огороде бузина, а в Киеве дядька. Не думаю, что если метод в два раза короче, то для него и тесты в два раза лучше.
а каким вы образом будете тестировать гигантский switch где сгруппировано всю кучками? будете писать отдельный тест для каждого значения case? для одного из класса? или все-таки для каждого класса таких значений?
тесты говнокода всегда пытаются описать что говнокод делает, когда тест нормального кода описывает что код должен делать

IT>>>Это просто, но это не работает. Даже не компилируется. Когда просто, но не работает меня такое не устраивает.
__>>я несколько лет на C# не писал, синтаксис не помню, хотя не думаю что в этой теме найдется хоть кто-то кто не поймет что я имел в виду. кроме вас, разумеется
IT>При чём тут C#? Expression — это стандартный класс фреймворка, для которого нет возможности получить список всех входящих в него Expressions. Т.е. как минимум придётся написать такой метод, к которому возникнут те же самый вопросы. Ибо один только switch превысит предложенный тобой максимум в 30 строк. Но даже если такой метод и был, то он бы нас не устроил, т.к. всегда кроме соображений компактности кода есть ещё и такая злая штука как нефункциональные требования. В данном случае они требуют, чтобы мы не пересоздавали ветку, если она не изменилась.
я ничего про ветку не понял. вот, допустим, я что-то добавил-поменял в выражениях. как мне удостовериться, что ничего старого не поломалось, а новое работает?

Здравствуйте, __kot2, Вы писали:

__>а каким вы образом будете тестировать гигантский switch где сгруппировано всю кучками? будете писать отдельный тест для каждого значения case? для одного из класса? или все-таки для каждого класса таких значений?

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

__>тесты говнокода всегда пытаются описать что говнокод делает, когда тест нормального кода описывает что код должен делать

Глубокая мысль. Если её упростить, то получится так: дважды два равно четыре, когда трижды три равно девять.

__>я ничего про ветку не понял. вот, допустим, я что-то добавил-поменял в выражениях. как мне удостовериться, что ничего старого не поломалось, а новое работает?

Ты опять про тесты? Давай может вернёмся к тому как ты сейчас лихо из 250 строк предложенного кода сделаешь 10?

Здравствуйте, IT, Вы писали:
IT>Здравствуйте, __kot2, Вы писали:
__>>а каким вы образом будете тестировать гигантский switch где сгруппировано всю кучками? будете писать отдельный тест для каждого значения case? для одного из класса? или все-таки для каждого класса таких значений?
IT>а каким вы образом будете тестировать гигантский цикл? будуте писать отдельный тест для каждой итерации?
тут, разумеется, понадобится два теста. на то, что метод вызывается нужное число и раз и корректность работы метода непосредственно

__>>тесты говнокода всегда пытаются описать что говнокод делает, когда тест нормального кода описывает что код должен делать
IT>Глубокая мысль. Если её упростить, то получится так: дважды два равно четыре, когда трижды три равно девять.
нет. просто когда понимаешь, что потом это еще и тестировать надо, то стараешься писать совсем по другому

__>>я ничего про ветку не понял. вот, допустим, я что-то добавил-поменял в выражениях. как мне удостовериться, что ничего старого не поломалось, а новое работает?
IT>Ты опять про тесты? Давай может вернёмся к тому как ты сейчас лихо из 250 строк предложенного кода сделаешь 10?
я уже привел свое решение

public static void for_every_subexpression_do(this Expression expr, Func<Expression,bool> func)
{
    for_each(subexpr : expr.sub_expressions())
        {
          Visit(subexpr, func);
          func(subexpr);
        }
}

наверное, правильнее будет вставить
Visit(expr, func);

на самый верх, но это зависит так же от того, что мы понимаем под подвыражением

6 строчек кода. 7 если разделитесь для красоты добавить

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

Здравствуйте, __kot2, Вы писали:

__>я уже привел свое решение

Я уже отвечал, что это псевдорешение не работает.

Здравствуйте, dosik, Вы писали:

D>А что тогда с высоконагруженными приложениями, где кроме как на себя, даже на компилятор положиться нельзя?

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

Здравствуйте, __kot2, Вы писали:

__>не думаю, что вы найдете хоть одну рекоменацию от авторитетного человека, который скажет обратное.
__>от опытного — да, конечно. я много людей знаю опытных, которые застряли где-то в начале 2000ых

Скажи, а тут, на rsdn, есть для тебя кто то авторитетный, или все застряли в начале 2000-х?

Здравствуйте, __kot2, Вы писали:

__>так и прогрммист со своими функциями-спагетями это нечто среднее между маленькой девочкой с мешком картошки и фашистом с гранатой, в зависимости от его должности и степени влияния на проект. он все равно не сможет контролировать сложность проекта сам или же вообще самоустранится и предложит другим разбираться с проблемами.

А можно посмотреть на твой собственный код?

Здравствуйте, IT, Вы писали:
IT>Здравствуйте, __kot2, Вы писали:
__>>я уже привел свое решение
IT>Я уже отвечал, что это псевдорешение не работает.
ну не работает, так не работает. в конце концов я так до конца и не уверен, насчет того, что же делает эта ф-ия

Здравствуйте, AndrewVK, Вы писали:
__>>не думаю, что вы найдете хоть одну рекоменацию от авторитетного человека, который скажет обратное.
__>>от опытного — да, конечно. я много людей знаю опытных, которые застряли где-то в начале 2000ых
AVK>Скажи, а тут, на rsdn, есть для тебя кто то авторитетный, или все застряли в начале 2000-х?
тут много грамотного народа. я был лучшего мнения о отметившихся тут, они сами признались, что спагетти это нормально