Должен ли сгенерированный код быть читаемым человеком?

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

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

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

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

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

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

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

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

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

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

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

Таким образом, человеческая читабельность должна иметь более низкий приоритет; такие вещи, как скорость выполнения или функциональность, гораздо важнее. Это особенно верно, когда вы смотрите на такие инструменты, как bison и flex, которые используют сгенерированный код для предварительной генерации таблиц быстрого поиска, чтобы сделать сопоставление шаблонов, которые было бы просто безумием вручную поддерживать.

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

Нет абсолютно никаких причин, чтобы не сделать его человеческим парсементом, так почему же вы хотите сделать это?

- Адам

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

Я нашел полезным много раз перепроверять различия в сгенерированном коде и исходном коде.

Таким образом, вы можете даже иногда находить ошибки в инструментах, которые генерируют код.

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

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

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

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

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

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

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

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

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

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

Существуют различные типы генерируемого кода, но наиболее простыми типами являются:

1. сгенерированный код, который не должен быть замечен разработчиком. например, xml - код, который определяет макеты (подумайте .frm-файлы, или ужасные файлы, генерируемые SSIS)
2. сгенерированный код, который должен быть основой для класса, который будет позже настроен вашим разработчиком, например, код генерируется для уменьшения утомления при наборе текста

Если вы делаете последнее, вы определенно хотят, чтобы ваш код был читаем человеком.

Классы и интерфейсы, независимо от того, насколько "недоступными" для разработчиков они должны быть, почти наверняка подпадают под сгенерированный код типа № 2. Они будут поражены отладчиком в одной точке другого -- применение форматирования кода-это самое меньшее, что вы можете сделать для облегчения процесса отладки, когда компилятор попадает в эти сгенерированные классы

Как и практически все здесь, я предлагаю сделать его читаемым. Это не стоит ничего лишнего в процессе вашего поколения, и вы (или ваш преемник) оцените это, когда они начнут копать.

Для примера реального мира-посмотрите на все, что генерирует Visual Studio. Хорошо отформатированный, с комментариями и все такое.

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

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

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

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

Я думаю, что ответ таков: это зависит.

*это зависит от того, нужно ли настраивать и хранить сгенерированный код как артефакт. Например, люди очень редко сохраняют или настраивают объектный код, выводимый из C-компилятора, потому что они знают, что могут воспроизвести его из исходного кода каждый раз. Я думаю, что здесь может быть аналогичная аналогия. *Это зависит от того, нужно ли вам сертифицировать код по какому-либо стандарту, например Misra-C или DO178. *Это зависит от того, будет ли сгенерирован источник с помощью вашего инструмента каждый раз, когда код компилируется, или если он будет сохранен для включения в сборку в более позднее время.

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