Масштабирование грамотного программирования?

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

Очевидно, с тех пор многое произошло.

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

Отличный вопрос. Мотивация к грамотному программированию никогда не исчезнет, ​​но я думаю, что к этому следует относиться как к плавному. Это означает «дать читателю отдохнуть и научить его тому, что вы пытаетесь сделать». Я не думаю, что это означает «сделайте ваш код действительно многословным».

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

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

Книга «Физический рендеринг» (pbrt.org) - лучший пример крупномасштабного грамотного программирования, о котором я знаю. В книге реализована полная система рендеринга, и текст книги и код трассировщика лучей генерируются из одного и того же «источника».

На практике я обнаружил, что просто использовать такую ​​систему, как Doxygen, и по-настоящему копаться и использовать все ее возможности, лучше, чем полноценное «грамотное» программирование, за исключением таких вещей, как учебники, учебные материалы.

pbrt - это физический трассировщик лучей, написанный в грамотном стиле для обучения выпускников информатики (и меня), это умеренно крупномасштабная система. Как неспециалисту-программисту, этот уровень документации очень важен для понимания того, что делает программа и почему она это делает.

У меня также есть доступ к исследовательскому рендереру на Java, который хорошо написан, но относительно недокументирован, но для нескольких статей SIGGRAPH. Это тоже относительно понятно, но у меня тоже есть доступ к авторам.

Я также довольно часто использовал ImageJ и заглядывал в основную Java - за ней довольно сложно следовать, не имея представления о лежащей в основе философии.

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

Я немного грамотно программировал с помощью WEB около 15 лет назад. Совсем недавно я попытался извлечь код из вики и создать документацию из среды Squeak Smalltalk.

С восходящей частью можно относительно хорошо справиться путем создания документов из фреймворков TDD / BDD, но LP фокусируется на объяснении кода читателю.

Есть несколько проблем:

• история, которую нужно рассказать, разная для разных заинтересованных сторон / читателей;
• структура проекта в большинстве сред не является структурой, необходимой для рассказывания историй;
• поддержка последовательного уточнения / раскрытия отсутствует;
• помимо текста необходима поддержка картинок;
• из комментариев в системе управления версиями можно понять, как была построена система. История должна состоять в том, как система могла быть построена (с идеальной ретроспективой).

Чтобы LP работала в более крупных системах, вам нужна лучшая поддержка IDE, чем вики или обозреватель объектов.

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

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

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

"Overall, Literate Programming is still just text"

Ложь.

Диаграммы в порядке.

My thought would be to use LP to specify components that communicate with each other using event streams

Это просто архитектура, и это нормально.

you can extract a documentation -- a dataflow diagram -- from the net and also generate code from it really well. What do you think of it?

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

Хороший инструмент для письма (например, LaTex) может закодировать диаграмму в документе. Вероятно, вы могли бы найти путь к диаграмме из других частей документации.

Нижняя граница

В конечном итоге вам лучше создать диаграмму как резюме текста.

Почему?

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

Но схематическое резюме некоторой другой разметки LP подойдет.

Попробуйте NanoLP - расширяемый инструмент LP, поддерживающий множество форматов документов (Markdown, OpenOffice, Creole, TeX, Asciidoc и другие), импорт других программ LP, создание шаблонов и многое другое. Пользователь может добавлять собственные команды / макросы (в Python), например, для специального импорта, например, из VCS ... http://code.google.com/p/nano-lp

12,5 лет спустя, наконец, появились некоторые многообещающие разработки. GToolkit предоставляет интегрированные множественные представления, точки входа и инструменты для грамотного программирования.