Правила программирования. Успокойся и все получится
Каждая программа должна начинаться с комментария, содержащего имя и фамилию программиста, назначение программы, номер версии и дату создания.
Каждая подпрограмма должна начинаться с комментария, кратко описывающего назначение подпрограммы. Комментарии должны описывать что делает код, а не как он это делает. Отслеживая код, программист сам увидит, как он работает.
В исходном коде весьма полезны пустые строки, обозначающие разбивку программы на разделы.
Если назначение оператора или группы операторов трудно понять из исходного кода, то он должен быть снабжен кратким комментарием. Однако описывать отдельные операторы следует как можно реже. Обычно эффективность таких комментариев невелика. Если комментарий описывает то, что несложно увидеть из кода, он даже затруднит чтение кода. Если такой комментарий все же необходим, располагайте его в начале блока, чтобы не разрывать структуру программы.
Имена переменных и подпрограмм должны быть информативными, т.е. такими, чтобы, глядя на них, другой программист мог догадаться о назначении переменной или подпрограммы. Плохо подобранное имя, дезориентирующее читателя, даже хуже, чем неинформативное имя, например X или A. Имена переменных должны состоять из букв нижнего регистра, кроме букв, с которых начинается второе или последующие слова, входящие в имя, например taxRate или numberOfCars . Имена подпрограмм должны начинаться с буквы верхнего регистра.
Имена объектов, свойств и методов должны начинаться с букв верхнего регистра.
Имя каждого компонента должно начинаться с префикса, состоящего из трех букв нижнего регистра и обозначающего тип компонента. Например, имя формы содержит префикс frm , поля ввода – edt , кнопки – btn и т.д. Буквы после префикса описывают назначение или содержание компонента. Например, поле ввода edtLastName содержит фамилию.
Для улучшения читаемости исходного текста программы рекомендуется писать не более одного оператора в строке, что вызвано особенностями восприятия текста человеком. Кроме того, это облегчает пошаговую отладку в символьных отладчиках.
Не следует опасаться того, что программа слишком вырастет в длину, так как реальные программы и без того настолько длинны, что несколько «лишних» страниц (или даже десятков страниц) не меняют общую ситуацию. Выигрыш же в понимаемости с избытком покрывает увеличение длины.
Два оператора в строке вполне допустимы, если второй подчинен первому, причем является единственным подчиненным. Использование двух и более операторов в строке не только допустимо, но и желательно, если это позволяет подчеркнуть некую систему в локальной последовательности операторов.
4.2. Правила разработки программ
У всех вещественных констант цифры должны быть как слева, так и справа от десятичной точки, например 0.15, а не.15.
Следует по возможности избегать смешанных арифметических операций, выполняемых над операндами разных типов. Используйте встроенные подпрограммы преобразования типов.
Для преобразования вещественного значения в строку и обратно используйте процедуры Str () и Val (), а для целых значений в языке Object Pascal – функции StrToInt () и IntToStr () соответственно.
Выражения, состоящие из многих операторов, должны содержать круглые скобки, облегчающие понимание этих выражений.
Удаляйте ненужный код. Особенно это относится к операторам внутри циклов, выполняющихся многократно. Например, нет необходимости присваивать значения переменным или элементам массива перед присвоением им значений другими операторами. Любой такой оператор присваивания уменьшает эффективность программы и делает код более громоздким.
Избегайте использования глобальных переменных. Если несколько подпрограмм используют одну и ту же глобальную переменную, то могут возникнуть серьезные проблемы в процессе отладки, так как трудно будет отследить, какая подпрограмма изменяет ее значение. Переменные, используемые в нескольких подпрограммах, лучше передавать через параметры, так как в этом случае их использование становится более очевидным.
Во время изучения программирования следует придерживаться некоторых правил, которые помогут облегчить вашу работу. Эти правила выполняют программисты всего мира, использующие все языки программирования:
комментарии – следует приобрести привычку добавлять к коду комментарии. Даже строки, кажущиеся ясными в данный момент, могут стать непонятными, если вы вернетесь к ним через месяц;
имена переменных – используйте имена переменных, отражающие их назначение. Они дополнят комментарии и помогут понять код, когда вы вернетесь к нему позднее;
имена функций – все вышесказанное относится и к именам функций. Они должны описывать выполняемые ими действия;
чем короче, тем лучше – во Flash нет ограничения на длину функции. Тем не менее, если вы напишите функцию длиной в 100 строк, позднее вам будет непросто ее редактировать. Лучше разбить функцию на задачи и поместить каждую задачу в отдельную функцию;
включайте в код многократно используемые функции – во время программирования не забудьте подумать о том, как можно применить ту или иную функцию к схожей или аналогичной задаче другой части вашей программы. Допустим, вам необходима функция, добавляющая одно очко к счету игрока. Постарайтесь использовать в ней параметр, позволяющий добавлять к счету не только одно, но и любое другое количество очков;
старайтесь обходиться без жесткого кодирования – под жестким кодированием подразумевается включение в ваш код конкретных чисел. Допустим, для описания правой стороны рабочего поля в вашем коде используется значение 550, оно будет жестко закодировано в программу. Если вы решите расширить рабочее поле до 600 пикселов, вам придется изменять каждое употребление значения 550 в коде. Лучше в самом начале задать переменной под названием screenRightSide значение 550 и использовать эту переменную на протяжении всей программы;
хорошая организация – хороший программист, несомненно, должен уметь организовывать различные элементы программы. Например, функции следует помещать не в разные кадры, а в один кадр вашего ролика. Кроме этого, старайтесь сгруппировать функции согласно выполняемым ими задачам.
Отладка
Всем программистам приходится отлаживать создаваемые ими программы. Невозможно добиться безупречной работы программы при ее первом запуске. Хороший специалист должен уметь отлаживать программу.
Помимо использования отладчика ActionScript, отладку можно производить различными способами. При пробном воспроизведении ролика в окне Output могут появляться сообщения об ошибках. Иногда этого достаточно, чтобы вы поняли, в каком месте кода у вас проблемы 10 .
Информация о программе может также размещаться в окне Output при помощи команды trace. Она поможет вам отследить определенные моменты программы и значение некоторых переменных в эти моменты.
Если же вы хотите воспользоваться программой отладки, советуем вам изучить соответствующую информацию в руководстве по Flash MX. Программа отладки является простым инструментом, позволяющим отображать значения переменных во время воспроизведения Flash‑ролика. Однако она не в состоянии творить чудеса; программа отладки может только помочь вам разобраться в собственном проекте.
С приобретением опыта программист вырабатывает собственные правила и стиль. При этом совершенно не обязательно наступать на все грабли самому. Разумное следование приведенным ниже рекомендациям поможет избежать многих распространенных ошибок. Конечно, на все случаи жизни советы дать невозможно, ведь не зря многие считают программирование искусством.
Главная цель, к которой нужно стремиться, - получить легко читаемую программу, возможно, более простой структуры. В конечном счете, все технологии программирования направлены на достижение именно этой цели, поскольку только так можно добиться надежности программы и легкости ее модификации.
· Программа должна состоять из максимально обособленных частей, связанных друг с другом только через интерфейсы.. Следует четко отделять интерфейс подпрограммы или модуля от их реализации и ограничивать доступ к информации, ненужной для их использования.
· Каждое законченное действие оформляется в виде подпрограммы.. Размер подпрограммы может быть разным, это зависит от конкретного действия, но желательно, чтобы ее тело помещалось на один-два экрана: одинаково сложно разбираться в программе, содержащей несколько необъятных функций, и в россыпи из сотен подпрограмм по несколько строк каждая. Если какая-либо последовательность операторов используется хотя бы дважды, ее также нужно оформить в виде подпрограммы.
· Все величины, которыми подпрограмма обменивается с вызывающей программой, должны передаваться ей через параметры. Входные параметры предпочтительнее передавать как константы. Обычно в списке параметров сначала записывают все входные параметры, а затем - все выходные. Если подпрограмма возвращает одно значение, лучше оформить ее в виде функции, если несколько - в виде процедуры.
· В подпрограмме полезно предусматривать реакцию на неверные входные параметры и аварийное завершение. Это может быть или печать сообщения, или, что более предпочтительно, формирование признака результата. Этот признак необходимо анализировать в вызывающей программе. Сообщение об ошибке должно быть информативным и подсказывать пользователю, как ее исправить. Например, при вводе неверного значения в сообщении должен быть указан допустимый диапазон.
· Величины, используемые только в подпрограмме, следует описывать внутри нее как локальные переменные. Это упрощает отладку программы. Использовать глобальные переменные в подпрограммах нежелательно, потому что их изменение трудно отследить.
· Имена переменных должны отражать их смысл. Правильно выбранные имена могут сделать программу в некоторой степени самодокументированной. Неудачные имена, наоборот, служат источником проблем. Сокращения ухудшают читаемость, и часто можно забыть, как именно было сокращено то или иное слово. Общая тенденция состоит в том, что чем больше область видимости переменной, тем более длинное у нее имя. Перед таким именем можно поставить префикс типа (одну или несколько букв, по которым можно определить тип переменной). Для счетчиков коротких циклов, напротив, лучше обойтись однобуквенными именами типа i или k.
· Следует избегать использования в программе чисел в явном виде. Константы должны иметь осмысленные имена, заданные в разделе описания const. Символическое имя делает программу более понятной, а, кроме того, при необходимости изменить значение константы потребуется изменить программу только в одном месте. Конечно, этот совет не относится к константам 0 и 1.
· Для записи каждого фрагмента алгоритма необходимо использовать наиболее подходящие средства языка. Например, ветвление на несколько направлений по значению целой переменной более красиво записывается с помощью оператора case, а не нескольких if. Для просмотра массива лучше пользоваться циклом for. Оператор goto применяют весьма редко, например. для принудительного выхода из нескольких вложенных циклов, а в большинстве других ситуаций лучше использовать другие средства языка, такие как процедуры break или exit.
· Программа должна быть «прозрачна». Если какое-либо действие можно запрограммировать разными способами, то предпочтение должно отдаваться не наиболее компактному и даже не наиболее эффективному, а такому, который легче для понимания. Особенно это важно тогда, когда пишут программу одни, а сопровождают другие, что является широко распространенной практикой. «Непрозрачное» программирование может повлечь огромные затраты на поиск ошибок при отладке.
· Не следует размещать в одной строке много операторов. Как и в русском языке, после знаков препинания должны использоваться пробелы:
· Вложенные блоки должны иметь отступ в 3-4 символа, причем блоки одного уровня вложенности должны быть выровнены по вертикали. Форматируйте текст по столбцам везде, где это возможно.
· Помечайте конец длинного составного оператора.
· Для организации циклов пользуйтесь наиболее подходящим оператором. Цикл repeat применяется только в тех случаях, когда тело непременно потребуется выполнить хотя бы один раз, например при проверке ввода. Цикл for используется, если число повторений известно заранее и параметр имеет порядковый тип, цикл while - во всех остальных случаях. При записи итерационных циклов (в которых для проверки условия выхода используются соотношения переменных, формируемых в теле цикла) необходимо предусматривать аварийный выход по достижении заранее заданного максимального количества итераций. Чтобы цикл легче читался, надо стремиться объединять инициализацию, проверку условия выхода и приращение в одном месте.
Несколько советов по записи операторов ветвления:
· Более короткую ветвь if лучше поместить сверху, иначе вся управляющая структура может не поместиться на экране, что затруднит отладку.
· Бессмысленно использовать проверку на равенство true или false.
· Следует избегать лишних проверок условий.
· Если первая ветвь оператора if содержит передачу управления, использовать else нет необходимости:
if i > 0 then exit; { здесь i <= 0 }
· Необходимо предусматривать печать сообщений в тех точках программы, куда управление при нормальной работе программы передаваться не должно.
- Перед началом каких-либо операций проверьте существование всех нужных файлов, папок и переменных. Например, если файл не будет найден, то вы его сможете создать и избавиться от ошибок.
- Проверяйте все входные данные, которые передаются по форме. Например, если в переменной должна прийти дата - проверьте являются ли пришедшие данные датой. Даже если в форме предлагается выбор этих самых дат. Помните, форму всегда можно сохранить локально и поправить ее на свое усмотрение.
- Проверяйте входные данные, чтоб они были только в пределах диапазона, указанного вами. Например, если вы поставили ограничение на 1000 символов в сообщении, а вам написали 2000.
- Длина слов и другие, так как в простую форму можно вести очень много символов, из которых вам нужно будет всего лишь 3-4 десятка с начала, то на форму лучше всего тоже поставить ограничение.
- Длина слов и другое. Если ввести слов 20 без пробела, то на странице это будет выглядеть некрасиво, а вам это не надо, поэтому либо запрещайте ввод таких длинных слов, либо разделяйте длинные слова самостоятельно, либо укорачивайте слова и другое
- Вы знаете, что в поле имени (скрипты: гостевые книги, форумы…) пользователь может ввести что угодно, в том числе и ваше имя. Но так как в интернете не все честные, то некоторые, подписавшиеся вашим именем могут наговорить много всего нехорошего. Чтобы подобного не произошло, создайте список с запрещенными именами и проверяйте не совпадает ли имя пользователя с именем из этого списка.
- Никогда не показывайте в форме пароля его текущее значение. Помните о том, что в этом случае пароль может попасть остаться в компьютере в так называемом каталоге временных файлов Интернета. А если это общественный компьютер? Тогда следующий кто сядет за него может легко узнать пароль. Кроме того форму с паролями обязательно отправляйте по методу POST.
- В вашем скрипте обязательно должно быть предусмотрено модерирование. Согласитесь, гораздо проще и удобнее зайти на сайт, зайти в на страницу модерирования и нажать на пару кнопок и заполнить пару форм, чем заходить по FTP на сайт, открывать нужную страницу и ковыряться в HTML коде.
- Кавычки. Заменяйте в получаемых данных все кавычки на ESCAPE - последовательность. Например, кавычку ["] на [\"]. Данные в форму можно ввести так, что при отображении может много чего натворить с вашей страницей. Например, можно вставить скрипт на Java, изменить оформление. Кроме того если это у вас форум или гостевая, можно заменять два пробела на пробел, для того чтоб количество пробелов отображалось верное.
- Храните пароли в закодированном виде. Ведь если какой-нибудь пользователь и сумеет скопировать себе этот файл с паролями, то он пароль не сможет расшифровать. Если пользователь забыл пароль - меняйте его на абракадабру и отправляйте на Email. При этом обязательно выдавайте вначале ссылку для подтверждения, чтобы никто не узнал пароль.
- Всегда заменяйте метки и разделители, которые вы используете для сохранения информации или отображения, на что-то подобное. Иначе имеется какой-то шанс, что его пользователь введет в форму ваш разделитель и на странице появится целый список ошибок.
- Никогда не забываете ставить error_reporting (0) в начало страницы, благодаря этому параметру все ошибки, если они будут, не будут отображаться на странице и злоумышленник не сможет узнать слабое место в вашем скрипте.
- При подгрузке какого-нибудь файла сначала удостоверьтесь в его существовании, а если он и вправду существует, то подгружайте его с помощью функции require, а не include, потому что в 1 случае если будет ошибка то файл совсем не будет подгружаться, а во 2 он подгрузится с ошибками.
- Проверяйте откуда пользователь пришел. Потому что пользователь может сохранить форму ввода у себя на компьютере и подправить ее, но если он попытается отправить через нее данные, то ничего не получится, так как он его запрос придет не с той страницы, с которой нужно.
Уроки, извлечённые из опыта разработки программного обеспечения. Хоть список правил больше касается разработки ПО, это будет полезно почитать каждому новичку.
Разработка
1. Начинайте с небольших вещей, затем расширяйте их.
Как при создании чего-то нового, так и при добавлении функциональности к готовым системам, я всегда начинаю с очень простой версии, которая не делает почти ничего из необходимых функций. Затем я расширяю это решение шаг за шагом, до тех пор пока оно не станет тем, что было заявлено изначально. У меня ещё никогда не получалось расписать в плане все детали уже на старте. Вместо этого, я всё лучше и лучше понимаю то, что нужно получить в процессе разработки и использую эти знания в проекте.
Мне нравятся эти слова Джона Галла: «Любая достаточно сложная система, которая работает, так или иначе в своё время эволюционировала из простой системы, которая работала».
2. Изменяйте что-то одно за один раз.
Если при разработке программа начинает проваливаться на каком-то тесте или некоторая функция перестаёт работать, то гораздо проще найти причину, если вы поменял код только в одном месте. Другими словами, лучше использовать небольшие итерации, чем пытаться сделать всё и сразу. Сделайте что-то одно, убедитесь, что это работает, повторите.
Это также применимо и на уровне коммитов в систему контроля версий. Если вам надо провести рефакторинг, то прежде чем добавить какую-то новую фичу, сначала зафиксируйте изменения для рефакторинга, а только потом (отдельным коммитом) добавьте эту фичу.
3. Добавляйте логирование и обработку ошибок на ранних стадиях.
Когда я принимаюсь за разработку новой системы, одна из первых вещей, которую я делаю — это добавление логирования и обработки ошибок. Обе эти вещи приносят пользу с самого начала работы над проектом. В любой программе, которая больше пары десятков строк кода, вам нужно знать, что происходит в процессе выполнения. И особенно эти данные важны тогда, когда что-то работает не так, как было запланировано.
Примерно то же самое и с обработкой ошибок — раз уж исключений всё равно не избежать, и они будут кидаться на протяжении всей жизни проекта, то почему бы не начать обрабатывать их систематически уже в самом начале?
4. Каждая новая строчка кода должна быть выполнена хотя бы один раз.
Прежде чем закончить работу по какой-либо функциональной возможности, её нужно протестировать. Ведь иначе как вы поймете, что она делает именно то, что должна? Часто лучший вариант для этого — автоматические тесты, хотя бывают и другие варианты. В целом не важно как, но главное, что управление должна получить каждая написанная вами строчка кода.
Иногда может быть сложно воспроизвести нужные условия, чтобы зайти во все ветки кода. К счастью, у вас есть возможность немного смухлевать, не обязательно стараться воспроизводить полностью боевые условия. К примеру, отлов ошибок базы данных можно проверить специально допустив ошибку в написании названия колонки. Или можно временно инвертировать условие внутри if, тогда случай «ошибка произошла» поменяется местами со «всё прошло корректно». Это полезно для ошибок, которые в принципе происходят очень редко и их сложно сымитировать.
Иногда мне попадаются баги, которые показывают, что определённая строчка кода вообще никогда не должна работать. Она может выглядеть вполне нормально внешне, во время code-review, но всё равно не работать так, как должна. Вы избежите таких ситуаций, если примете за правило всегда выполнять хотя бы один раз каждую новую строку.
5. Тестируйте по частям прежде, чем проверять весь проект на работоспособность.
Чем тщательнее вы протестируете отдельные составляющие, тем больше времени сэкономите. Часто можно столкнуться с проблемой наладки взаимодействия между отдельными компонентами. И если вы будете уверены в том, что каждый из них работает корректно, вы сможете уделить достаточное время решению этой задачи.
6. Абсолютно всё занимает больше времени, чем вы думаете.
Особенно в программировании. Оценить, сколько времени уйдет на реализацию той или иной задачи, действительно трудно, даже если всё идет гладко. Но когда речь идет о разработке ПО, необходимо брать в расчет тот факт, что могут возникнуть неожиданные проблемы: в самое простое слияние может закрасться баг, обновление фреймворка вызовет необходимость изменить некоторые функции, или вызов API даст непредсказуемый или неверный результат.
Похоже старик Хофштадтер был прав, когда формулировал свой закон: «На любое дело требуется больше времени, чем казалось в начале, даже если вы учитывали при этом закон Хофштадтера».
7. Сначала поймите, что делает данный код.
В большинстве своем программирование подразумевает изменение существующего кода. Даже если вы включили в проект нечто совершенно новое, это новое должно стать частью написанного кода. Более того, необходимо понять найденное решение прежде, чем добавлять его. Иначе вы можете нарушить работоспособность чего-то, что уже было реализовано. Поэтому умение читать код так же важно, как умение его писать. И это еще одна причина, почему вроде бы простая задача по встраиванию кода может занять больше времени, чем кажется: нужно понимать контекст, в котором происходят изменения.
8. Читайте и запускайте код.
К счастью, есть два метода понимания кода, которые отлично дополняют друг друга. Вы можете читать код и вы можете смотреть, что происходит когда он выполняется. Запуск на исполнение может неплохо вам помочь в понимании того, для чего этот код был написан. Но убедитесь, что вы используете оба подхода.
Отладка
9. Ошибки будут всегда.
Мне не очень нравится подход «Сделать всё с первого раза». Не имеет значения, сколько усилий вы потратите, ошибки будут всё равно («Мы об этом не подумали…»). Гораздо продуктивней запустить приложение и исправлять баги по мере поступления.
10. Реагируйте на отчеты об ошибках.
Каждый разработчик должен тратить часть своего времени на разбор отчетов об ошибках и их исправление. Это даёт более глубокое понимание того, как работает система, чего от нее ждут клиенты, насколько сложно поддерживать систему. Кроме того, это отличный способ почувствовать ответственность за свою разработку. Не упускайте эту возможность.
11. Воспроизводите проблему.
Первым шагом по исправлению любого бага должно быть вопроизведение ошибки. Тогда вы можете быть уверены, что, когда вы исправите программу, ошибка исчезнет. Это простое правило поможет вам избежать ситуации, когда вы предполагаете проблему там, где ее нет, и убедиться, что решение будет работать.
12. Исправьте известные ошибки и смотрите, что останется.
Иногда есть некоторое количество проблем, о которых вы знаете. Различные ошибки могут взаимодействовать друг с другом и вызывать странное поведение. Вместо того, чтобы искать причину такого поведения, исправьте известные ошибки и проверьте, остались ли симптомы.
13. Совпадений не бывает.
Не верьте в совпадения, когда занимаетесь тестированием или отладкой. Вы поменяли значение таймера, и система стала перезагружаться чаще? Это не совпадение. Вы добавили новую функциональность, и другая функция стала работать медленнее? Исследуйте!
14. Учитывайте временны́е метки.
Используйте их при отладке, смотрите на взаимосвязь.К примеру, если примерно за 3000 мс до того, как система перезапустилась, был отправлен запрос, возможно таймер запустил какие-либо действия, которые привели к перезапуску.
Сотрудничество
Живой диалог не заменят видеоконференции, чат, звонок или электронная почта. Удивительно, насколько лучше становятся идеи и решения, если обсудить их с коллегами.
16. Резиновый утенок.
Если вы столкнулись с затруднениями, вы можете пойти к коллеге и рассказать ему о своей проблеме. Чаще всего, в процессе объяснения, вы сами придете к решению, даже если коллега не сказал ни слова. Звучит как магия, но работает достаточно часто.
17. Спрашивайте.
Чтение и запуск кода — отличный способ понять, как он работает. Но если у вас есть возможность спросить кого-нибудь компетентного (автора программы, к примеру), используйте её. Возможность задать вопрос и получить на него ответ, а затем, исходя из ответа задать дополнительные вопросы, позволит вам получить информацию за несколько минут вместо нескольких дней.
18. Признавайте заслуги других.
Говорите, напимер: «Маркусу пришла в голову замечательная идея …», вместо: «мы попробовали …». Старайтесь упомянуть всех, кто вам помог.
Разное
19. Экспериментируйте.
Если вы не уверены, как работает та или иная особенность языка, вы можете просто написать маленькую программу, которая продемонстрирует это на примере. Тот же самый метод применим и когда вы тестируете сложную систему. Что случится, если я передам -1 в качестве аргумента? А не упадет ли сервис, когда я перезагружу машину? Исследуйте, как что работает — вы наверняка обнаружите какие-то ошибки, и кроме того, глубже поймете систему.
20. Поспите.
Если вы работаете над сложной задачей или столкнулись с проблемой, попробуйте поспать, прежде чем принимать решение. Ваше подсознание все равно работает над решением, даже если вы не думаете о нём. В итоге, на утро вы легко найдете ответ, который покажется вам очевидным.
21. Меняйтесь.
Не бойтесь пробовать себя на разных ролях время от времени. Работа с разными людьми, разными продуктами, в разных компаниях стимулирует. Многие люди год за годом сидят на одной и той же работе, изменяя что-то в своей жизни только под влиянием внешних обстоятельств.
22. Учитесь.
Самая лучшая особенность ИТ — всегда есть, куда расти, есть, чему учиться. Пробуйте разные языки и инструменты, читайте книги, проходите онлайн-курсы. Маленькие улучшения, накапливаясь, значительно укрепят ваши навыки.