В плане свойств да, тут безусловно большой профит, убедили!  Возможно, пиши я изначально на C#, я бы эту тему вообще не создал. Но сейчас я согласен, что
 Поэтому   


Автоматически генерируемый код - это, конечно, хорошо, но его

А ИДЕ иногда такого нагородит, что потом сам можешь не понять, что к чему.
  

Не будем уточнять, из какого!  





Это сообщение отредактировал(а) Pawl - 1.6.2014, 09:40

Я уже сказал, что ООП здесь вообще ни при чем. Если ты уверен, что ситуации, в которой это может стать проблемой, не может возникнуть в принципе, то поступай как тебе удобно. Но ведь не все же от тебя зависит.

Тут есть несколько возражений:
1. Изначально мы говорили о тривиальных случаях, а с ними любой инструмент кодогенерации справляется на ура, да и читается все хорошо.
2. Читать сгенерированный код в принципе не обязательно, обычно он используется как внешняя библиотека и проблем это не создает.
3. Много зависит от того, что именно ты используешь для кодогенерации, насколько надежен инструмент и какие возможности дает тебе язык, на котором ты пишешь. К примеру в C# и VB.Net есть такая штука как partial-классы. То есть код одного класса можно описать в разных файлах. Кроме того в одном файле может быть несколько классов, среди которых могут быть и частичные. Такой подход позволяет безболезненно использовать инструменты кодогенерации, посколько автоматически генерируемый код можно легко отделить от ручного. Таким образом сгенерированные файлы вообще даже открывать не обязательно, а на их содержимое можно влиять только через визуальный дизайнер к примеру и при любом изменении в дизайнере файл переписывается полностью. Обычно это работает достаточно надежно.

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

Согласен, удобная штука. Надо будет как-нить обсудить достоинства и недостатки шарпа, но не в этой теме - тут это будет оффтопик.


С этим не соглашусь: ты должен отвечать за выдаваемый тобой код, а как ты будешь отвечать за что-то, чего даже не видел?  Так что тут можно и поспорить - но опять таки в другой теме (типа, надо ли читать, а тем более редактировать код, написанный твоей ИДЕ). А вот холивара из инкапсуляции чёт не получается...  

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

За это пусть Oracle отвечает.   И вообще, я на байт-коде не пишу!  

Это сообщение отредактировал(а) Pawl - 2.6.2014, 18:38

Тогда на вопрос

ответ аналогичный, это пусть <разработчик генератора кода> отвечает.

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

Это сообщение отредактировал(а) Pawl - 3.6.2014, 16:50

Туда это туда же куда тебя пошлет Оракл с твоим багов в JIT (при условии конечно что у тебя не куплен VIP саппорт)?

Разница тут в том, что ты можешь залезть в дебри автосгенерированного IDE java-кода, разобраться в нём, потратив n-ное количество времени, и, найдя там лажу, хлопнуть себя по лбу с воплем "Семён Семёнович!" А потом самостоятельно эту лажу исправить. А баги JDK исправить можешь?

Это сообщение отредактировал(а) Pawl - 3.6.2014, 18:00

1. Про "автосгенерированного IDE" это твоя личная фантазия, diadiavova не уточнял чем генерируется код. А так, сгенеренный код подправить то конечно можно, но как ты предлагаешь это (исправление) автоматизировать?
2. И я о том же, баги в JIT JDK имеют гораздо более серьезные последствия и устраняются на порядок сложнее, чем баги в автосгенеренном коде. Но тебя почему-то сильно пугает "автосгенерированный IDE" код, а код сгенерированный JIT не беспокоит вообще.

А чем еще при разработке может быть автосгенерирован код?  

Никак, только тщательная проверка и правка ручками  Поэтому я стараюсь сразу всё писать сам, а не слепо доверяться какой-то там IDE.

Я вообще стараюсь не беспокоиться о вещах, на которые повлиять не в силах!  

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

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

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

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

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

3. Код, порождающий код. Обычно это какой--то вариант текстовых шаблонов, где код смешивается с операторами языка программирования, которые будут выполняться. 
Пример из MSDN, поддерживается в Visual Studio.

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


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

Вообще-то генерация кода с помощью IDE, это очень плохая практика. Как минимум по тому что такой билд, нельзя автоматизировать и гонять на CI сервере. Ну или придется комитить сгенерированный код в VCS, то тоже не айс.



Я так и представляю, как ты берешь какой нибудь prtobuf, и вдумчиво читаешь все те тонны кода которые он генерирует  




А это тогда тут при чем

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

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

1. Нефиг генерированный код коммитить.
2. Хотел бы я посмтреть на реализованный тобой protobuf сериализатор/десериализатор  
3. Не знаю в какой *** конторе ты работаешь, но у нас за баги никого премии не лишают.