Чем плоха кодогенерация? (продолжение)
Поехали!
> сгенеренный код затем используется в рукописном коде.
> И тогда главным недостатком является потеря возможности
> рефакторинга, такой привычной, что ее замечаешь только тогда,
> когда она исчезает.
Практически это решается хранением созданного прототипа и
поправленной руками версии, чтобы сохранить возможность прививки
ручных изменений. Можно хранить текстовую разницу, если это
больше нравится.
Например, такое делается в pkgsrc и FreeBSD ports.
> Менее значительным и более спорным является недостаток –
> ухудшение читаемости source code-а. И это тоже следствие
> нарушения DRY
Это очень спорно, поскольку на практике:
а) чаще всего навязывают формальный стиль, который автоматизируется;
б) этот формальный стиль выбирают из соображений читаемости;
в) алгоритм форматирования является безусловным стандартом, что
и есть DRY.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
> И тогда главным недостатком является потеря возможности
> рефакторинга, такой привычной, что ее замечаешь только тогда,
> когда она исчезает.
Практически это решается хранением созданного прототипа и
поправленной руками версии, чтобы сохранить возможность прививки
ручных изменений. Можно хранить текстовую разницу, если это
больше нравится.
Например, такое делается в pkgsrc и FreeBSD ports.
> Менее значительным и более спорным является недостаток –
> ухудшение читаемости source code-а. И это тоже следствие
> нарушения DRY
Это очень спорно, поскольку на практике:
а) чаще всего навязывают формальный стиль, который автоматизируется;
б) этот формальный стиль выбирают из соображений читаемости;
в) алгоритм форматирования является безусловным стандартом, что
и есть DRY.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
Практически это решается хранением созданного прототипа ия имел ввиду не правку сгенеренного кода, а использование его в других кусках кода. А для того, о чем ты говоришь, в C# есть механизмы partial классов и методов, обычно их достаточно.
поправленной руками версии, чтобы сохранить возможность прививки
ручных изменений. Можно хранить текстовую разницу, если это
больше нравится.
а) чаще всего навязывают формальный стиль, который автоматизируется;для этого обычно пользуются тулзами типа ReSharper-а. Но я не о таких кодогенераторах. Я о "массовых" кодогенераторах, которые действуют не точечно на уровне названий переменных и методов в процессе набора кода, а о тех, которые сразу генерят сотни и тысячи строк кода.
в) алгоритм форматирования является безусловным стандартом, что
и есть DRY.
autoconf и есть --- массовый кодогенератор.
Ещё таковыми являются Lex и YACC.
---
...Я работаю антинаучным аферистом...
Ещё таковыми являются Lex и YACC.
---
...Я работаю антинаучным аферистом...
выбора между кодогенерацией и новой возможностью реализации, появившейся с выходом C# 3.0Что, простите?
Оставить комментарий
6yrop
продолжение вот этого .В том треде я не упомянул важный момент:
сгенеренный код затем используется в рукописном коде.
И тогда главным недостатком является потеря возможности рефакторинга, такой привычной, что ее замечаешь только тогда, когда она исчезает. О рефакторинге хорошо написано в русской статье в Википедии
Поэтому я бы не стал (без дополнительных условий) включать пункт “Source code generation” в список “When DRY may not be advantageous”
Менее значительным и более спорным является недостаток – ухудшение читаемости source code-а. И это тоже следствие нарушения DRY
P.S. Вопрос из сабжа мне интересен в контексте выбора между кодогенерацией и новой возможностью реализации, появившейся с выходом C# 3.0. Но это отдельная тема.