Двухуровневая организация исходного кода. Неизбежно или бессмысленно?

в 7:27, , рубрики: исходный код, Программирование, разработка, среда разработки, метки: , ,

Я достаточно давно занимаюсь разработкой программного обеспечения, и все это время не могу отделаться от мысли, что непосредственно языки программирования либо не развиваются вообще, либо развиваются крайне вяло. Все развитие с 80-х годов заключается в виде каких-то, порой малопонятных, танцев вокруг C++. По сути, мы по-прежнему пишем на том, что было придумано 30 лет назад, исключая незначительные «поправки».

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

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

Я исхожу из того факта, что подавляющее большинство разработчиков уже давно не пишет в текстовых редакторах, а в той или иной мере использует достаточно продвинутые средства разработки. Предлагаю сделать еще один принципиальный шаг в этом направлении. А именно уйти от плоско-текстового способа работы с исходными кодами. За аналогию возьмем, например, тот же HTML, на самом деле не суть важно. Основной смысл в том, что среда разработки, если придерживаться выбранной аналогии, будет выступать в роли браузера исходного кода с возможностью его редактирования. То есть видеть/править мы будем не исходный код в его конечном виде, а код в более удобном для нас представлении в тот или иной момент времени. Так же как мы сейчас в браузере видим не HTML исходник, а нечто более «приятное». Что мы этим решаем? На мой взгляд, очень многое.

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

2. Решается проблема разделения сущностей. Ну, в наиболее распространенном примере, это типы и переменные. Сейчас это решается как попало, например, в Java типы принято писать с большой буквы, переменные с маленькой, в Delphi типы начинаются с «T» и т.п. Но все это довольно коряво. В предполагаемом подходе, объявляемый пользователем тип, скажем, Table будет выглядеть как Table только для пользователя, для среды это будет что-то вроде <type name="Table"/>, не суть важно, важно то, что среда разработки в любой момент времени будет знать, что это именно тип данных, даже не имея «под рукой» файла, где этот тип определен. В результате мы смело можем определять типы, переменные и т.д. в одном регистре, без каких либо префиксов, суффиксов и т.п. Но, тем не менее, разработчик всегда точно будет знать, что это за Table перед ним, поскольку он всегда будет выделен особым образом, например, шрифтом и (или) цветом.

3. Решается проблема документирования исходного кода. Да, конечно, сейчас есть инструменты, типа JavaDoc, но помимо сомнительной эстетичности, у нее есть и ряд ограничений. Попробуйте, например, описать код на разных языках или описать отдельно каждый параметр функции. В предлагаемом подходе, таких проблем не будет. Мы без труда можем привязать сколь угодно большой и сколь угодно многоязычный блок документации буквально к каждому слову кода. При этом документируемый текст будет совершенно невиден пользователю до тех пор, пока он сам не захочет его увидеть.

4. Мы сможем хранить ресурсы, любые, вплоть до звуков и картинок, непосредственно в исходном коде, причем связывая их с ним напрямую. Наиболее распространенным примером для этого может служить, наверное, визуальная разработка, когда данные форм хранятся в отдельных ресурсах, те же .dfm в Delphi, xml ресурсы в Android и т.п. Конструкция получится более устойчивой и удобной и, наверное, более функциональной.

5. Станут доступны следующие, ныне совершенно немыслимые конструкции, типа

Двухуровневая организация исходного кода. Неизбежно или бессмысленно?

или описание параметров функции в виде таблицы, а элементов класса в виде дерева.

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

Автор: poterin

Поделиться

* - обязательные к заполнению поля