Недавно я нашел концепцию грамотного программирования . И я нашел это довольно интригующим. И все же я не сталкивался с утверждениями, что это плохой способ структурировать программу. Кажется, не во многих местах. Даже здесь я не смог найти никаких вопросов по этому поводу.
Мой вопрос не о его недостатках или способах обработки документации. Я считаю документацию побочным эффектом того, что она будет означать для потока грамотного программирования. Я знаю, что дизайн изначально был предназначен для простой документации, а также для концепции прямого программирования.
Концепция деления проблемы на проблемы, основанные на небольших предложениях, кажется действительно блестящей идеей. Таким образом, это облегчит понимание хода программы.
Следствием грамотного метода проектирования также является то, что количество требуемых функций будет ограничено воображением программиста. Вместо того, чтобы определять функцию для определенной задачи, она может быть создана как scrapв грамотном методе. Это приведет к автоматической вставке кода вместо отдельной компиляции функции и последующего требования шага оптимизации межпроцедурной компиляции для получения эквивалентной скорости. На самом деле первая попытка Дональда Кнута показала худшее время исполнения, благодаря этому самому факту. Я знаю, что компиляторы могут быть сделаны во многом из этого, однако это не моя забота.
Поэтому я хотел бы получить обратную связь о том, почему следует считать это плохой / хорошей методологией проектирования?
literate-programmingна StackOverflow также есть тег. Там больше контента, хотя и не так много.Ответы:
Это не имеет значения. Был на протяжении десятилетий. Вы можете убрать это из вопроса, поскольку современные компиляторы не имеют смысла подрывать их оптимизаторы.
Там нет недостатков в грамотном программировании. (Я ожидаю десятки -1 голосов за это чувство.) Как практикующий, я никогда не видел никаких проблем.
Есть некоторые аргументы, против которых все сводится к тому, что «программирование на языке более высокого уровня может быть подорвано путем настройки результирующего кода». Правильно. Точно так же, как программирование на C ++ подрывается путем настройки создаваемого
.oфайла. Это правда, но не имеет значения.Написание грамотных программ просто означает объединение высокоуровневого и детального (на уровне кода) дизайна в один документ, написанный с помощью подходящего набора инструментов, который создает файлы, удобные для компиляции, и файлы, удобные для людей.
Когда Кнут изобрел грамотное программирование, основных ОО-языков не было. Поэтому большая часть оригинальных веб-инструментов и инструментов плетения позволила ему создать классоподобные определения для абстрактных типов данных.
Многое из этого не имеет значения в настоящее время. Инструменты грамотного программирования могут быть довольно простыми, если они ориентированы на современные высокоуровневые объектно-ориентированные (или функциональные) языки программирования. Существует меньше необходимости в сложных обходных решениях из-за ограничений C (или Pascal или Assembler).
Подход к написанию грамотных программ ничем не отличается от подхода к написанию неграмотных программ. Это все еще требует тщательного проектирования, модульного тестирования и аккуратного кодирования. Единственная дополнительная работа - написание объяснений в дополнение к написанию кода.
Только по этой причине - необходимость писать связные объяснения - грамотное программирование является трудным для некоторых программистов. Есть немало программистов, которые успешны (их код проходит все модульные тесты, аккуратен и прост для понимания), но не может написать связное предложение на своем родном языке. Не знаю, почему это правда.
Есть очень большое количество программистов, которые оказываются лишь незначительно успешными, и тогда только случайно. (В Stack Overflow достаточно плохих вопросов, указывающих на то, что многим программистам трудно понять даже основные принципы.) Для программистов, которые задают в значительной степени несогласованные вопросы о переполнении стека, мы знаем, что они не могут сделать хорошую работу по грамотному программированию, потому что они могут не делаю хорошую работу по программированию.
источник
Самым важным аспектом грамотного программирования (или даже просто хорошего комментирования) для меня является не столько то, что он предоставляет документацию, а скорее намерение программиста. Зная заявленное намерение, вы можете сразу судить, действительно ли код, следующий за ним, делает то, что должен. Без намерения вы должны начать с предположения о правильности кода, а затем доказать его правильность или неправильность по индукции, что более утомительно и требует много времени, поскольку для этого часто требуется также ознакомиться со всем окружающим кодом.
Таким образом, заявленное намерение часто позволяет другим, незнакомым с кодом, быстро подключаться и находить ошибки, не зная окружающего его более широкого контекста.
И, конечно же, это помогает вам быстрее освоить основной поток и дизайн кода, поскольку простой английский часто более интуитивен, чем арифметика указателей для большинства людей.
источник
Хотя я довольно новичок в концепции буквального программирования (и, следовательно, вполне вероятно, что я скучаю по лодке целиком), кажется, что она в значительной степени согласуется с концепцией DSL .
Идея DSL состоит в том, чтобы разделить область проблем на простую, ориентированную на естественный язык грамматику, которую можно использовать для построения алгоритмов для решения этих проблем.
Для меня та же самая идея, или, по крайней мере, ее основа, такая же или, по крайней мере, тесно связана с грамотным программированием.
Например, в мире Groovy существует сильный стимул для более регулярного использования DSL и создания новых DSL для решения общих проблем. Этот толчок исходит как от инструментов в языке (простые сборщики), так и от базовых библиотек, поддерживающих API на основе DSL.
Учитывая, что тенденция, по крайней мере в этом уголке мира, заключается в грамотному программированию, я бы сказал, что это хорошая методология, к которой нужно стремиться.
К сожалению, уровень мышления необходим для создания хорошего dsl, часто выходит за рамки того, что я видел у большинства программистов. Я знаю, что лично я борюсь с некоторыми концепциями, необходимыми время от времени. Возможно, именно эта трудность помешала таким методам получить более широкое распространение.
Это ваш классический случай, когда использование инструмента - это одно, а создание - на совершенно другом уровне.
Чтобы немного расширить мою точку зрения, не так много, что DSL - это то же самое, что и грамотное программирование, а скорее то, что они делают грамотное программирование гораздо более возможным . Особенно, когда они являются DSL на естественном языке .
В версии 1.8 groovy возможности DSL на естественном языке были значительно улучшены с добавлением более мощных цепочек команд.
Например, следующие строки кода являются программированием , а не просто псевдо-предложениями:
Примечание: пример кода взят из блога Гийома Лафоржа
Основная идея, лежащая в основе грамотного программирования, заключается в том, что естественный язык более понятен людям, и именно это имеет значение. На мой взгляд, возможности DSL на языке Groovy делают эту реальность намного ближе. Особенно, когда эти DSL используются для создания бизнес-правил для приложения.
Способность «кодировать» критические компоненты системы с использованием естественного языка является самой сутью грамотного программирования. Необходимость перемежать естественный язык с кусками кода - ублюдочная форма грамотного программирования. Хотя это полезно, я считаю, что DSL на естественном языке позволяют использовать естественный язык в качестве самого кода , - огромный шаг вперед.
Расширение возможностей программирования в целом является следующим шагом в этом процессе, но в значительной степени инструменты для этого уже существуют. Да, пока нет «общего» DSL, но для небольших доменов такая возможность есть.
Для большего количества примеров этого в действии (без определенного порядка):
источник
turn left then rightилиpaint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…Я думаю, что ошибочно думать, что LP - это своего рода DSL. Поскольку LP - это журнал (со схемами, схемами, фрагментами псевдокода, то есть кусками) разработанной программы, ее архитектурой и т. Д. Это абсолютно аналог бумажного блокнота - многие разработчики используют их, но после завершения программы - выкинь свои тетради, документы ...
Давным-давно у каждого физика, астронома, химика / алхимика, математика есть свои тетради, рукописи со многими схемами, необходимая информация, таблицы, и без них вы сможете понять или повторить свой успешный опыт, свои результаты. И всегда между такими народами существует охота на рукописей / тетрадей.
Сегодня многие программисты пишут код, а иногда добавляют комментарии! Байт-программа - это не только код - это мысли, идеи, воображение, концепции, а когда новый разработчик наследует чужой код - он часто ломает все идеи и концепции, создает разные «лазейки» и «черные ходы», надеюсь, вы меня понимаете :)
Таким образом, основное требование для LP (как инструмента!) Слишком разрешает все это с простым, легким, читаемым синтаксисом. Я перепробовал много инструментов LP, но сегодня я разрабатываю собственный - NanoLP ( http://code.google.com/p/nano-lp/ ), который призван удовлетворить этот спрос.
источник