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

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

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

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

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

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

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

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

+1

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

И не будет. Всё дело (использовать-нет) только в читабельности.

Здравствуйте, _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-ом, который здесь уже вспоминали.

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

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

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

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

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

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

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

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

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

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

You will always get what you always got
  If you always do  what you always did

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Встраиваемая функция, подставляемая функция, можно и инлайн-функция — это устоявшийся термин, но никак не инлайн фанкшн :)

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

ВВ>Ну я привел пример немного "от балды". В действительности инлайн ассайнмент рулит в тех случаях, когда нужно совершить несколько операций — в результате вместо того, чтобы городить огород из локальных переменных, заводишь одну и используешь ее для хранения промежуточного значения. Типа такого:
ВВ>(stub = GetData(key1)) != null && !(stub is DBNull) && ...
ВВ>(stub = GetData(key2)) != null && !(stub is DBNull) && ...
В таком случае лучше сравнение с образцом.
Правда язык сменить придется на более умный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

U>Давай по пунктам:
Не хочу лезть в спор ради спора.

Всего хорошего.
СУВ, Aikin

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

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

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

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

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

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

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

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

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

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

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

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

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