Без малого 3 века назад Бэн Франклин опубликовал свой "Альманах бедного Ричарда". В нём были собраны афоризмы, предназначенные служить руководством в повседневной жизни.
В настоящее время, существуют различные сборники "советов" и "рекомендаций" по различным областям жизни. Наиболее яркими примерами являются "Законы Мерфи" и "Законы Паркинсона". Также имеются различные сборники афористических высказываний в области программирования, в частности, а также вообще в области IT-технологий.
Ниже приводятся некоторые практические правила разработки программ, которые не являются абсолютными (бесспорными), но и не произвольны. За каждым из них стоят мысли и опыт.
С первого взгляда некоторые из правил могут показаться тривиальными и слишком несовершенными, чтобы им следовать, но опыт показывает, что рано или поздно от этих заблуждений избавляются. Если Вы уже занимались программированием, то для начала возьмите свои последние "ошибки" и найдите правила, которые были нарушены.
Конечно же, существуют случаи, когда программы не соответствуют стандартным правилам, как есть исключения почти к каждому правилу. Тем не менее, практический опыт покажет, что не следует нарушать правила, тщательно не проанализировав альтернативы.
Правила сгруппированы по категориям.
Перед тем, как писать программу:
1. Полностью определите задачу, т.е., что имеется в наличии, и что нужно в итоге получить.
2. Сначала подумайте, затем программируйте – прежде чем начать программировать, составьте план и разработав алгоритм.
3. Используйте структурный подход – работа над программой должна вестись последовательно, от определения проблемы, до чистки программы на каждом уровне и написания руководства. При структурном подходе:
· Программа создается уровнями, поэтапно. Разбираются только те части программы, которые имеют отношение к данному уровню, и они исчерпывающе формулируются.
· Вопрос о представлении данных откладывается как можно дольше, и потом его решают согласно алгоритму, конечно, насколько это возможно.
· Более того, когда бы программист ни задумал использовать процедуру или встроенную секцию, прежде всего решаются связи, интерфейсы (т.е. аргументы, возвращаемые значения, результаты). Ввод и вывод для процедуры оформляется до самой процедуры, так, что процедуры подстраиваются под подпрограммы, их вызывающие, но не наоборот.
· И что наиболее важно, это то, что на каждом шаге при структурном подходе программист должен иметь полную корректную "программу".
4. Избегайте других подходов.
При кодировании программы:
5. Составляйте программу логическими блоками – лучшие программы те, которые можно легко понять. Структурность программы всегда результат тщательного обдумывания плана.
6. Используйте процедуры – отличительная особенность современных средств разработки – один раз описанное действие можно применять многократно.
7. Избегайте необязательных "GOTO" – безусловный переход можно заменить циклами, условными предложениями и встроенными функциями. Без "GOTO" повышается структурная чёткость программы, сокращается общий размер. "GOTO" часто является причиной беспорядка в программе.
8. Избегайте побочных эффектов – эффект имеет место в процедуре при изменении каких-либо внешних по отношению к ней элементов. Если этот эффект не является главной целью процедуры, его называют побочным. Побочные эффекты могут быть причиной хитрых ошибок, которые чрезвычайно трудно обнаружить. Наиболее обычным источником побочных эффектов является изменение глобальных переменных, т.е. переменных, имеющих силу во всей программе. Ярким примером побочного эффекта является зацикливание.
9. Проверяйте текст на синтаксис сразу, а не потом – синтаксические ошибки в программе мало оправданы, т.к. в руководствах синтаксис точно определён. Исправляйте синтаксические ошибки не во время отладки, а во время кодирования. Всякий раз, когда нет уверенности в синтаксисе, заглядывайте в руководство. На это уйдёт всего несколько секунд, а постоянное обращение к руководству поможет лучше овладеть языком. Подумайте о тех часах, которые можно потратить разыскивая синтаксические ошибки.
10. Используйте удобные мнемонические имена – т.е. давайте переменным названия, которые отражают суть, потом будет проще разбираться.
11. Правильно используйте промежуточные переменные – во многих языках сложные математические вычисления могут быть закодированы в одну непрерывную последовательность действий. Для ясности часто бывает лучше разбить их на части и использовать промежуточные переменные.
12. Не перевычисляйте переменные в цикле – с определённой точки зрения переменные цикла могут рассматриваться как константы. Во время выполнения цикла ни значения активных переменных, ни переменных в выражении присваивания не должны изменяться, их изменение может вызвать различные ошибки, которые очень трудно исправлять.
13. Не перевычисляйте константы в цикле – если в цикле присваивается константе значение, помните, что она будет перевычисляться при каждом прохождении цикла. Избегайте дублирования (воспользуйтесь промежуточными переменными). Выносите повторяющиеся вычисления за пределы цикла.
14. Избегайте системно-зависимых особенностей – в связи с быстрыми изменениями технологии меняются компьютеры и языковые процессоры. К тому же сами программисты могут переходить на другие установки. Поэтому программист должен писать программы так, чтобы при переходе на другую машину или к другому языковому процессору ему бы не пришлось их переписывать. Для гарантии следует выбрать такое подмножество языка, которое избегает системно-зависимых особенностей и сложностей. Системно-независимая программа имеет больше шансов на "мобильность", т.е. сможет работать без предварительных изменений с другим компилятором, отличным от первоначального (так называемые кросс-платформенные приложения). Системно-зависимые особенности служат для сокращения программы и экономии времени. Конечно, программист может в каком-то частном случае использовать особенности конкретной установки, если это необходимо. В таком случае можно сказать, что, действительно, нет правил без исключений.
15. Избегайте хитростей – не пытайтесь по максимуму сократить программу, это может и не привести к выигрышу (временному или ресурсному), но усложнит дальнейшую работу.
16. Пользуйтесь отладочными средствами – в старых языках программирования (например PL1) можно было вставлять отладочные блоки в саму программу. В современных оболочках отладчики встроены и позволяют тестировать корректность работы программы в процессе разработки (например, туда ли осуществляется переход; те ли значения принимают переменные в процессе вычислений).
17. Никогда не предполагайте, что компьютер что-нибудь знает сам – он делает только то, что вы ему "говорите", и чем чётче будут инструкции, тем лучше он будет работать.
18. Используйте комментарии – форма документации, которая позволяет программисту описывать программу внутри самой программы, что облегчает отладку.
19. Пользуйтесь красивой печатью – т.е. пишите текст программы структурно (сверху вниз и наискосок) используя отступы для более чёткого разделения блоков.
20. Обеспечьте хорошую документацию – распространённые недостатки документации - это или слишком мало, или слишком много информации – документируйте так, чтобы перекрыть, но не больше, структуру программы, а также комментарии.
При работе с программой:
21. Перед отладкой проверьте программу – выберите примерный ввод, затем вычислите вывод, как будто вы были бы компьютером – ничего не предполагая и используя строго то, что написано. Проследите, чтобы каждый логический блок работал корректно и последовательность передачи управления между блоками была бы верной. Если программа слишком длинна или сложна, чтобы проверить её сразу целиком, то проверьте сначала наиболее крупные секции, а потом меньшие, предположив, что ранее проверенные секции корректны. При выборе примерного ввода особо проследите за тем, чтобы были включены ограничительные условия и другие особые случаи.
22. Не оформляйте вывод до тех пор, пока программа не заработает правильно – основное в программировании – правильная работа программы. Полное оформление вывода следует отложить до тех пор, пока не разработаны наиболее важные части программы. В деталях разработанный, умный, изящный вывод не производит впечатления, если сама программа работает неправильно. Не следует полностью оформлять вывод, если возможны изменения структуру программы.
23. Когда программа откорректирована, оформите вывод – часто случается так, что, когда программист заканчивает сложную программу, любой вывод ему кажется отличным. Сам программист знает, как его истолковать, но другие люди могут в нём не разобраться, как, может быть, и он сам через полгода.
Общее:
24. Перечитайте руководство – умный программист время от времени перечитывает руководство и иногда бывает приятно удивлён. Как правило, программист придерживается удобного подмножества языка. В результате забываются многие полезные конструкции, в которых может возникнуть необходимость.
25. Изучите другой язык – может какой-то другой язык более подходит к вашей задаче, если условия благоприятствуют, изучите его.
26. Не бойтесь начать сначала…
