Комментарии под вашим вопросом указывают правильное направление для конкретного рассматриваемого случая, но интересно подумать о том, что является общей передовой практикой при работе над проектом с автоматически сгенерированным кодом, который, как мы надеемся, помечен как таковой комментарии.
Что ж, такой комментарий говорит вам, что это не фактический исходный код, а код, который был передан / сгенерирован из другого исходного . Это действительно не лучшая идея изменить его напрямую, так как процесс, генерирующий этот код (скорее всего, как часть сборки или с помощью инструмента), может отменить ваши изменения, переписав файл. Один из способов думать об этом - это немного похоже на то, если бы это был двоичный файл, сгенерированный компилятором (более правильным термином был бы промежуточный язык). То же самое применимо в этом случае, модификация двоичного файла будет контрпродуктивной, подверженной ошибкам, и изменения будут отброшены фактическим процессом компиляции.
Более того, этот тип кода обычно следует строгим соглашениям и, как ожидается, будет работать, если эти соглашения будут неукоснительно соблюдаться. Следует иметь в виду, что обычно такой автоматически генерируемый код представляет собой тупой код, который лучше оставить инструменту для генерации.
Время от времени я пишу инструменты для автоматической генерации кода, это может быть очень полезно для таких вещей, как склеивание кода (отображение в базу данных, сериализация и т. Д.). Автоматически сгенерированные тесты и т.д ..
Один конкретный пример, который я помню, использовал в реальном производственном коде заглушка . У нас был wpf-клиент, который был помечен нулевыми ссылочными исключениями. Моя команда тратила слишком много времени на их исправление, но все время появлялись новые. В какой-то момент я реализовал настраиваемый инструмент, который создавал бы код, который исправляет модель данных, помещая объекты-заглушки по умолчанию вместо нулевых ссылок.