Почему IDE не поддерживают динамическое форматирование?

Question

Учитывая все священные войны, связанные с различными стилями форматирования кода, и строгие требования многих компаний к форматированию, почему IDE не допускают динамическое переформатирование кода?
Под этим я подразумеваю, чтобы формат IDE представлял собой код так, как этого требует пользователь каждый раз, и сохранял код без какого-либо форматирования вообще. (Ну, может быть, разрывы строк, так что различия все еще просты)
Пользователю не нужно будет беспокоиться о соблюдении стандарта кодирования, люди не потеряют форму от работы с кодом, который отформатирован не так, как ему нравится, а изменения форматирования не будут отображаться в репозиториях diff *. 1003 * Должен быть какой-то механизм для его отключения, чтобы он не испортил старый предварительно отформатированный код, но в противном случае, что мешает ему стать стандартной функцией?

Редактировать: Мне известно, что некоторые IDE имеют функцию переформатирования, но это вызывает почти столько же проблем, сколько и ее решение - различия в управлении исходным кодом становятся практически бесполезными, так как реальные изменения теряются в море незначительных изменений форматирования, и Различная ширина символов табуляции по-прежнему выбивает вещи из строя. Кроме того, он не позволяет программистам работать с кодом в их предпочтительном формате.

Answer 1

Потому что большинству людей нравится видеть код, как он будет зафиксирован. Если все инструменты, которые вы используете для просмотра своего кода (программы diff, grep, средства просмотра исходного кода в Интернете и т. Д.), Не понимают, как динамически форматировать код одинаково, вы будете смущены различными форматированиями, когда будете смотреть на это в вашей IDE против других инструментов.

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

Answer 2

Я думаю, что Eclipse позволяет вам форматировать код так, как вам нравится.

РЕДАКТИРОВАТЬ: Да, форматирование Java Code Formatter основано на правилах, установленных вами в проекте.

Answer 3

Я тоже подумал, что это будет хорошей идеей, но как функция программного обеспечения управления источниками, а не IDE.

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

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

Answer 4

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

Конечно, вы можете контролировать версию AST, но как вы будете отображать комментарии на узлах AST?

Наивным подходом было бы связывать комментарии с утверждениями на языке, но что, если у меня есть комментарий, относящийся к «следующим 3 строкам», и затем кто-то перемещает одну из строк куда-то еще. Куда идет комментарий?

Answer 5

Я думаю, что файлы, которые живут на вашем компьютере, в большинстве случаев должны быть в обычном текстовом формате, бесполезно иметь возможность открывать любой файл с исходным кодом, над которым я работаю, в блокноте или любом другом удобный текстовый редактор. Из-за этого я не хотел бы, чтобы мои локальные копии содержали какие-либо специальные символы, которые в среде IDE интерпретируются как «Это отступ, пожалуйста, используйте вкладку или пробел здесь, если считаете, что это уместно». Мое мнение таково, что лучшим вариантом для такого форматирования является система управления исходным кодом: вы проверяете файл в отформатированном виде, как вам нравится, я проверяю его в отформатированном виде, как мне нравится.

Некоторое время назад я задал этот вопрос об инструментах контроля версий, не понимающих код, и ответ ascalonx, указывающий мне на контроль источников в базе данных . Жаль, что эта идея, кажется, не имеет больше тяги, поскольку она решит обе наши проблемы и намного больше . Я являюсь разработчиком .NET, поэтому в данный момент я очень зациклен на этом, но, очевидно, Eclipse и IntelliJ в мире Java приближаются к этому идеалу (я не знаю, насколько близко, так как я мы никогда не пользовались)

Answer 6

Плагиат будет трудно обнаружить:)

Answer 7

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

Если код написан:

if(value!=null)

и динамический форматер показывает:

if (value != null)

и я изменяю его на:

if ((value != null) && (value.Length > 0))

, а затем другой разработчик динамически форматирует его так:

if ( (value != null) && (value.Length > 0) )

и изменяет какую-то другую строку в коде и сохраняет ее. Сохраняется ли указанное выше форматирование? Как вы согласовываете разные настройки форматирования двух разработчиков, потому что его новые дополнения будут в другом формате.

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

Answer 8

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

Answer 9

Я уверен, что есть программы и скрипты, которые форматируют код так, как вы укажете.

Хотя некоторые IDE поддерживают такое переформатирование кода (Eclipse, Intellij для Java, Wing для Python, VS2007 - для .net), даже если они этого не делают, нужно просто запустить эти сценарии в исходном коде.

Answer 10

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