Интуитивная мотивация для Грамотного программирования?

StackOverflow https://stackoverflow.com/questions/1246406

Вопрос

Итак, я использовал каракули /lp модуль для написания моей первой грамотной программы с использованием plt-scheme:

#lang scribble/lp
(require scribble/lp)

<<lp_scheme.ss>>

@chunk[<squarefunction>
        (define (f x)
         (* x x))]

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

Это было полезно?

Решение

(Я предполагаю, что вы используете определение грамотного программирования Дональда Кнута.)

Ключевое отличие заключается в одном из последовательность.

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

Чтобы проиллюстрировать:

  • Весь код для определенного класса должен быть выражен в одном месте
    (или в очень небольшом количестве мест, напримерЧастичные классы C #)
  • Весь код для одного метода должен быть предоставлен за один раз, в правильном порядке выполнения
  • Зависимости должны быть объявлены перед вещами, зависящими от них
    (переменные, объявленные перед использованием в большинстве языков;процедуры / функции, объявленные до использования в Pascal;сборки библиотек, скомпилированные раньше других в .NET)

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

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

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

Другие советы

Основная мотивация, как по мне, заключается в том, что каждый программист использует бумажные листы / блокнот для "проектирования" архитектуры, разработки идей, там он пишет схемы, диаграммы, пытается немного посчитать и так далее.После завершения программы все эти записные книжки / листы бумаги теряются, поэтому поддержка программы снижается.Я написал об этом в WiKi моего LP-инструмента NanoLP: http://code.google.com/p/nano-lp/wiki/AboutLP.

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

Есть много разработчиков, которые никогда ничего не рисуют, даже без комментариев (!), они только пишут программы...Ужасно!

И LP помогает вам создавать хорошую документацию (не формальным способом - описание функций, это аргументы и то, что они возвращают, и, конечно, это хорошо известно с сигнатурой функции, так зачем нужна такая документация ??), но это помогает писать РЕАЛЬНУЮ ФАКТИЧЕСКУЮ документацию с семантикой, с картинками, с описанием реальных действий...

Много мотиваций :) И, конечно, иногда лучше использовать только обратную пластинку (Doxygen, например), иногда - настоящую пластинку, зависит от многих факторов.

Грамотное программирование основано на трех простых утверждениях:

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

Действительно, по моему опыту, № 2 обычно терпит неудачу.Я сбился со счета, сколько раз QA говорил мне: "в документе сказано это, но код делает ЭТО;неверен ли код или документ устарел?" Я не ожидаю, что мое рабочее место в этом отношении необычно.Кроме того, в одном из моих ранних проектов я пытался поддерживать документы в актуальном состоянии, поскольку обмен мнениями с заинтересованными сторонами привел к изменению требований.Это заняло достаточно много времени, и руководство сказало мне прекратить возиться с документами и просто запустить проект.С тех пор мы перешли к менее утомительным процессам документирования (слава небесам!).

У нас есть инструменты проверки кода, где, когда мы вносим изменения в код, множество людей могут видеть изменения, четко очерченные, и могут оставлять комментарии, задавать вопросы, объяснять материал, предлагать улучшения.Если бы код был написан с использованием Грамотных методов программирования, большая часть этого вопроса / ответа была бы избыточной, потому что объяснение было бы включено.

Большая часть мышления современного программирования заключается в том, что ваш код должен представлять собой собственную документацию.Многие эксперты утверждают, что, если вам понадобится объяснить свой код в комментариях, вам, вероятно, следует переформатировать код (изменить имена переменных / функций и т.д.) Таким образом, чтобы комментарии стали ненужными.Я нахожу это замечательным в теории, менее практичным в реальности.Я имею в виду, когда я использую библиотеки, созданные / поддерживаемые кем-то другим, их выбор имен методов / функций не всегда интуитивно понятен для меня.Например:

Set<String> statesWeCareABout = new HashSet<String>(Arrays.asList(new String[] { "one", "two", "three" }));
Set<String> statesWeFound = <some function>;
statesWeFound.retainAll(statesWeCareAbout);

Если вы не знакомы с Set<> или хэш - набор<>, возможно, вы этого не знаете .retainAll() означает дать мне пересечение двух, с результатом в измененном наборе<>.

Наконец, грамотное программирование обычно позволяет вам разбить все на части, чтобы вы могли объяснить этот фрагмент кода изолированно, а затем встроить его в этот другой фрагмент кода.Это больше соответствует тому, как работает человеческое понимание.Объясните мне, как это работает, затем опирайтесь на это понимание, чтобы объяснить общую картину.Компьютерам на самом деле все равно;вы можете написать одну функцию с 1000 строками кода, и у нее не возникнет проблем с пониманием всего этого.Да поможет вам Бог, если вам, как разработчику, придется поддерживать это.

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

И действительно ли у нас есть время продолжать заново изобретать колесо?

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top