Действительно ли генерация кода является плохой вещью?

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

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

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

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

Один небольшой лакомый кусочек, если бы действительно делают генерала кода в oo среде, я предложил бы, чтобы Вы перенесли сгенерированные классы, если Вы хотите до степени их от сгенерированных.

Я думаю вопрос того, использовать ли генерацию кода, зависит от того, что Ваши цели с кодом.

Вашим примером уровня доступа к данным является хороший. Ваша проблема с NHibernate состоит в том, что необходимо генерировать доменные классы сами. Если Ваши доменные классы отображаются непосредственно на схему базы данных, то это не проблема. Однако одни из преимуществ NHibernate в этом сценарии точно, что Вы, CAN определяет Ваши собственные доменные классы, и что они не должны отображаться точно на слой базы данных. Это означает, что можно настроить уровень DB позже и единственный код, который необходимо изменить, отображающийся файл. При использовании генерации кода необходимо было бы, вероятно, настроить намного больше кода, и тонкие настройки не всегда были бы так же просты, как тонкие настройки в отображающиеся файлы будут.

Для превосходного примера сгенерированного кода, который очень расширяем, изучите Инструментарий DSL, это - часть Visual Studio SDK. Каждый использует его для определения собственного графического проблемно-ориентированного языка (который сгенерирован), и большая часть поведения может быть настроена через частичные классы и переопределения. Это - очень мощная комбинация.

Два примечания:.NET делает довольно мало генерации кода негласно. Регулярные выражения, XML Преобразовывает, и код Сериализатора XML сгенерирован на лету. Конечно, то же верно для ASP.NET, и я был бы удивлен найти, что оно не использовало больше, чем это (я думаю о XAML).

Кроме того, я хочу сказать явно, что классы, сгенерированные Разработчиком DataSet и тем, "Добавляют веб-Ссылка" и "Добавляют Сервисная Ссылка", являются всеми частичными классами. Можно оставить сгенерированные файлы совершенно одними и все еще расширить сгенерированные классы. Посмотрите нижнюю часть Способов Настроить Ваш Клиентский Прокси ASMX для примера этого.

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

НО в Вашем случае я определенно проверил бы одну конкретную функцию Быстрого NHibernate: автоматическое отображение!Более подробная информация.

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

Мои 2 цента, по крайней мере.

Генератор кода может сэкономить Вам некоторое бесценное время, но имейте в виду, начинаете ли Вы генерировать огромные объемы кода, который также означает, что Вашим кодом не является DRY, означая большое повторение. Это могло представить проблемы для обслуживания кода и ухудшить элегантность Вашего кода.

При нахождении большого количества повторных блоков кода или подобного кода попытайтесь найти лучший путь, такой как Фабрики классов / генерация кода Во время выполнения. Занимает больше времени записать, но это представляет больший интерес и более изящный. Делает обслуживание легче также.

Наконец, если у Вас есть свобода выбрать Ваш язык, Вы могли бы попробовать ActiveRecord рубина (Пакет направляющих), или DataMapper или Продолжение. Они - весь превосходный ORMs, который требует минимальной конфигурации.

Мы не могли функционировать почти на уровне, мы обходимся без генерации кода. Это повсеместно.

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

Кто Вы действительно меня, "Это хорошо для меня для взятия части этой ужасающей силы для моего очень собственного использования?"

На который я ответил бы "Несомненно, Выведите себя из строя. Просто помните 1) с великой державой, прибывает большая ответственность и, 2) только используют его во благо, никогда для зла".

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

Marc

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

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

Если это хорошо сделано, необходимо будет едва возвратиться и настроить его несколько месяцев с этого времени. После того, как Вы генерируете свой код и внесете некоторые корректировки, затем Вы найдете мир в том проекте :P

Генерация кода прекрасна, пока Вы понимаете то, что сгенерировано или когда она заменила значение по умолчанию пользовательским одним (рассматриваемый вопрос)
Для, например, Это - часть отображения nhibernate, сгенерированного MyGeneration
Почему там a

IsChanged

свойство

/// <summary>
/// Returns whether or not the object has changed its values.
/// </summary>
Public virtual bool IsChanged { get; private set; }

Это изменится?, Когда это изменится? и что происходит, когда это изменяется.

nhibernate класс объекта ручной работы будет по всей вероятности иметь только свойства столбца и конструкторов.

Это все сценарии, с которыми Вы столкнетесь, особенно в мире предприятия, где существуют сотни программистов, работающих над проектом и посредственностью факт жизни.

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

К счастью, платформы как .NET допускают частичные классы, дополнительные методы и т.д., которые помогают Вам справиться с ситуациями это.

У меня абсолютно ничего нет против генерирования кода, который не должен быть изменен: это - то, что делают компиляторы :-)

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

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

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

Эмпирическое правило - то, что что-либо сделанное автоматически должно быть повторяемым. Генерация кода не повторяема, если существует какая-либо мысль, требуемая поворачивать то, что она производит, в какой Вы хотите.

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

Я записал 3 генератора кода, но в настоящее время я использую Код Smith. Иногда я использую шаблоны NETTiers. Иногда я использую свое собственное.

Я действительно не забочусь, какой генератор Вы используете. CodeBreeze, CodeSmith, LLBLGen, xslt файлы, и т.д...

Получите один, изучите это, любите его.

КАЖДЫЙ проект я шел в течение 10 лет или больше, включал некоторый сгенерированный код.

Запустите здесь: <http://www.dotnetrocks.com/default.aspx? showNum=63>

<http://www.dotnetrocks.com/default.aspx? showNum=304>

<http://www.dnrtv.com/default.aspx? showNum=77>

<http://www.dnrtv.com/default.aspx? showNum=133>

<http://www.nettiers.org/Home.ashx>

Должен работать.Приятного отдыха.

Это - обоюдоострый меч. С одной стороны, это может быть огромное средство экономии времени. Посмотрите на размер тупиков, которые VS генерирует при указании на него на файл WSDL - я не хотел бы должным быть кодировать это каждый раз, когда я хотел использовать новый веб-сервис.

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

Larry Wall (создатель Perl) говорит, что три кардинальных достоинства являются ленью, нетерпением и гордостью, и что существуют хорошие и плохие версии каждого.

Вы иллюстрируете лень (хороший путь) в попытке автоматизировать скучную и нетворческую работу.Молодец.

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

Генерация кода является хорошей вещью, когда она сделана правильно, но слишком часто делается неправильно.

IMO, генераторы кода должны быть достаточно умными для обработки изменений в сгенерированном коде. Назад в.NET 1,0 дня, даже новейшие генераторы кода Visual Studio.NET могли сделать это - в причине. С.NET 2.0 мы заставили частичные классы делать это еще более легким.

И все же, существуют все еще некоторые генераторы там, которые довольно неспособны к работе несколько раз.

Мои правила для "хорошей" генерации кода:

• Код должен быть сгенерирован в IDE, для которого сгенерирован код. Никакие сторонние исполняемые файлы. Обычно это - плагин Visual Studio, но это правило относится к другим языкам также.
• Сгенерированный код должен обеспечить ясные и легкие дополнительные возможности.
• Сгенерированный код должен быть в других отношениях невидим для разработчика.
  • Другими словами, разработчик должен только использовать разработчика для изменения сгенерированного кода.

Множество хороших ответов.

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

Основной вопрос, который я задаю генератору кода: «Я понимаю, что он делает?».
Если я этого не сделаю, то, вероятно, это мне не поможет.

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

Я настоятельно рекомендую использовать Ruby в качестве инструмента для генерации кода. Я генерирую код C ++ и C # из Ruby. Входом в генератор кода является простой внутренний DSL.

Создание кода во время сборки - это плохо , потому что:

• его труднее поддерживать - новый программист, просматривающий проект, может потратить неделю на понимание того, что какой-то код действительно сгенерирован;

• он требует генерации полной сборки, а в среде разработки вы не хотите часто проходить полную сборку;

• когда возникает исключение в сгенерированный код, вы застряли;

• он требует дополнительных (часто сложных) настроек SCM, чтобы его игнорировать;

• вы не можете изменить его, даже если захотите, потому что он будет переопределен в следующей сборке;

• ​​изменение определений, из которых генерируется код, может привести к нарушению кодовой базы, но это будет обнаружено позже (т. Е. Вы можете успешно развиваться, имея сломанный код).