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

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

это может выглядеть примерно так:

Процедура ResolveCollisions

Выполняет апостериорное разрешение столкновений с помощью алгоритма пространственного разделения

параметры

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Локальные переменные

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

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

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

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

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

Однако для «статического» отображения кода вы можете легко украсить исходный код. Например, возьмите любой наполовину приличный конвертер source-> html и добавьте в таблицы стилей любые размеры и стили шрифтов, которые вам нравятся, и вы получите богато отформатированный код.

Простая причина: независимость редактора / инструмента.

Как только вы сделаете свой код «обогащенным» - он будет привязан к редактору, который вы использовали - или к тем, которые могут понимать богатый код. Все остальные редакторы, которые не могут справиться с богатством, покажут бред.

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

А как насчет контроля версий? Как бы вы сказали ему игнорировать все изменения в форматировании и видеть файлы измененными только тогда, когда есть какое-то "реальное" изменение.

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

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

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

Почему его не существует? Там нет спроса / необходимости в этом.

Современные редакторы могут удовлетворить потребности программистов с подсветкой синтаксиса и некоторыми другими незначительными стилистическими опциями. Это уже не «богатый текст»?

Это уже существует для LaTeX в режиме AucTeX для Emacs. Заголовки разделов больше по размеру, суб- и верхние индексы изменяются соответствующим образом, и вы даже можете иметь небольшие предварительные просмотры математики (и, возможно, других сред, таких как Algorithmic).

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

Другое дело Emacs может сделать , это заменить символы , как ->и forallс →и , ∀соответственно , в Haskell. Существует мало причин, по которым подобные вещи нельзя распространять на форматирование, как вы предлагаете, за исключением того, что в Haskell это вообще не нужно.

Некоторое время назад я задал этот вопрос о форматировании кода, спрашивая, хотят ли программисты форматировать их код при вводе.

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

Мой личный опыт был совсем другим. Хотя я обычно использую общедоступные инструменты, иногда мне нужно написать XSLT в моем собственном редакторе. Этот редактор форматирует код по мере ввода текста с помощью отступа на левом поле, поэтому у меня нет проблем с нежелательным пробелом (существенным в XSLT) и позволяет моему коду переноситься по словам, но при этом все еще поддерживается форматирование. Я нахожу этот опыт вполне естественным, стиль форматирования контролируется только контекстом и положением перевода строки (этот опыт особенно полезен при использовании сенсорных устройств ввода).

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

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

Также в более чем нескольких языках (Haskell, Ruby, Python, Erlang, CoffeeScript и некоторых других) важен отступ. Так что, если вы меняете размеры шрифта, это может быть очень сложно понять.

В основном это традиция. Я профессионально программирую в течение почти 20 лет, и я подозреваю, что это сведет меня с ума. Я пишу книги в Emacs или VI с docbook, поэтому я не фанат WYSIWIG

CWEB Кнута делает это, но работает только для C / C ++ и Pascal. - Вы должны взглянуть на это, хотя ... это довольно аккуратно. Есть две программы: ctangleи cweaveкоторые объединяют / разделяют файлы CWEB в TeX и C соответственно.

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

Конечно. Xcode поддерживает стили помимо простой окраски для другого синтаксиса:

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

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

Другой вопрос заключается в том, следует ли использовать стилизованный текст как часть самого синтаксиса языка. Например, должен ли компилятор использовать тот факт, что некоторый текст имеет определенный стиль, чтобы определить, является ли текст объявлением функции? Поначалу это может показаться странным, но языки вроде Python и Fortran уже используют отступ в качестве синтаксиса. Тем не менее, я думаю, что более вероятно, что мы продолжим видеть стиль, управляемый синтаксисом, а не наоборот. Есть много преимуществ, которые дает возможность использовать простой текст (более простые компиляторы, независимость от платформы, предпочтения программиста), и другие традиции развивались, чтобы сделать код читаемым в отсутствие стилей (отступ, пустые строки, символы маркера и функции редактора, такие как свертывание кода и навигационные меню).

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

Никогда не прекращается пламенная война на одну и ту же тему в мире наборов между теми, кто предпочитает WYSIWYG-редакторы (например, MS Word), и такими системами, как TeX (LaTeX).

В целом однозначного ответа нет. Все зависит от инструментов, вариантов использования и личных предпочтений.

Такие инструменты, как Doxygen или JavaDoc, уже позволяют форматировать код в расширенном текстовом формате. Они также добавляют гипертекст кода для просмотра. Вам не нужно вставлять специальные теги для базового форматирования.

Это не WYSIWYG, хотя.

Я боюсь сказать, что это существует.

В прошлом я работал над неким кодом Centura (также известным как Gupta или SQL / Windows - старый код « 4GL »). На самом деле было невозможно редактировать код Centura в стандартном редакторе, таком как блокнот, до необходимого уровня форматирования.

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

Кроме того, форматирование часто вызывало проблемы при объединении в системе контроля версий.

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

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

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