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

L>get, меняющий состояние — нафик, нафик.

Интересно, почему get (по сути запрос), меняющий состояние — нафик, а предикат (тоже по сути запрос), меняющий состояние — не нафик?

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

ОК. За пример спасибо. А теперь давай представим, что сделают криворукие программисты, если начнут использовать замыкания "по-полной":

if (!DoSomething(delegate {
    Result r = ObtainResult(arg);
    MethodInvoker inv = delegate {
        if (r != Result.Error && r != Result.Warning || 
            r != Result.Unknown)
        {
            SubscribeSource(delegate(Source source, Argument arg2) {
                source.Add(arg, delegate(Result r2) { return r == r2; });
                ProcessArgument(arg2);
            });
        }
        else
            return Analyze(delegate { ProcessResult(r); });                    
    };

    if (inv()) {
        DoSomething2(delegate { 
            if (!LogResult(r))
                throw new Exception("Unable to log!");
            else
            {
                DoSomething3(delegate {
                    ProcessArgument(arg);
                });
            }
        }
    }
})))

Замыкания — зло?

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

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

А в итоге вся разница сводится к тому, что в одном случае читаем слева направо, в другом — сверху вниз.

Давайте все-таки не будем касаться вопросов читабельности. Ибо все-таки уж очень субьективный фактор это.

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

L>get, меняющий состояние — нафик, нафик.

Угу, double check lock паттер — ф топку!

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

Лично я знаю ровно одно полезное применение этой фичи: копирование потоков или что то аналогичное:

int bytesRead;
while ((bytesRead = stream.Read(...)) > 0)
  ...

И если этой фичи не будет, я, если честно, совсем не огорчусь.

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

V>С того, что предикат, это и есть запрос, у которого результат имеет логический тип.
ВВ>>И каким образом вышеприведенный код нарушает правило "leave the state of the system unchanged"? Что вообще изменяет это код?
V>Значение переменной х

Теперь будем заниматься подменой понятий, только чтобы что-то там такое доказать?
Запрос, результат которого "имеет логический тип" не изменяет значение переменной х. Значение переменной х изменяет (а вернее инициализует ее) функция MyFunс, которая для того была и создана и которая имеет совсем не логический тип.

ВВ>>Он проводит инициализацию переменной x результатом выполнения функции MyFunc, самый смысл выполнения которой в том, чтобы вернуть результат.
V>Взгляни на код:
ВВ>>

ВВ>>int x = 10;
ВВ>>if (...куча условий...x=MyFunc()...куча условий...)
ВВ>>{
V>    Console.WriteLine(x);
ВВ>>}
ВВ>>

V>Что будет выведено на экран?

В общем, я понял. Конкретики никакой нет. Как обычно разговор идет по принципу "эта фича плохая, потому что я могу на ней написать плохой код". На любой "фиче" можно написать такой код, что кошмары будут сниться. А if-ы вам не страшно использовать? С 20-к вложенных if-ов, и мозги слетят набекрень, когда будете пытаться определять, где какая переменная объявлена, и какая у нее область видимости.

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

AVK>И если этой фичи не будет, я, если честно, совсем не огорчусь.

Но какое в ней "скрытое зло" все-таки? Объективно ведь никто не заставлял в C# делать так, что оператор "=" возвращает результат операции. В васике вот не такого.

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

Это если пример тривиальный. Вот мой любимый пример из одной библиотеки. Неплохой, кстати, библиотеки.

  channel = outgoingCommand -> command.header.channelID < peer -> channelCount ? & peer -> channels [outgoingCommand -> command.header.channelID] : NULL;
       reliableWindow = outgoingCommand -> reliableSequenceNumber / ENET_PEER_RELIABLE_WINDOW_SIZE;
       if (channel != NULL && 
           outgoingCommand -> sendAttempts < 1 && 
           ! (outgoingCommand -> reliableSequenceNumber % ENET_PEER_RELIABLE_WINDOW_SIZE) &&
           (channel -> reliableWindows [(reliableWindow + ENET_PEER_RELIABLE_WINDOWS - 1) % ENET_PEER_RELIABLE_WINDOWS] >= ENET_PEER_RELIABLE_WINDOW_SIZE ||
             channel -> usedReliableWindows & ((((1 << ENET_PEER_FREE_RELIABLE_WINDOWS) - 1) << reliableWindow) | 
               (((1 << ENET_PEER_FREE_RELIABLE_WINDOWS) - 1) >> (ENET_PEER_RELIABLE_WINDOW_SIZE - reliableWindow)))))
         break;
  
       commandSize = commandSizes [outgoingCommand -> command.header.command & ENET_PROTOCOL_COMMAND_MASK];
       if (command >= & host -> commands [sizeof (host -> commands) / sizeof (ENetProtocol)] ||
           buffer + 1 >= & host -> buffers [sizeof (host -> buffers) / sizeof (ENetBuffer)] ||
           peer -> mtu - host -> packetSize < commandSize)
       {
          host -> continueSending = 1;
          
          break;
       }

Все еще не страшно? ^_^

Давайте все-таки не будем касаться вопросов читабельности. Ибо все-таки уж очень субьективный фактор это.

Так это основополагающий фактор . Мы быстро забываем код. Над кодом работает больше одного человека. Программист с идеальной памятью соло может писать код в ЛЮБОМ стиле. Оно будет работать и расширяться. Разве что совсем глобальная архитектурная лажа случится.

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

Поэтому вполне естественно что запрещается делать свой язык встроенными средствами ( переопределения всякие, макросы и прочие шаблоны ), наворачивать длинные if'ы, вызывать функции внутри условий и прочее. Дабы код был простой как топор и так же легко модифицировался. Если простота кода не нужна — можно делать как больше нравится.

Это всего лишь один из костылей которым лично я вынужден пользоваться, потому что проекты большие а народу много. Еще раз повторю, что вызов функции внутри if() плох не сам по себе, а потому что ПОТЕНЦИАЛЬНО может привести к ТРУДНОЧИТАЕМОМУ коду в БОЛЬШИХ проектах. А это в свою очередь приводит к багам, срывам сроков и прочим непритностям.

Это единственная серьезная причина, которую я знаю. Опечатка с '=' и '==' уже года три как не актуальна .

P.S. Все вышесказанное естественно мое ИМХО. Основываюсь на своем небольшом ( порядка 12 лет ) опыте коммерческого программирования. Согласен с тем что зло небольшое. Но лично видел как совокупность небольших зол рождает таких чудовищь, что проще уволиться чем с ними махаться ^_^.

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

ВВ>Но какое в ней "скрытое зло" все-таки?

Плохо читается.

ВВ> Объективно ведь никто не заставлял в C# делать так

ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы. В свое время культовые фичи были, чуть ли не главное преимущество С перед Паскалем в тогдашних флеймах. Написать какую нибудь заковыристую конструкцию (ну, типа хрестоматийного уже примера копирования строк), которая хрен-пойми-как-работает считалось мегакруто. Интересно, что получится в результате работы i+++++i в плюсовом форуме до сих пор обсуждают?

Интересно, что получится в результате работы i+++++i в плюсовом форуме до сих пор обсуждают?

Да, конечно. Отче вопрос на собеседовании. Если человек знает какой парсер в С++ и про sequence points — он мегакрут . Наверное.

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

ВВ>> Объективно ведь никто не заставлял в C# делать так
AVK>ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы.

Кстати, тоже интересная тема
В принципе-то если тебе надо сделать сначала инкремент, потом передать значение в функицию, то чем плохо:

MyFunc(++i)

Тоже плохо читается? Но ведь все вроде наглядно

Кстати, ведь тернарный оператор тоже в общем-то читабельность не улучшает. И даже нововведенный ??

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

EOH>Все еще не страшно? ^_^

Ну если честно — нет Особенно если пробелы лишние убрать Кстати, это на каком языке? Что означает "& peer -> channels"?
Ну какая разница в какую сторону читать сверху-вниз или слева-направо?

А вообще по этому поводу рекомендую посмотреть мой пример с замыканиями

EOH>

Давайте все-таки не будем касаться вопросов читабельности. Ибо все-таки уж очень субьективный фактор это.

EOH>Так это основополагающий фактор . Мы быстро забываем код. Над кодом работает больше одного человека. Программист с идеальной памятью соло может писать код в ЛЮБОМ стиле. Оно будет работать и расширяться. Разве что совсем глобальная архитектурная лажа случится.

EOH>Простые смертные, к которым я отношу себя и большинство программистов, вернувшись через полгода к своему коду или смотря код коллег основное время как раз тратят на то чтобы "разобраться как это работает". Чтобы добавить новую функциональность или починить старую, ничего не сломав.

Да нет, это все понятно. Есть кодинг гайдлайн, и все по нему пишут. Наш гайдлайн когда обсуждали года три назад — когда контора-соконтрактор на C# переходила — так мы там даже как переменные объявлять и инициализировать прописали
Но тут вроде как "философия"

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

Мне вот было интересно — может, какие другие грабли есть? На которые я по счастливой случайности не наступал. Или наступал, но не замечал А судя по всему нет.

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

ВВ>Тоже плохо читается?

Да.

ВВ> Но ведь все вроде наглядно

Нет.

ВВ>Кстати, ведь тернарный оператор тоже в общем-то читабельность не улучшает.

В некоторых случаях — улучшает

ВВ> И даже нововведенный ??

Этот тоже улучшает.

Ну если честно — нет Особенно если пробелы лишние убрать Кстати, это на каком языке? Что означает "& peer -> channels"?

Plain C . Но это не суть есть важно, я просто для примера страха и ужаса привел. Вызовов функций внутри if там тоже нет, он от этого страшнее не становится. '&' там для получения указателей. Черная магия и все такое .

Ну какая разница в какую сторону читать сверху-вниз или слева-направо?

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

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

Завидую черной завистью. Я по граблям — как по минному полю. Как писал три года назад, шесть лет, девять, двенадцать — совершенно разные стили . Зато сейчас программы в принципе с первого раза работают. Скомпилировалась, запустилась, ассерты не сказала, юниты проползла — значит работает .

Мне вот было интересно — может, какие другие грабли есть? На которые я по счастливой случайности не наступал. Или наступал, но не замечал А судя по всему нет.

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

MyFunc(++i)
Тоже плохо читается? Но ведь все вроде наглядно

Когда строчка одна — наглядно. Когда через полгодика MyFunc немного приросла аргументами и немного сдвинулась в коде, а потом еще через пару лет внимательно смотришь на пару сотен... тысячь... экранов кода дабы "подправить одну маленькую неувязку в функциональности... да сколько ж тут всего наплодилось... а оно тут еще и врем жизни объекта сечет... а где тут корень иерархии... да нифига себе абстрактных слоев навернули... ой, сериализация... и маршалинг... а, оно еще и по сети... какой идиот... а, да это же я во время аврала... неаккуратненько... ну да ладно, фиг с ним... о, мультипоточность... и тут... ух ты, синглтон... да какой автоматический... а, вот и корень... тройной... а, оно еще и объектом может... и в форме... и с джавой... а с бейсиком зачем?!?... а, ну да, пять лмов заплатили... зря согласились... о чем это я... ах да, кнопочка... сигслоты... сообщения... обработка... объекты... инкапсуляция... и тут... а тут цепочка... а куда ведет... у-у-у-у-ух ты куда она ведет... а это нафига?... зря Васю уволил, надо было убить сначало... ладно, юниты проходит значит работает... а вот и точка входа... еб[.......]ть... два раза... а кто аргументы проверять будет?... это что Я писал?!? ну нифига себе три ночи без сна... так... тут мы меняем... тут не меняем... о, нашел, вот тут и будем менять", то один незамеченный ++ может стоить потом недели отладки. Что есть очень печально. Да и пить тоже печально. Да и вообще лучше не стоит, там под эти грабли уже средних размеров озеро крови натекло .

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

EOH>Plain C . Но это не суть есть важно, я просто для примера страха и ужаса привел. Вызовов функций внутри if там тоже нет, он от этого страшнее не становится. '&' там для получения указателей. Черная магия и все такое .

Просто я не понимаю, что это значит:
& peer -> channels

Берем адрес у peer, а дальше что? Это же не lvalue. По-моему, так нельзя
Впрочем, фиг его теперь знает

EOH>

Ну какая разница в какую сторону читать сверху-вниз или слева-направо?

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

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

EOH>Завидую черной завистью. Я по граблям — как по минному полю. Как писал три года назад, шесть лет, девять, двенадцать — совершенно разные стили . Зато сейчас программы в принципе с первого раза работают. Скомпилировалась, запустилась, ассерты не сказала, юниты проползла — значит работает .

Но чему тут завидовать. Самосовершенствование это хорошо. Это как раз завидую

Просто я не понимаю, что это значит:
& peer -> channels
Берем адрес у peer, а дальше что? Это же не lvalue. По-моему, так нельзя

Говорю же, черная магия . Приоритет операторов. Сперва выполняется peer->channels[ channelID ] что дает нам структуру в массиве / по указателю, а затем над полученным противоестественно выполняется '&', что дает адрес этой структуры. То же самое что peer->channels + channelID. Используется для совместимости с леворезьбовыми компиляторами. Оно же все, [.....], портабельно по самое пикачу и для последнего калькулятора .

ВВ>Что-нибудь еще?

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

Так удобней отлаживать.

Я предложу другой пример:

if (x > 2 && (x = random())!=3) { ... }

Выполнилось ли присваивание в x при пошаговом выполнении, так сразу и не поймешь. И на какой ветви мы отвалились, тоже непонятно.

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

L>get, меняющий состояние — нафик, нафик.

Это типичный lazy паттерн. Оптимизация. Обычно никаких проблем не вызывает.

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

ВВ>Собственно, сабж.

Плохо тем, что выполнение условия имеет неявный эффект — инициализацию или изменение состояния переменной. Принципиально такой код ничем не отличается от функции GetSomething, которая при своем выполнении изменяет состояние объекта. Надеюсь чем плохи такие функции объяснять не надо. То что код с неявными эффектами заинлайнен и вроде бы нагляден ситуацию не шибко улучшает, при изменении реального кода такое пропустить очень легко.

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