Re[5]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 23:27
Оценка: :))) :))) :)))

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


Когда строчка одна — наглядно. Когда через полгодика MyFunc немного приросла аргументами и немного сдвинулась в коде, а потом еще через пару лет внимательно смотришь на пару сотен... тысячь... экранов кода дабы "подправить одну маленькую неувязку в функциональности... да сколько ж тут всего наплодилось... а оно тут еще и врем жизни объекта сечет... а где тут корень иерархии... да нифига себе абстрактных слоев навернули... ой, сериализация... и маршалинг... а, оно еще и по сети... какой идиот... а, да это же я во время аврала... неаккуратненько... ну да ладно, фиг с ним... о, мультипоточность... и тут... ух ты, синглтон... да какой автоматический... а, вот и корень... тройной... а, оно еще и объектом может... и в форме... и с джавой... а с бейсиком зачем?!?... а, ну да, пять лмов заплатили... зря согласились... о чем это я... ах да, кнопочка... сигслоты... сообщения... обработка... объекты... инкапсуляция... и тут... а тут цепочка... а куда ведет... у-у-у-у-ух ты куда она ведет... а это нафига?... зря Васю уволил, надо было убить сначало... ладно, юниты проходит значит работает... а вот и точка входа... еб[.......]ть... два раза... а кто аргументы проверять будет?... это что Я писал?!? ну нифига себе три ночи без сна... так... тут мы меняем... тут не меняем... о, нашел, вот тут и будем менять", то один незамеченный ++ может стоить потом недели отладки. Что есть очень печально. Да и пить тоже печально. Да и вообще лучше не стоит, там под эти грабли уже средних размеров озеро крови натекло .
Re: [C#] Чем плох инлайн ассайнмент?
От: COFF  
Дата: 10.11.08 13:51
Оценка: +5 -1 :)))
Здравствуйте, Воронков Василий, Вы писали:

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


Кстати, немного не в тему, но использование слова ассайнмент вместо давно сложившегося термина присваивание, честно говоря, режет глаз. Я конечно понимаю, что Вы наверняка читаете э лот оф инглиш литрча, бат все-таки может стоит выражаться или по русски, или по английски, а не на смеси того и другого? :)
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 22:37
Оценка: +6

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


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

  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 лет ) опыте коммерческого программирования. Согласен с тем что зло небольшое. Но лично видел как совокупность небольших зол рождает таких чудовищь, что проще уволиться чем с ними махаться ^_^.
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 09.11.08 07:23
Оценка: +4
Здравствуйте, Lloyd, Вы писали:

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


Это типичный lazy паттерн. Оптимизация. Обычно никаких проблем не вызывает.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.08 04:29
Оценка: +4
Здравствуйте, Воронков Василий, Вы писали:

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

AVK>>ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы.

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

ВВ>MyFunc(++i)
ВВ>Тоже плохо читается? Но ведь все вроде наглядно
ВВ>Кстати, ведь тернарный оператор тоже в общем-то читабельность не улучшает. И даже нововведенный ??

Я те так скажу. В Nemerle операции ++/-- (и инфиксная и префиксная) и = имеют тип void и стало быть не могут использоваться в выражении. По началу я авторам тоже задал вопрос типа твоего. Получил ответ такой. Мы в дизайне языка стремились избавиться даже от малейших возможностей сделать случайную ошибку программистом.

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

По факту использую изменяемые переменные только там где это действительно может дать огромный выигрыш.

Так что на ваши споры я смотрю с усмешкой. Ты ратуешь за фичу думая, что она обеспечит тебе краткость, в то время как она как раз обеспечивает длинный говнокод который тяжело отлаживать. Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.

Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль". Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: ili Россия  
Дата: 08.11.08 20:43
Оценка: 6 (1) +2
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну типа:


ВВ>
ВВ>int x;

ВВ>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>{

ВВ>}
ВВ>


вот полчаса думал что это тут написано... тем и плох.
код пишется не для компилятора, а для того кто его сопровождать будет.
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 23:15
Оценка: +3
Здравствуйте, Воронков Василий, Вы писали:

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


Да.

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


Нет.

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


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

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


Этот тоже улучшает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 11.11.08 05:51
Оценка: 9 (1) +1
Здравствуйте, IT, Вы писали:

IT>То, что это плохо в C++ как раз понятно. ВВ хочет понять чем это плохо в C#. Кроме сомнительного аргумента про читабельность пока ничего не прозвучало.


А в реальных проектах есть что-то более важное чем читабельность?
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: mkizub Литва http://symade.tigris.org
Дата: 08.11.08 13:23
Оценка: 1 (1) +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>
if ((x = MyFunc()) > 4 && x % 2 == 0)


Тем, что чаще является опечаткой, чем действительно намеренным кодом программиста.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 16:40
Оценка: +2
Здравствуйте, mkizub, Вы писали:

ВВ>>
M>if ((x = MyFunc()) > 4 && x % 2 == 0)
M>


M>Тем, что чаще является опечаткой, чем действительно намеренным кодом программиста.


Эээ... А каким образом можно так опечататься? В смысле вместо == поставить =? Ну так у тебя это не скомпилируется. Тебе придется все выражение еще в скобочки дополнительные взять — опять-таки и после этого оно не скомпилируется. Надо будет сравнить с чем-нибудь.

В общем что-то мне кажется, что сложновато так опечататься.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 08.11.08 19:06
Оценка: +2
Здравствуйте, prVovik, Вы писали:

V>Зачем всё лепить в кучу: вычисление предиката и действия?


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

if ({ def x = MyFunc(); x + 1 } > 4)
{
}

Зачем вводить новые локальные переменные выше, если их scope ограничен только условием?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 08.11.08 20:37
Оценка: +2
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А почему в С++ это актуально, а С#, как говорят некоторые, это плохо?


Некоторые в C# до сих пор пишут

if (0 == a)
{
}

полагая, что это помогает это им реально решать ту же саму проблему.

На самом деле это всё тот же копи--пейст, только не кода, а идей. Копирование первично, понимание сути вторично.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re: [C#] Чем плох инлайн ассайнмент?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 22:19
Оценка: +2
Здравствуйте, Воронков Василий, Вы писали:

Лично я знаю ровно одно полезное применение этой фичи: копирование потоков или что то аналогичное:
int bytesRead;
while ((bytesRead = stream.Read(...)) > 0)
  ...

И если этой фичи не будет, я, если честно, совсем не огорчусь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: thesz Россия http://thesz.livejournal.com
Дата: 09.11.08 00:00
Оценка: +2
ВВ>Что-нибудь еще?

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

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

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

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


Выполнилось ли присваивание в x при пошаговом выполнении, так сразу и не поймешь. И на какой ветви мы отвалились, тоже непонятно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 17:47
Оценка: 7 (1)
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>>>
M>>if ((x = MyFunc()) > 4 && x % 2 == 0)
M>>


M>>Тем, что чаще является опечаткой, чем действительно намеренным кодом программиста.


ВВ>Эээ... А каким образом можно так опечататься? В смысле вместо == поставить =? Ну так у тебя это не скомпилируется. Тебе придется все выражение еще в скобочки дополнительные взять — опять-таки и после этого оно не скомпилируется. Надо будет сравнить с чем-нибудь.


А если x имеет логический тип?

ВВ>В общем что-то мне кажется, что сложновато так опечататься.


Я, например, неоднократно опечатывался так в С\С++.
лэт ми спик фром май харт
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 21:47
Оценка: 7 (1)

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


Пример, из головы, 1 минута, не компилируется, не полностью соответствует первому примеру, без стилей:

Экономим строчки:

if( RET_OK == ( result = MyFunc() ) && ( result % LOW_BOUND < MIN_LOW || result % HI_BOUND > MAX_BOUND ) &&
    ( ( RET_OK == ( add_check = MyFunc( PRECISE ) ) || RET_STRANGE == ( add_check = MyFunc( PRECISE ) ) ) || RET_OK == TryValidate( result ) ) ) ||
      result == RESERVED_INT && RET_STRANGE == TryValidate( result ) ) ) )
{
  result += LOW_BOUND;
}


Злобно не экономим строчки, один из возможных стилей, не самый лучший:

result = MyFunc();

if( RET_OK != result )
{
  result = MyFunc( PRECISE );
}

if( RET_OK != result && RET_STRANGE != result )
{
  result = TryValidate( result );
}

bool overbounds = false;
if( RET_OK == result )
{
  overbounds = result % LOW_BOUND < MIN_LOW || result % HI_BOUND > MAX_BOUND;
}

if( overbounds && ( RET_OK == result || RET_STRANGE == result ) )
{
  result += LOW_BOUND;
}
Re[9]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 23:40
Оценка: 7 (1)

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


Говорю же, черная магия . Приоритет операторов. Сперва выполняется peer->channels[ channelID ] что дает нам структуру в массиве / по указателю, а затем над полученным противоестественно выполняется '&', что дает адрес этой структуры. То же самое что peer->channels + channelID. Используется для совместимости с леворезьбовыми компиляторами. Оно же все, [.....], портабельно по самое пикачу и для последнего калькулятора .
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.08 14:55
Оценка: 2 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Длинный говнокод обеспечивают говнокодеры. На VB.NET, даже при соблюдении всех пассов в целях повышения его, так сказать, "типизированности", говнокод вот выходит даже куда лучше в C#. Ну правда, в том, что приложения плохо написаны виноват язык и его возможности, которыми все пользуют без разрабора?


Конечно появление говнокода без "умелых" рук невозможно (ну или плачевного состояния мозга программиста в момент написания оного, например, из-за аврала). Однако есть четкая зависимость между общим объемом говнокода на еденицу площади проекта и языком программирования. Скажем С++ по этом параметру явный лидер. Это не значит, что на С++ нельзя писать качественный код. Это значит, что С++ не способствует написанию хорошего кода.

По мне так если язык уберегает от граблей, то это несомненный плюс. От того на плюсах я вообще перестал писать.

ВВ>Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".

ВВ>Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете

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

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

VD>>Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.


ВВ>У меня возникает такое ощущение, что практика показывает, что человеческий мозг очень хорошо умеет приспасабливать к теории

ВВ>Вот помню были раньше обсуждения — хорошо ли множественное наследование или плохо и почему его нет в C#. Мне вот одно время его не хватало. Теперь я не только о нем не вспоминаю, но, более того, даже готов отстаивать, что множественное наследие — это зло и вообще говоря концептуально неправильно в рамках ООП. А, черт его знает, может так оно и есть. А может, и не так. Но ведь "практика" говорит, извините...

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

VD>>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".


ВВ>Императивный стиль — это мейнстрим.


Это ошибочное заявление которое отлично опровергается хотя бы тем фактом, что в мэйнстриме прекрасно используется SQL (не имеющих к императиву ни малейшего отношения), а теперь еще и Линк.

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

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


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

ВВ>Я вот в императивном стиле проблем особых не вижу. Когда приложение правильно спроектировано, пишется с использованием мозга и пр. Проблемы ведь на самом деле не из-за императивности возникают.


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

VD>>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?


ВВ>Я бы начал даже с неизменяемых in параметров функций.


Это частности. Скажем в Немерле все переменные по умолчанию не изменяемые. В том числе и параметры. Если надо их сделать изменяемыми, то надо использовать ключевое слово mutable перед ним. И никаких проблем. Только изменение подхода. Так просто, а работает на ура.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: jazzer Россия Skype: enerjazzer
Дата: 10.11.08 14:58
Оценка: 1 (1)
Здравствуйте, EyeOfHell, Вы писали:

EOH>В конкретном случае — ничем. Но Дьявол — он в деталях. Зачем такое используют? Чтобы сэкономить строчку. Но код имеет обыкновение рости и меняться. Эволюционировать. Усложняться. Если codestyle допускает inline assignment в целях экономии строчки, то через годик-другой в коде начнут появляться вот такие милые конструкции ( пример, не компилируется ):


Ну да, заставь дурака богу молиться...
На это есть сode review, по которому этот код будет послан не переписывание с пометкой "нечитабельно" (и присваивание тут вообще будет ни при чем).
Не надо стандарт кодирования превращать в святое писание.

EOH>P.S. Некоторые вещи, абсолютно адекватные в примерах уровня "Hello world" приводят к жутким последствиям в долгих проектах с миллионами строчек кода .


Все равно это не повод догматизмом заниматься.
Вещи, абсолютно адекватные в огромных проектах, выглядят воинствующим идиотизмом в программах уровня "Hello world".

Как ты правильно заметил выше: "В конкретном случае — ничем".
Вот этим и надо руководствоваться.
Если в данном конкретном случае все просто и понятно, то значит, так и надо писать.
И не думать, что же там будет после сотого переписывания этого кода — об этом думать должны эти самые сотые переписчики, а не ты (ср. преждевременная оптимизация). Если в результате их переписывания получился нечитабельный код — автор исходного простого и понятного кода тут совершенно ни при чем.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 11.11.08 07:00
Оценка: 1 (1)
Здравствуйте, Undying, Вы писали:

IT>>То, что это плохо в C++ как раз понятно. ВВ хочет понять чем это плохо в C#. Кроме сомнительного аргумента про читабельность пока ничего не прозвучало.


U>А в реальных проектах есть что-то более важное чем читабельность?


Этот приём тоже вполне может повысить читабельность. А может и понизить. Всё зависит от каждого конкретного случая.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:21
Оценка: +1
Здравствуйте, samius, Вы писали:

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

(stub = GetData(key1)) != null && !(stub is DBNull) && ...
(stub = GetData(key2)) != null && !(stub is DBNull) && ...

Мне вот лично проще такой код читать чем полуметровый листинг. Поэтому и всякие ?: и ?? тоже в общем рулят ибо позволяют не расписывать все до соплей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 08.11.08 21:41
Оценка: +1
Здравствуйте, prVovik, Вы писали:

V>В С++ это ещё более плохо, чем в С#.


То, что это плохо в C++ как раз понятно. ВВ хочет понять чем это плохо в C#. Кроме сомнительного аргумента про читабельность пока ничего не прозвучало.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Lloyd Россия  
Дата: 08.11.08 21:55
Оценка: +1
Здравствуйте, samius, Вы писали:


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

S>
S>public Foo Foo
S>{ 
S>    get { return _foo ?? (_foo = new Foo()); } 
S>}
S>


get, меняющий состояние — нафик, нафик.
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 22:11
Оценка: -1
Здравствуйте, EyeOfHell, Вы писали:

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

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

Давайте все-таки не будем касаться вопросов читабельности. Ибо все-таки уж очень субьективный фактор это.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 23:19
Оценка: +1

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


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

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


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

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


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

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


Да нету судя по всему. Все грабли — от невнимательности, забывчивости и лени . Но так как все мы человеки и все мы ошибаемся... то лучше с матюгами нарисовать все защитные заклинания при вызове импа, чем потом лет через семь там же вызвать архидемона .
Re: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 09.11.08 07:47
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

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


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

Кроме того лучше всего читается код, в котором все переменные инициализируется по месту объявления и по возможности не изменяют своего состояния в процессе работы. Сабж этот принцип нарушает, чем ухудшает читабельность кода, не давая абсолютно ничего взамен. Поэтому за использование сабжа в реальном коде надо бить канделябрами.
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: _FRED_ Черногория
Дата: 10.11.08 13:23
Оценка: +1
Здравствуйте, IT, Вы писали:

V>>В С++ это ещё более плохо, чем в С#.


IT>То, что это плохо в C++ как раз понятно.


+1

IT>ВВ хочет понять чем это плохо в C#. Кроме сомнительного аргумента про читабельность пока ничего не прозвучало.


И не будет. Всё дело (использовать-нет) только в читабельности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: COFF  
Дата: 10.11.08 16:53
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

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


COF>>Кстати, немного не в тему, но использование слова ассайнмент вместо давно сложившегося термина присваивание, честно говоря, режет глаз. Я конечно понимаю, что Вы наверняка читаете э лот оф инглиш литрча, бат все-таки может стоит выражаться или по русски, или по английски, а не на смеси того и другого? :)


ВВ>Inline assignment — это устоявшийся термин, перевод которого на русский "устоявшимся" уже не является. Здесь даже есть отдельный форум, посвященный "проблемам перевода".


Ну да, настолько устоявшийся, что первый же пост в теме — а что это такое? :) А вот была бы тема озаглавлена, скажем — чем плох оператор присваивания внутри if, то вопросов бы наверняка не возникло, пусть это и не дословный перевод. Но это я так, просто глаз резануло такое насилие над великим и могучим :)
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: Aikin Беларусь kavaleu.ru
Дата: 11.11.08 07:34
Оценка: +1
Здравствуйте, Undying, Вы писали:

U>А в реальных проектах есть что-то более важное чем читабельность?

Рабочесть? Соответствие ТЗ? Сроки?
Re[10]: [C#] Чем плох инлайн ассайнмент?
От: Aikin Беларусь kavaleu.ru
Дата: 11.11.08 12:28
Оценка: :)
Здравствуйте, Undying, Вы писали:

U>Давай по пунктам:

Не хочу лезть в спор ради спора.

Всего хорошего.
СУВ, Aikin
Re[10]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 11.11.08 15:52
Оценка: +1
Здравствуйте, Undying, Вы писали:

U>1) Работоспособность. Какой код лучше читабельный с пятью багами или нечитабельный с одним багом? Читабельный, потому что в нем эти пять багов могут быть быстро локализованы и исправлены, а в нечитабельном один баг можно до второго пришествия искать.


Работоспостобность — это не только баги, но ещё и нефункциональные требования, вроде требований к быстродействию и используемым ресурсам. Реализуются эти требования как правило с помощью разнообразных оптимизаций на всех уровнях. Оптимизации, в свою очередь, могут в разы ухудшить читабельность кода. Взять хотя бы распараллеливание или кеширование.

U>2) Соответствие ТЗ. Какой код лучше, читабельный, но не реализующий 3 пункта ТЗ или нечитабельный, но не реализующий только один пункт ТЗ? Читабельный, потому что добавить в него реализацию 3 пунктов ТЗ это дело техники, а в нечитабельном коде может быть вообще не понятно как добавлять новую функциональность и что при этом отвалится.


Этот пункт даже не обсуждается. Приложение не просто должно делать то, что от него требуется, оно для этого создаётся. Другими словами, приложение создаётся для того, чтобы оно работало, а не для того, чтобы оно было читабельно.

U>3) Сроки. Какой код лучше, читабельный, который писали год или нечитабельный, который писали полгода? Читабельный, потому что завтра окажется, что как поправить баги в нечитабельном коде и добавить туда новую функциональность никто не знает, и чем решить эти задачи проще переписать проект полностью. Соответственно будут потеряны и те шесть месяцев, которые ушли на написание нечитабельного кода, и еще бог знает сколько времени уйдет на переписывание с нуля.


Сроки можно отнести к нефункциональным требованиям.

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


Какая-то каша получается

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

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

И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.

На практике чаще всего бывает, что вопросов по первым двум пунктам не возникает и требования к сопровождаемости сами собой выходят на первое место. И это правильно. Неправильно фиксировать сопровождаемость на первом месте навсегда и ради неё жертвовать функциональными или нефукнциональными требованиями. Это большая ошибка, которую часто допускают начинающие архитекторы.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: [C#] Чем плох инлайн ассайнмент?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.08 07:48
Оценка: +1
Здравствуйте, IT, Вы писали:
IT>Работоспостобность — это не только баги, но ещё и нефункциональные требования, вроде требований к быстродействию и используемым ресурсам. Реализуются эти требования как правило с помощью разнообразных оптимизаций на всех уровнях. Оптимизации, в свою очередь, могут в разы ухудшить читабельность кода. Взять хотя бы распараллеливание или кеширование.
Правильно! Именно поэтому мы и любим средства, которые позволяют использовать распараллеливание и кэширование не ухудшая читаемость.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: [C#] Чем плох инлайн ассайнмент?
От: Aen Sidhe Россия Просто блог
Дата: 12.11.08 11:13
Оценка: :)
Здравствуйте, Undying, Вы писали:

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


IT>>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.


U>Главное — это соответствие приложения требованиям заказчика сегодня, завтра, через полгода, через пять лет. Читабельный код это необходимое условие выполнения этого требования. Нечитабельный код может соответствовать требованиям заказчика сиюминутно (хотя обычно и в этом случае читабельный код обошелся бы дешевле), но любое изменение этих требований в будущем приводит к проблемам и с работоспособностью, и с функциональностью и со сроками.


Если контракт на конкретный объём работ — зачем мне закладываться на двести лет вперёд? Я завершил разработку по ТЗ, внедрил, мы разошлись. Так что главное — это соответствие ТЗ.

U>Жертвовать требованиями ради читабельности я не призывал, я говорил, что реанимировать читабельный проект с недостающей функциональностью можно, а вот реанимировать нечитабельный проект с недостающей функциональностью нельзя.


Если вы не можете, это не значит, что это невозможно. Да, дорого. Да, муторно. Но вполне реально. Это я по своему опыту говорю.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.08 14:35
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>А зачем тогда вообще две формы ++?


А они автоматом получаются. Описываешь оператор и можешь использовать его как нравится. Особенно хорошо для эстетствующих особ или долболомов считающих что скажем ++i быстрее чем i++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 28.11.08 16:17
Оценка: +1
Здравствуйте, ili, Вы писали:

ili>эт смотря в какой угол эта оптимизация ставиться.


Именно. Как правило оптимизация — это результат реализации нефункциональных требований. Если оптимизация никаких проблем не решает, то она не имеет право на жизнь.

IT>>Если он работает и выполняет свои функции, но плохо читаем, то необходимая цель достигнута. Если же он не работает, но хорошо читабелен, то это провал.


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


Это всё понятно и никто с этим не спорит. Вопрос стоит именно как или-или.

ili>Да и как-то не вяжется первое предложение с тем же BLT и его вылезанностью на предмет читаемости


Тем не менее в BLT полно непонятных на первый взгляд мест, тот же emit или mapping. Без оптимизаций алгоритм мапинга занимал бы 20 строк, но работал бы в разы медленнее.

ili>короче я к тому, что рулит сбалансированность, а крайности никогда до добра не доводят... а если честно то вообще из чистого графоманства ))


Рулит адекватная система приоритетов. Читабельный код важен, очень важен и часто является критерием успеха при длитетельной эксплуатации и развитии системы. Но приносить в жертву функциональные или нефункциональные требования ради читабельности нельзя.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
[C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 07.11.08 22:16
Оценка:
Собственно, сабж.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re: [C#] Чем плох инлайн ассайнмент?
От: Lloyd Россия  
Дата: 08.11.08 00:15
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


А что это такое?
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 01:30
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>А что это такое?


Ну типа:

int x;

if ((x = MyFunc()) > 4 && x % 2 == 0)
{

}
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 17:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>
ВВ>int x;

ВВ>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>{

ВВ>}
ВВ>


Помимо сказанного про ошибки. Зачем всё лепить в кучу: вычисление предиката и действия? Какой смысл специально вводить в язык конструкции, предназначенные для создания предикатов с сайд-эффектами? Какой вообще смысл в предикатах с сайд-эффектами? Чтобы отлаживать было веселее?
лэт ми спик фром май харт
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 18:00
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Помимо сказанного про ошибки. Зачем всё лепить в кучу: вычисление предиката и действия? Какой смысл специально вводить в язык конструкции, предназначенные для создания предикатов с сайд-эффектами? Какой вообще смысл в предикатах с сайд-эффектами? Чтобы отлаживать было веселее?


Так в чем сайд-эффекты? Только в том, что похоже на опечатку?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 18:05
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Я, например, неоднократно опечатывался так в С\С++.


Ну хорошо, положим конкретный пример использования можно перепутать с опечаткой:

if ([bool]x = [bool]GetValue())
{
    ...
}


Что-нибудь еще?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 08.11.08 19:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

Это было актуально в C/C++.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 20:02
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это было актуально в C/C++.


А почему в С++ это актуально, а С#, как говорят некоторые, это плохо?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 20:02
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>if ({ def x = MyFunc(); x + 1 } > 4)
IT>{
IT>}
IT>

IT>Зачем вводить новые локальные переменные выше, если их scope ограничен только условием?

Да уж, если эту тему развивать, то можно прийти к тому, что все будем писать по-старинке:

int x;
x = 3;


Ибо зачем "смешивать" инициализацию переменной и ассайнмент?

Про лямбды с замыканиями я вообще молчу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 08.11.08 20:59
Оценка:
Здравствуйте, IT, Вы писали:

IT>Зачем вводить новые локальные переменные выше, если их scope ограничен только условием?


Локальные переменные нужны для наглядности кода. Не знаю как обстоят дела с компилятором С#, а современные С++ компиляторы очень многие локальные переменные (особенно в циклах) не создают — помещают значения сразу в регистр. Т.е. и наглядность сохраняется, и лишних сущностей фактически не создаётся.
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.11.08 21:01
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


L>>А что это такое?


ВВ>Ну типа:


ВВ>
ВВ>int x;

ВВ>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>

На мой взляд с if-ом этот пример не совместим. Вычисление x явно просится наружу. А вот с употреблением сабжа в цикле я бы согласился:
while ((x = MyFunc()) > 4 && x % 2 == 0)
{
   ...
}


Есть другие примеры, где сабж довольно удачно вписывается:
public Foo Foo
{ 
    get { return _foo ?? (_foo = new Foo()); } 
}
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:07
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Так в чем сайд-эффекты? Только в том, что похоже на опечатку?


Сайд эффект в том, что после проверки условия у нас изменится переменная х. А согласно здравому смыслу, а также ожиданиям того, кто будет читать код, проверка условия не должна вообще ничего менять, она лишь проверяет истинность некоторого утверждения.
лэт ми спик фром май харт
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:07
Оценка:
Здравствуйте, IT, Вы писали:

Честно, не понял. Разве это:

IT>
IT>if (0 == a)
IT>{
IT>}
IT>


писалось не для того, чтобы бороться как раз с теми самыми "опечатками"?

Мне просто интересно понять — есть ли какие-нибудь реальные проблемы у инлайн ассаинмента или это все, что называется, религия. Я вот проблем не замечал и во многих случах он просто напросто удобен.
Точно также как удобнее писать:

int i = 3;

вместо

int i;
i = 3;
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:11
Оценка:
Здравствуйте, prVovik, Вы писали:

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


Переменная x — "состояние" проверки, которое мы анализируем. Потому она меняется. Семантически

GetValue() != 3

и

(x = GetValue()) != 3

полностью аналогичны. Во втором случае я лишь "запоминаю" результат операции, для дальнейших с ним действий. Где здесь нарушение здравого смысла?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


IT>>Это было актуально в C/C++.


ВВ>А почему в С++ это актуально, а С#, как говорят некоторые, это плохо?


В С++ это ещё более плохо, чем в С#. Просто там значением условия может быть не только логический тип, но и ещё куча других типов (все численные, указатели).
лэт ми спик фром май харт
Re: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 21:12
Оценка:

Чем плох инлайн ассайнмент?
if ((x = MyFunc()) > 4 && x % 2 == 0)


В конкретном случае — ничем. Но Дьявол — он в деталях. Зачем такое используют? Чтобы сэкономить строчку. Но код имеет обыкновение рости и меняться. Эволюционировать. Усложняться. Если codestyle допускает inline assignment в целях экономии строчки, то через годик-другой в коде начнут появляться вот такие милые конструкции ( пример, не компилируется ):

if( RET_OK == ( result = MyFunc() ) && ( result % LOW_BOUND < MIN_LOW || result % HI_BOUND > MAX_BOUND ) &&
    ( ( RET_OK == ( add_check = MyFunc( PRECISE ) ) || RET_STRANGE == ( add_check = MyFunc( PRECISE ) ) ) || RET_OK == TryValidate( result ) ) ) ||
    result == RESERVED_INT && RET_STRANGE == TryValidate( result ) ) ) )
{
  result += LOW_BOUND;
}


А такие милы конструкции череповаты последствиями в дальнейшей поддержке проекта .

P.S. Некоторые вещи, абсолютно адекватные в примерах уровня "Hello world" приводят к жутким последствиям в долгих проектах с миллионами строчек кода .
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:13
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да уж, если эту тему развивать, то можно прийти к тому, что все будем писать по-старинке:


ВВ>
ВВ>int x;
ВВ>x = 3;
ВВ>


ВВ>Ибо зачем "смешивать" инициализацию переменной и ассайнмент?


ВВ>Про лямбды с замыканиями я вообще молчу.


Аналогии идут лесом.
лэт ми спик фром май харт
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:15
Оценка:
Здравствуйте, samius, Вы писали:

S>На мой взляд с if-ом этот пример не совместим. Вычисление x явно просится наружу. А вот с употреблением сабжа в цикле я бы согласился:

S>
S>while ((x = MyFunc()) > 4 && x % 2 == 0)
S>{
S>   ...
S>}


Но только при условии, что за границами этого условия х не виден.
лэт ми спик фром май харт
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:18
Оценка:
Здравствуйте, Воронков Василий, Вы писали:


ВВ>Переменная x — "состояние" проверки, которое мы анализируем. Потому она меняется. Семантически


ВВ>GetValue() != 3


ВВ>и


ВВ>(x = GetValue()) != 3


ВВ>полностью аналогичны. Во втором случае я лишь "запоминаю" результат операции, для дальнейших с ним действий. Где здесь нарушение здравого смысла?


Это только при условии, что х больше нигде не используется, кроме как в условии. Если используется, то будут проблемы.
лэт ми спик фром май харт
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:22
Оценка:
Здравствуйте, prVovik, Вы писали:

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


S>>На мой взляд с if-ом этот пример не совместим. Вычисление x явно просится наружу. А вот с употреблением сабжа в цикле я бы согласился:

S>>
S>>while ((x = MyFunc()) > 4 && x % 2 == 0)
S>>{
S>>   ...
S>>}


V>Но только при условии, что за границами этого условия х не виден.


Прочитал собственную фразу и чуть не завис. Слава Богу, стек вовремя переполнился.
лэт ми спик фром май харт
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:24
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Аналогии идут лесом.


Ну в таком случае давай философию в стиле "зачем лепить в одну кучу вычисление предиката и действия" тоже пошлем лесом, ок?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:24
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Это только при условии, что х больше нигде не используется, кроме как в условии. Если используется, то будут проблемы.


Какие проблемы? Я еще ни одной проблемы не услышал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:24
Оценка:
Здравствуйте, EyeOfHell, Вы писали:

EOH>
EOH>if( RET_OK == ( result = MyFunc() ) && ( result % LOW_BOUND < MIN_LOW || result % HI_BOUND > MAX_BOUND ) &&
EOH>    ( ( RET_OK == ( add_check = MyFunc( PRECISE ) ) || RET_STRANGE == ( add_check = MyFunc( PRECISE ) ) ) || RET_OK == TryValidate( result ) ) ) ||
EOH>    result == RESERVED_INT && RET_STRANGE == TryValidate( result ) ) ) )
EOH>{
EOH>  result += LOW_BOUND;
EOH>}
EOH>


Напиши пожалуйста аналог этого код так, как он должен выглядеть правильно на твой взгляд и поставь их вместе. Как раз и сравним читабельность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:28
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


V>>Аналогии идут лесом.


ВВ>Ну в таком случае давай философию в стиле "зачем лепить в одну кучу вычисление предиката и действия" тоже пошлем лесом, ок?


Это ещё почему?
Если уж тебе так хочется использовать аналогии, то докажи сначала, что аналогия корректна.
лэт ми спик фром май харт
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.11.08 21:30
Оценка:
Здравствуйте, EyeOfHell, Вы писали:

EOH>В конкретном случае — ничем. Но Дьявол — он в деталях. Зачем такое используют? Чтобы сэкономить строчку. Но код имеет обыкновение рости и меняться. Эволюционировать. Усложняться. Если codestyle допускает inline assignment в целях экономии строчки, то через годик-другой в коде начнут появляться вот такие милые конструкции ( пример, не компилируется ):


EOH>
EOH>if( RET_OK == ( result = MyFunc() ) && ( result % LOW_BOUND < MIN_LOW || 
EOH>...
EOH>


EOH>А такие милы конструкции череповаты последствиями в дальнейшей поддержке проекта .

Тут уже не сабж виноват, а тот кто забыл про рефакторинг.

EOH>P.S. Некоторые вещи, абсолютно адекватные в примерах уровня "Hello world" приводят к жутким последствиям в долгих проектах с миллионами строчек кода .


Если миллион строчек вставить в одну — то конечно так и будет!
Re[9]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:32
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Это ещё почему?

V>Если уж тебе так хочется использовать аналогии, то докажи сначала, что аналогия корректна.

Слушай, давай ты мне не будешь говорить, что я могу использовать, а что нет. Если нечего сказать, то лучше ничего и не говорить. А вести пустопорожние беседы я не намерен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[9]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:42
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


V>>Это только при условии, что х больше нигде не используется, кроме как в условии. Если используется, то будут проблемы.


ВВ>Какие проблемы? Я еще ни одной проблемы не услышал.


http://en.wikipedia.org/wiki/Side_effect_(computer_science)

Side effects often make a program's behavior more difficult to predict. A "Safe" operation is one that is guaranteed to be free of side-effects, i.e., it may be relied upon to leave the state of the system unchanged. Queries are the canonical safe transactions. Safe operations are also idempotent, although the reverse is not necessarily true.


Основываясь на вышевыделенном, я вправе ожидать, что факт вычисления условия не изменит состояния программы.
лэт ми спик фром май харт
Re[10]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 21:45
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


V>>Это ещё почему?

V>>Если уж тебе так хочется использовать аналогии, то докажи сначала, что аналогия корректна.

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


Иначе получается демагогия. С чего ты взял, что присвоения в условиях аналогичны инициализации переменных? С таким же успехом я могу сказать, присвоения в условиях аналогичны поеданию младенцев.
лэт ми спик фром май харт
Re[10]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 21:54
Оценка:
Здравствуйте, prVovik, Вы писали:

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


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


V>>>Это только при условии, что х больше нигде не используется, кроме как в условии. Если используется, то будут проблемы.


ВВ>>Какие проблемы? Я еще ни одной проблемы не услышал.


V>http://en.wikipedia.org/wiki/Side_effect_(computer_science)

V>

V>Side effects often make a program's behavior more difficult to predict. A "Safe" operation is one that is guaranteed to be free of side-effects, i.e., it may be relied upon to leave the state of the system unchanged. Queries are the canonical safe transactions. Safe operations are also idempotent, although the reverse is not necessarily true.


V>Основываясь на вышевыделенном, я вправе ожидать, что факт вычисления условия не изменит состояния программы.


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

Queries are the canonical safe transactions.

и

int x;

if ((x = MyFunc()) > 4 && x % 2 == 0)
{

}


Где ты здесь видишь "queries"? И каким образом вышеприведенный код нарушает правило "leave the state of the system unchanged"? Что вообще изменяет это код? Он проводит инициализацию переменной x результатом выполнения функции MyFunc, самый смысл выполнения которой в том, чтобы вернуть результат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[11]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 22:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
факт вычисления условия не изменит состояния программы.

ВВ>С чего ты решил, что можешь провести аналогию между


ВВ>Queries are the canonical safe transactions.


ВВ>и


ВВ>
ВВ>int x;

ВВ>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>{

ВВ>}
ВВ>


ВВ>Где ты здесь видишь "queries"?


С того, что предикат, это и есть запрос, у которого результат имеет логический тип.

ВВ>И каким образом вышеприведенный код нарушает правило "leave the state of the system unchanged"? Что вообще изменяет это код?


Значение переменной х

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


Взгляни на код:


ВВ>
ВВ>int x = 10;

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


Что будет выведено на экран?
лэт ми спик фром май харт
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: prVovik Россия  
Дата: 08.11.08 22:06
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


Интересно, почему get (по сути запрос), меняющий состояние — нафик, а предикат (тоже по сути запрос), меняющий состояние — не нафик?
лэт ми спик фром май харт
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 22:11
Оценка:
Здравствуйте, 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);
                });
            }
        }
    }
})))


Замыкания — зло?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 22:13
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


Угу, double check lock паттер — ф топку!
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[12]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 22:33
Оценка:
Здравствуйте, 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-ов, и мозги слетят набекрень, когда будете пытаться определять, где какая переменная объявлена, и какая у нее область видимости.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 22:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


Но какое в ней "скрытое зло" все-таки? Объективно ведь никто не заставлял в C# делать так, что оператор "=" возвращает результат операции. В васике вот не такого.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: [C#] Чем плох инлайн ассайнмент?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.11.08 22:41
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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

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


ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы. В свое время культовые фичи были, чуть ли не главное преимущество С перед Паскалем в тогдашних флеймах. Написать какую нибудь заковыристую конструкцию (ну, типа хрестоматийного уже примера копирования строк), которая хрен-пойми-как-работает считалось мегакруто. Интересно, что получится в результате работы i+++++i в плюсовом форуме до сих пор обсуждают?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: EyeOfHell Россия eyeofhell.habr.ru
Дата: 08.11.08 22:54
Оценка:

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


Да, конечно. Отче вопрос на собеседовании. Если человек знает какой парсер в С++ и про sequence points — он мегакрут . Наверное.
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 23:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

AVK>ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы.

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

MyFunc(++i)

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

Кстати, ведь тернарный оператор тоже в общем-то читабельность не улучшает. И даже нововведенный ??
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 23:13
Оценка:
Здравствуйте, EyeOfHell, Вы писали:

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


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

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

EOH>

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


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


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


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

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

Мне вот было интересно — может, какие другие грабли есть? На которые я по счастливой случайности не наступал. Или наступал, но не замечал А судя по всему нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 08.11.08 23:35
Оценка:
Здравствуйте, EyeOfHell, Вы писали:

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


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

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

EOH>

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

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

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

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


Но чему тут завидовать. Самосовершенствование это хорошо. Это как раз завидую
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: _FRED_ Черногория
Дата: 10.11.08 13:23
Оценка:
Здравствуйте, Lloyd, Вы писали:

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

S>>public Foo Foo
S>>{ 
S>>    get { return _foo ?? (_foo = new Foo()); } 
S>>}


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


Видимое "снаружи" состояние этот геттер не меняет. Так же надо очень криво постараться, что бы такое использование привёло хоть к каким-либо последствиям (можно пример?).
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 10.11.08 13:32
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


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

_FR>
S>>>public Foo Foo
S>>>{ 
S>>>    get { return _foo ?? (_foo = new Foo()); } 
S>>>}
_FR>


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


_FR>Видимое "снаружи" состояние этот геттер не меняет. Так же надо очень криво постараться, что бы такое использование привёло хоть к каким-либо последствиям (можно пример?).

Есть пример — многопоточный доступ.
Однако, при такой необходимости решается double check locking-ом, который здесь уже вспоминали.

Но я тоже не вижу ничего плохово в этом примере. А иначе как же вообще все кэширование организовывать, мемоизацию?
Re[2]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 10.11.08 16:35
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Кстати, немного не в тему, но использование слова ассайнмент вместо давно сложившегося термина присваивание, честно говоря, режет глаз. Я конечно понимаю, что Вы наверняка читаете э лот оф инглиш литрча, бат все-таки может стоит выражаться или по русски, или по английски, а не на смеси того и другого?


Inline assignment — это устоявшийся термин, перевод которого на русский "устоявшимся" уже не является. Здесь даже есть отдельный форум, посвященный "проблемам перевода".
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 10.11.08 17:03
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Ну да, настолько устоявшийся, что первый же пост в теме — а что это такое? А вот была бы тема озаглавлена, скажем — чем плох оператор присваивания внутри if, то вопросов бы наверняка не возникло, пусть это и не дословный перевод. Но это я так, просто глаз резануло такое насилие над великим и могучим


"Непонимающие" всегда найдутся, а "чем плох оператор присваивания внутри if" неправильное название, так речь не только об if, а о любой ситуации, где операция присваивания рассматривается внутри другого выражения как свой результат, благодаря тому, что оператор "=" всегда возвращает результат операции.
Несколько длинновато получается, нет?

А как перевести inline function, например?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: COFF  
Дата: 10.11.08 17:16
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>"Непонимающие" всегда найдутся, а "чем плох оператор присваивания внутри if" неправильное название, так речь не только об if, а о любой ситуации, где операция присваивания рассматривается внутри другого выражения как свой результат, благодаря тому, что оператор "=" всегда возвращает результат операции.

ВВ>Несколько длинновато получается, нет?

Ну можно назвать это вложенным оператором присваивания, тем более, что именно так это и называется :)

ВВ>А как перевести inline function, например?


Встраиваемая функция, подставляемая функция, можно и инлайн-функция — это устоявшийся термин, но никак не инлайн фанкшн :)
Re[5]: [C#] Чем плох инлайн ассайнмент?
От: WolfHound  
Дата: 10.11.08 18:23
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну я привел пример немного "от балды". В действительности инлайн ассайнмент рулит в тех случаях, когда нужно совершить несколько операций — в результате вместо того, чтобы городить огород из локальных переменных, заводишь одну и используешь ее для хранения промежуточного значения. Типа такого:

ВВ>(stub = GetData(key1)) != null && !(stub is DBNull) && ...
ВВ>(stub = GetData(key2)) != null && !(stub is DBNull) && ...
В таком случае лучше сравнение с образцом.
Правда язык сменить придется на более умный.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: ryf  
Дата: 11.11.08 06:34
Оценка:
Здравствуйте, IT, Вы писали:
...

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


Это хороший паттерн. Особенно смешно в отладке под VS получается, когда в Watches добавишь свойство объекта, а оно сразу инициализируется отладчиком. Я чуть клавиатуру не сгрыз пока не понял в чем дело...
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 11.11.08 07:00
Оценка:
Здравствуйте, ryf, Вы писали:

ryf>Это хороший паттерн. Особенно смешно в отладке под VS получается, когда в Watches добавишь свойство объекта, а оно сразу инициализируется отладчиком. Я чуть клавиатуру не сгрыз пока не понял в чем дело...


Да, это не удобно. Можно это конечно пофиксить через кишки студии, но это будет через такую большую задницу, что сама проблема покажется мелочью.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 11.11.08 08:30
Оценка:
Здравствуйте, Aikin, Вы писали:

U>>А в реальных проектах есть что-то более важное чем читабельность?

A>Рабочесть? Соответствие ТЗ? Сроки?

Если в реальном проекте систематически забивать на читабельность кода ради рабочести, сроков и соответствия ТЗ, значит, завтра возникнут проблемы и с рабочестью кода, и со сроками, и с соответствием кода ТЗ.
Re[8]: [C#] Чем плох инлайн ассайнмент?
От: Aikin Беларусь kavaleu.ru
Дата: 11.11.08 09:44
Оценка:
Здравствуйте, Undying, Вы писали:

U>>>А в реальных проектах есть что-то более важное чем читабельность?

A>>Рабочесть? Соответствие ТЗ? Сроки?

U>Если в реальном проекте систематически забивать на читабельность кода ради рабочести, сроков и соответствия ТЗ, значит, завтра возникнут проблемы и с рабочестью кода, и со сроками, и с соответствием кода ТЗ.

Завтра может не настать, если забить на сроки, рабочесть и ТЗ.


Undying, я не говорю что читабельность не важна, нет, я двумя руками за нее и стараюсь ставить ее во главу угла. Но все же важность читабельности меньше, чем все мною перечисленное.
Re[9]: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 11.11.08 11:29
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Undying, я не говорю что читабельность не важна, нет, я двумя руками за нее и стараюсь ставить ее во главу угла. Но все же важность читабельности меньше, чем все мною перечисленное.


Давай по пунктам:

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

2) Соответствие ТЗ. Какой код лучше, читабельный, но не реализующий 3 пункта ТЗ или нечитабельный, но не реализующий только один пункт ТЗ? Читабельный, потому что добавить в него реализацию 3 пунктов ТЗ это дело техники, а в нечитабельном коде может быть вообще не понятно как добавлять новую функциональность и что при этом отвалится.

3) Сроки. Какой код лучше, читабельный, который писали год или нечитабельный, который писали полгода? Читабельный, потому что завтра окажется, что как поправить баги в нечитабельном коде и добавить туда новую функциональность никто не знает, и чем решить эти задачи проще переписать проект полностью. Соответственно будут потеряны и те шесть месяцев, которые ушли на написание нечитабельного кода, и еще бог знает сколько времени уйдет на переписывание с нуля.

Читабельность кода является наиболее важной характеристикой, т.к. она обеспечивает возможность поддержания работоспособности кода, соответствия кода ТЗ и соблюдение сроков. Нечитабельный код может быть работоспособным, соответствующим ТЗ и укладывающимся в сроки только до поры до времени, после чего его неработоспособность, несоответствие ТЗ и неукладывание в сроки начинает устойчиво расти.
Re[11]: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 12.11.08 09:31
Оценка:
Здравствуйте, IT, Вы писали:

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


Оптимизации ухудшающие читабельность выполняются под конкретные требования и затрагивают от силы 10% кода.

IT>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.


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

IT>Неправильно фиксировать сопровождаемость на первом месте навсегда и ради неё жертвовать функциональными или нефукнциональными требованиями.


Ежели систематически жертвовать читабельностью ради требований, то проект в скором времени сдохнет.

Жертвовать требованиями ради читабельности я не призывал, я говорил, что реанимировать читабельный проект с недостающей функциональностью можно, а вот реанимировать нечитабельный проект с недостающей функциональностью нельзя.
Re[13]: [C#] Чем плох инлайн ассайнмент?
От: Undying Россия  
Дата: 12.11.08 11:30
Оценка:
Здравствуйте, Aen Sidhe, Вы писали:

AS>Если контракт на конкретный объём работ — зачем мне закладываться на двести лет вперёд? Я завершил разработку по ТЗ, внедрил, мы разошлись. Так что главное — это соответствие ТЗ.


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

AS>Если вы не можете, это не значит, что это невозможно. Да, дорого. Да, муторно. Но вполне реально. Это я по своему опыту говорю.


Все реально, только обычно дешевле заново написать, используя отдельные функциональные куски из старого кода.
Re[12]: [C#] Чем плох инлайн ассайнмент?
От: IT Россия linq2db.com
Дата: 12.11.08 12:04
Оценка:
Здравствуйте, Undying, Вы писали:

U>Оптимизации ухудшающие читабельность выполняются под конкретные требования и затрагивают от силы 10% кода.


Да хоть пол процента. Главное, что у оптимизаций приоритет выше, чем у читабельности.

IT>>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.


U>Главное — это соответствие приложения требованиям заказчика сегодня, завтра, через полгода, через пять лет.


Вот. Правильно.

U>Читабельный код это необходимое условие выполнения этого требования.


А вот это уже не совсем правильно. Можно нанять команду индусов и они закидают будёновками любую белогвардейскую конницу. При ограниченных ресурасах читабельный код, как часть правильного процесса сопровождения, действительно имеет выжное значение.

U>Ежели систематически жертвовать читабельностью ради требований, то проект в скором времени сдохнет.


Если он работает и выполняет свои функции, но плохо читаем, то необходимая цель достигнута. Если же он не работает, но хорошо читабелен, то это провал.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.11.08 06:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я те так скажу. В Nemerle операции ++/-- (и инфиксная и префиксная) и = имеют тип void


А зачем тогда вообще две формы ++?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 14.11.08 11:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так что на ваши споры я смотрю с усмешкой. Ты ратуешь за фичу думая, что она обеспечит тебе краткость,


Я не ратую за фичу. А пытаюсь развести маленький флейм
Как раз под влиянием твоего комментария в какой-то ветке, что inline assignment это плохо.

VD>в то время как она как раз обеспечивает длинный говнокод который тяжело отлаживать.


Длинный говнокод обеспечивают говнокодеры. На VB.NET, даже при соблюдении всех пассов в целях повышения его, так сказать, "типизированности", говнокод вот выходит даже куда лучше в C#. Ну правда, в том, что приложения плохо написаны виноват язык и его возможности, которыми все пользуют без разрабора?
По-моему как раз напротив — проблема в том, что возможностями языка не пользуются.
А то, что у большинства фичек языка — начиная от самых простеньких вроде того, что оператор возвращает результат операции, и кончая более, так сказать, фундаментальными — есть "побочные" эффекты тут уж ничего не попишешь. Собственно, немалое количество посвящено обсужденями в стиле, полезна ли возможность Х или не полезна.
Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".
Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете

VD>Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.


У меня возникает такое ощущение, что практика показывает, что человеческий мозг очень хорошо умеет приспасабливать к теории
Вот помню были раньше обсуждения — хорошо ли множественное наследование или плохо и почему его нет в C#. Мне вот одно время его не хватало. Теперь я не только о нем не вспоминаю, но, более того, даже готов отстаивать, что множественное наследие — это зло и вообще говоря концептуально неправильно в рамках ООП. А, черт его знает, может так оно и есть. А может, и не так. Но ведь "практика" говорит, извините...

VD>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".


Императивный стиль — это мейнстрим. Практика опять-таки показывает, что у императивного стиля много проблем. Ну а как быть с функциональным стилем? Не появится ли у него даже большее количество проблем, чем у императивного стиля, если он станет мейнстримом?

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

VD>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?


Я бы начал даже с неизменяемых in параметров функций.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: [C#] Чем плох инлайн ассайнмент?
От: Воронков Василий Россия  
Дата: 14.11.08 17:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Конечно появление говнокода без "умелых" рук невозможно (ну или плачевного состояния мозга программиста в момент написания оного, например, из-за аврала). Однако есть четкая зависимость между общим объемом говнокода на еденицу площади проекта и языком программирования. Скажем С++ по этом параметру явный лидер. Это не значит, что на С++ нельзя писать качественный код. Это значит, что С++ не способствует написанию хорошего кода.

VD>По мне так если язык уберегает от граблей, то это несомненный плюс. От того на плюсах я вообще перестал писать.

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

ВВ>>Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".

ВВ>>Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете
VD>Это не аргумент. Я тебе отвечу так. Если код можно написать без изменения состояния, то его лучше написать без него. Иннлайн-присвоение способствует изменению состояния внутри выражения, что легко приводит к появлению трудно уловимых ошибок. Ну, а раз известны пути получения более надежного и при этом более короткого когда, так зачем заниматься извращениями и использовать ненадёжные паттерны?
VD>Так что присвоение нужно рассматривать как оптимизацию. А раз это оптимизация, то ее лучше выделить в отдельную строку, а то и функцию. Так оно надежнее будет. И так мест где можно сделать ошибку слишком много.
VD>Мне кажется не надо переводить стрелки. У множественного наследования есть свои плюсы и минусы. У вычислений без изменения состояния есть только один минус — оно может быть менее шустрым нежели антологичное но с присвоениями. Но если мы и так получаем приемлемую производительность, то возиться с изменением состояния глупо. На этом мы только теряем.

Да дело тут не в сравнении MH и инлайн ассайнмента, конечно. Речь об изменении отношения. Вот года три назад ты бы высказал то же самое мнение об inline assignment?

VD>>>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".

ВВ>>Императивный стиль — это мейнстрим.
VD>Это ошибочное заявление которое отлично опровергается хотя бы тем фактом, что в мэйнстриме прекрасно используется SQL (не имеющих к императиву ни малейшего отношения), а теперь еще и Линк.

Ну если не касаться работы с данными, то разве не мейнстрим? По крайней мере в значительно большей степени чем ФП.
Ты понимаешь, мне лично, в рамках какого-нибудь нетривиального интересного проекта преимущества того же Немерле очевидны. А вот в рамках стандартного такого промышленного проектика — уже далеко не так очевидны. Ибо проблемы как-то все другого плана возникают, не с языком и императивным стилем связанные.

VD>Просто универсальные языки пока что не дотягивают по удобству применения ФП. Как только дорастут, так сразу окажется, что мэйнстрим без проблем примет это диковенное блюдо.

ВВ>>Практика опять-таки показывает, что у императивного стиля много проблем. Ну а как быть с функциональным стилем? Не появится ли у него даже большее количество проблем, чем у императивного стиля, если он станет мейнстримом?
VD>ФП — это всего лишь набор паттернов и средства языка упрощающие их использование. Конечно с дуру можно и хрен сломать, но учитывая, что эти паттерны направлены на упрощение отладки и понимания кода, я не вижу проблем с ними.
ВВ>>Я вот в императивном стиле проблем особых не вижу. Когда приложение правильно спроектировано, пишется с использованием мозга и пр. Проблемы ведь на самом деле не из-за императивности возникают.
VD>Как только в программировании кому-то надо обосновать дырявость используемого им корыта, так сразу начинаются рассуждения о правильном проектировании.

Ну не обосновать, а защитить
А что еще делать? Призать, что императивное программирование — говно? Ну может и говно, но надо как-то жить с этим. Опять-таки не припомню, чтобы я сталкивался с какими-то "специальными" проблемами, которые приводили бы к тому, что хотелось, что называется, "все бросить", развести руками, и сказать — что вот, опять этот долбаный "императивный стиль" виноват, вот писали бы мы на ФП...
Наличие новых "паттернов и средств языка упрощающих их использование" ведь само по себе не означает, что код сразу станет лучше Вот ты, я уверен, напишешь на Немерле более интересное и совершенное приложение, чем на C#.

И потом, неужели тебе лично не доводилось видеть красиво написанных программ в императивном стиле? Я вот не вижу в нем "корень зла", честно.

VD>>>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?

ВВ>>Я бы начал даже с неизменяемых in параметров функций.
VD>Это частности. Скажем в Немерле все переменные по умолчанию не изменяемые. В том числе и параметры. Если надо их сделать изменяемыми, то надо использовать ключевое слово mutable перед ним. И никаких проблем. Только изменение подхода. Так просто, а работает на ура.

Кстати, раз уж речь зашла о Немерле. В Немерле действительно есть optional-параметры? И зачем они там?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[9]: [C#] Чем плох инлайн ассайнмент?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.08 18:45
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>И потом, неужели тебе лично не доводилось видеть красиво написанных программ в императивном стиле? Я вот не вижу в нем "корень зла", честно.


Я тебе говорю о том, что если взять к примеру С или Виртовский Паскаль и сравнить их с Обжект Паскалем и С++, то никто не будет спорить, что наличие в арсенале программиста не только структурного программирования, но и объектно-ориентированного является несомненным плюсом. Но почему-то многие начинают спорить с тем, что поддержка языком СП + ООП + ФП + МП лучше нежели поддержка только СП + ООП.

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

ВВ>Кстати, раз уж речь зашла о Немерле. В Немерле действительно есть optional-параметры? И зачем они там?


Причем тут это? Ну, да ладно.
Да, и не только optional, но и именованных. Правда optional-параметры поддерживаются несколько более ограничено. Их нельзя инициализировать экземплярами объектов. Но это тоже можно доработать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [C#] Чем плох инлайн ассайнмент?
От: ili Россия  
Дата: 27.11.08 16:06
Оценка:
Здравствуйте, IT, Вы писали:

IT>Да хоть пол процента. Главное, что у оптимизаций приоритет выше, чем у читабельности.


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

IT>Если он работает и выполняет свои функции, но плохо читаем, то необходимая цель достигнута. Если же он не работает, но хорошо читабелен, то это провал.


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

короче я к тому, что рулит сбалансированность, а крайности никогда до добра не доводят... а если честно то вообще из чистого графоманства ))
Re[4]: [C#] Чем плох инлайн ассайнмент?
От: Erop Россия  
Дата: 27.11.08 22:54
Оценка:
Здравствуйте, ili, Вы писали:

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


ВВ>>Ну типа:


ВВ>>
ВВ>>int x;

ВВ>>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>>{

ВВ>>}
ВВ>>


ili>вот полчаса думал что это тут написано... тем и плох.

ili>код пишется не для компилятора, а для того кто его сопровождать будет.

А главное, не ясно, от чего не написать так:
int x = MyFunc();
if ( x > 4 && x % 2 == 0)
{
}
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.