Опишу свои размышления, раз тема поднялась.
1.Сейчас настройки отображения всех IDE распостраняются вместе с IDE, и это логично, поскольку:а) язык вообщем говоря меняется слабо, а значит раскраски менять не нужно
б) принципы языка практически не меняются, а значит статический анализ кода будет работать всегда для одного и того же языка (всякие окошки с процедурами, класами, файлами проекта)
в) способ документирование кода часто устанавливается вместе с языком. Например, в питоне нужно под методом писать """ описание метода """, в .НЕТ языках можно выставлять XML-коментарии (всегда единого формата). Иногда прибегают к иным способам написания важных коментариев (примеры - смотри документацию ПХП кода). Случаи, когда такой документации недостаточно, нередки, но и описать это важным коментарием иногда сложнее чем написать код.
г) стандартизация рулит, поэтому навыки работы с IDE можна использовать при разработке другого проекта (или в другой IDE).
д) есть еще личные предпочтения програмиста по настройке IDE. Логично хранить их вместе с программой а не проектом.
Теперь применим данные буковки к Форту.
а) язык меняется, да, но все-таки останется некий "дух Форта", который должен быть статичным. Например, маловероятно что слова ":" и "DUP" будут когда-то заменены. Поэтому в случае раскраски получается, что нужен некий статичный режим, записаный внутри IDE, и некий динамический режим, зависящий от проекта. Иначе в разных проектах раскраски будут постоянно дублироватся. Наличие таких двух шаров уже усложняет задачу, ведь неизвестно, что нужно Форт-программисту от визуализации (или известно?)
б) в даном случае необходимо определить, что суть статический анализ для Форта. Если такое определение будет дано, то сразу появится проблема из пункта а) - большинство результатов даного анализа достаточно описать в одном месте (настройки IDE), а дополнительные реализовывать в динамическом режиме. Пример, где могет понадобится проектный стат. анализ - в ОО Форт системах.
в) В Форте также есть устоявшиеся стандарты комментирования. Причем никто (лично мое мнение) и не пытался улучшить их "документированиеспроможность", как правило этого хватало. Поэтому статического подхватывания документации вполне себе хватит. Пользовательская документация по коду - это уже из раздела творчества или новаторства (а это довольно неприятные категории)
г) что тут сказать? Если в одной IDE поиск использования слова будет происходить по комбинации "Ctrl-S" а у другой на эту комбо будет навешано сохранение файла - то так родится хаос. Быстрые клавиши - это всего-лишь пример..
д) тут также (надеюсь) ясно, что Форт сдесь ни при чем
Собственно, среди проблем появляются наши старые знакомые: "что программисту нужно от IDE всегда", "какие программисту могут быть нужны способы управления IDE и/или отображением кода", "Какие возможны способы метадокументирования проекта, какие возможны принципи работы с проектом в колективе", "что-то нужно стандартизировать, но что".
2. Про методы создания этих самых пользовательских особенностей отображения кода1) Тут прозвучал термин "тег для редактора". Лично я предпочитаю называть такую вещь аттрибутом
.
Аттрибут может быть и тегом в том числе, а может формироватся по своим правилам. В любом случае, аттрибут - это привязывание данных определенного вида к слову или группе слов. Действительно, при обычном исполнении аттрибуты должны игнорироватся Форт системой. Но в зависимости от реализации они могут неигнорироватся IDE. Приэтом запись аттрибутов в коментариях не есть обязательной. Аттрибут может быть несуществующим, как-бы мнимым (фиг его знает, понадобится ли такая возможность).
Правило - это определение поведения IDE в отношении аттрибутов. Собственно, правило должно рассказать IDE, как понимать тот или иной аттрибут. Оно применяется уже не слову, а к блоку кода. Что такое блок кода - можно обсудить. Это может быть код в пределах одного файла, это может быть код в пределах проекта, это может быть код до следующего переопределяющего правила, прочее. Правило может применятся к мнимым аттрибутам, правило может применятся к среде в целом.
Настройка - подвид бысто-создаваемого правила. Позволяет указать настройки по-умолчанию для проекта в случае конкретной IDE. (фиг его знает, нужно ли это)
2) В общем случае местоположение правил в коде безразлично. Некто может написать небольшой скрипт, но в необычном стиле, для того, чтобы даный скрипт лучше поняли люди, этот же некто прямо в этом же скрипте встроит правила, облегчающие понимание скрипта. Некто другой откроет скрипт в IDE и увидит тот скрытый текстово-визуальный смысл, который захотел донести первый некто.
С другой стороны, в больших проектах, будет логично разнести правила, разметку, определение документирования, определение проекта в отдельные файлы. В таком случае даже упростится работа для самой IDE - не нужно будет выискивать и исполнять правила в остальном коде.
3) Открытой остается проблема придумывания пользовательских ототбражений кода. Данная область, называемая юзабилити, недоступна для понимания многим программистам, а в сформулированом в даной теме виде, неизвестна вообще никому! Поэтому важной задачей станет придумывание примеров оправданного использования пользовательских отображений кода.
Собственно, мысли еще есть, но как нибудь потом. Когда я начинал тему, не думал что будет настолько сложно.
Вход
Регистрация
Благодарности
Forth-FAQ
