1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ
1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ
Стандарты давно используются в технике и программировании. Создание сложной системы немыслимо без стандартов. Они нужны для борьбы с хаосом и неразберихой, но вместе с этим стандарт не должен быть слишком «узким» и мешать техническому прогрессу.
Государственные стандарты отслеживают тенденции развития программирования и дают обязательные рекомендации по их соблюдению. Помимо государственных стандартов (ГОСТ) действуют отраслевые стандарты (ОСТ), стандарты предприятий (СТП).
Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.
Помимо вышеизложенных стандартов де-юре имеются стандарты де-факто. Ряд стандартов устанавливается де-факто ведущими фирмами-разработчиками программ и вычислительной техники. Стандарты де-факто появляются на основе идей какой-то широко известной разработки. Выгодно делать продукты в стиле разработки какой-то фирмы, так как пользователи уже имеют навыки работы с меню в стиле «Lotus», электронными таблицами, текстовыми редакторами. Обычно стандартом де-факто определяются используемые операционные системы, трансляторы с языков программирования, организация файлов и средний уровень качества, достигаемый по окончании тестирования программ. Конкретному разработчику выгодно следовать таким стандартам.
В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.
К сожалению, самое благородное дело стандартизации — достижение всеобщей унификации и взаимозаменяемости — может также стать тормозом развития. Вводя новый стандарт, надо учитывать последствия ввода, особенно если стандарт является опережающим и опережает практику развития или если стандарт является слишком «узким» и тормозит эволюцию прогресса. Во всем мире руководствуются следующим отношением к стандартам: или полностью им следуй, или делай свой собственный стандарт. Стандарты дают дополнительные ограничения.
Программист должен уметь не только использовать готовые стандарты, но и разрабатывать новые. Так, например, правила однотипного оформления исходного текста программы определяются стандартом проекта, который может быть изменен при начале разработки нового проекта. Однако в течение выполнения одного проекта оформление всех частей программы должно быть однотипным. Поэтому зачастую перед началом нового проекта конкретным программистам следует разрабатывать свои стандарты, которые не нарушают ГОСТ, ОСТ и СТП и действуют в пределах конкретного проекта.
Читайте также
Основные стандарты
Основные стандарты UNIX явилась первой действительно переносимой системой, и в этом одна из причин ее успеха.Как в ранние, бесплатно распространяемые, исследовательские версии, так и в сегодняшние коммерческие и свободно распространяемые версии UNIX постоянно вносятся
1.10. Стандарты Unix
1.10. Стандарты Unix Когда писалась эта книга, наибольший интерес в сфере стандартизации Unix вызывала деятельность группы Остина по пересмотру общих стандартов (The Austin Common Standards Revision Group, CSRG). Ими было написано в общей сложности около 4000 страниц спецификаций, описывающих более
Битва за стандарты
Битва за стандарты Как следует из предшествующего изложения, со временем различия между клонами UNIX становились все более значительными. Во-первых, в основе существовавших её вариантов лежали разные базовые системы – SVR3, SVR4, 4BSD.Во-вторых, каждый разработчик считал своим
B.5 Стандарты RFC
B.5 Стандарты RFC В документе RFC периодически публикуется официальный список стандартов и их текущий статус. Этот список является самостоятельным стандартом (STD 1). Информация в таблицах от B.1 до B.5 была взята из RFC 1920, опубликованного в марте 1996 г. и отражающего статус и
17.1.2. Стандарты С
17.1.2. Стандарты С Разработка стандартов С была консервативным процессом, в котором серьезное внимание уделялось «сохранению духа» оригинального С, а акцент был сделан скорее на утверждении экспериментов в существующих компиляторах, чем на создании новых функций.
17.1.2. Стандарты С
17.1.2. Стандарты С Разработка стандартов С была консервативным процессом, в котором серьезное внимание уделялось «сохранению духа» оригинального С, а акцент был сделан скорее на утверждении экспериментов в существующих компиляторах, чем на создании новых функций.
STL и Стандарты
STL и Стандарты В книге я часто ссылаюсь на Стандарт С++, потому что основное внимание уделяется переносимой, стандартной версии С++. Теоретически все примеры, приведенные в книге, должны работать во всех реализациях С++. К сожалению, на практике это не так. Вследствие
Firebird и стандарты
Соглашения и стандарты.
Соглашения и стандарты. В настоящий момент к PGP относятся два зарегистрированных документа Интернет: RFC 1991 («Формат обмена сообщениями PGP») и RFC 2015 («Обеспечение безопасности MIME с помощью PGP», определяющий формат PGP/MIME).Введение новых алгоритмов и возможностей в PGP 5.x
Стандарты Wi-Fi
Стандарты Wi-Fi Сегодня используются три стандарта беспроводных сетей: IEEE 802.11b, 802.11a и 802.11g. Современные ноутбуки чаще всего оснащаются поддержкой всех стандартов.802.11b – первый стандарт беспроводных сетей, поэтому он является самым медленным (скорость до 11 Мбит/с). Стандарты
Стандарты кодирования
Сетевые стандарты
Сетевые стандарты Локальная сеть состоит из огромного количества компонентов. Это компьютер и сетевая операционная система; сетевая карта; концентраторы, маршрутизаторы и т. п.; программное обеспечение компьютера, работающее с сетевой картой. Требования к компонентам
Стандарты и совместимость
Стандарты и совместимость Лазерные носители информации, работающие с ними приводы описаны множеством стандартов и спецификаций, а также их модификаций, расширений и дополнений. Пока пользователь записывает и читает диски на конкретном приводе отдельно взятого
Региональные стандарты
Стандарт оформления кода
Содержание
Применение
Образцом для стандарта кодирования может стать набор соглашений, принятых в какой-либо распространённой печатной работе по языку (например, стандарт кодирования на языке Си, получивший сокращённое наименование K&R, происходит из классического описания Си его авторами — Кернинганом и Ричи), широко применяемая библиотека или API (так, на распространение венгерской нотации явно повлияло её использование в MS-DOS и Windows API, а большинство стандартов кодирования для Delphi используют, в той или иной мере, манеру кодирования библиотеки VCL). Реже разработчик языка выпускает подробные рекомендации по кодированию. Например, выпущены стандарты кодирования на C# от Microsoft и на Java от Sun. Предложенная разработчиком или принятая в общеизвестных источниках манера кодирования в большей или меньшей степени дополняется и уточняется в корпоративных стандартах.
Состав
Стандарт сильно зависит от используемого языка программирования. Например, стандарт оформления кода для языка Си будет серьёзно отличаться от стандарта для языка BASIC. В целом, исходя из назначения стандарта, обычно он имеет целью добиться такого положения, когда программист достаточной квалификации мог бы дать заключение о функции, выполняемой конкретным участком кода, а в идеале — также определить его корректность, изучив только сам этот участок кода или, во всяком случае, минимально изучив другие части программы. Иными словами, смысл кода должен быть виден из самого кода, без необходимости изучать контекст. Поэтому стандарт кодирования обычно строится так, чтобы за счёт определённого визуального оформления элементов программы повысить информативность кода для человека.
Обычно, стандарт оформления кода описывает:
Вне стандарта подразумевается:
Стандарты кодирования и синтаксис языков
Для чего нужны стандарты при написании программ
Многие программисты в своей работе так или иначе сталкиваются с различными стандартами. Хотя многие, в данном случае, вовсе не подразумевает большинство, потому что, к сожалению, на просторах бывшего СССР стандарты даже для оформления исходного кода скорее экзотика нежели правило.
Что представляют собой стандарты в программировании? Зачем их вводят солидные компании и даже open source сообщества? И почему их всё-таки лучше вводить и придерживаться?
Что включает в себя стандарт в программировании
Говоря о стандартах в сфере разработки программного обеспечения следует чётко различать четыре категории:
Стандарты первой категории устанавливаются государством и компетентными международными организациями.
Стандарты последней категории влияют на разработку за счёт того, что помимо всего прочего регламентируют такие документы как техническое задание, а также программа и методика приёмо-сдаточных испытаний. Однако сам процесс разработки как таковой они не затрагивают.
Так как написание и оформление программного кода в настоящий момент находится в ведении самих программистов, мы поговорим о стандартах, которые относятся ко второй и третьей категориям.
Что регламентируют они? Да, практически всё что угодно их составителям.
Начиная с банальных правил именования переменных и отступов от начала строки. Заканчивая архитектурой приложения.
Есть небольшие стандарты, которые регулируют лишь некоторые вопросы (в основном самые общие). А, есть и целые комплексы, которые покрывают программную систему целиком.
Причём и то, и другое является уделом не только крупных коммерческих организаций. Например, сообщество разработчиков CMS WordPress сформировало так называемый «Кодекс WordPress». Свод стандартов, регламентирующих почти все вопросы разработки для этой CMS.
Для чего нужны стандарты в программировании
Первая цель которую преследует стандартизация, это приведение рабочего процесса к некоторому «общему знаменателю». Разрабатывать программу гораздо проще если общие вопросы оговорены изначально. Также в исходном коде значительно легче разобраться, когда он оформлен единообразно.
Вторая задача, которую могут решить стандарты, это предотвращение грубых ошибок путём исключения из практики программирования в рамках стандарта тех или иных потенциально опасных приёмов.
В качестве примера, можно привести CMS WordPress. Плагин содержащий форму отправки данных не пройдёт code review при публикации, если форма не имеет специальных скрытых полей, которые подтверждают, что данные отправлены с «правильной» станицы.
Поэтому, стандарты играют важную роль не только в совершенствовании рабочего процесса, но и обеспечении надёжности работы программы.
Соблюдать стандарты или нет
Ответ на это вопрос напрямую зависит лот контекста.
Если речь идёт о стандартах Вашей компании или сообщества разработчиков, то здесь выбор безусловно не богат…
Однако даже если вы просто пишите код для себя или в рамках фриланс проекта, лучше всё-таки хотя бы выработать некоторые личные стандарты для разработки. Если вы грамотно выстраиваете архитектуру приложения и качественно оформляете код, это не только упростит вам процесс работы, но и даст понять потенциальному работодателю и заказчику что перед ним на самом деле профессионал.
Правда, даже те программисты, которые не ищут работу, со временем либо принимают уже сформированные кем-либо стандарты, либо вырабатывают собственные на основе своего опыта. Таким образом формируется так называемый «code style».
Конечно, в подобных вопросах последнее слово всегда за конкретным разработчиком или руководителем. Только банальное нежелание потратить немного времени на решение ключевых вопросов чаще всего приводит к огромным потерям времени и денег за счёт дополнительных затрат на разработку и сопровождение проекта (вникание в неоформленный код, ошибки, антапаттерны и т.д.), который, как это ни странно, при лучшем качестве мог бы стоить гораздо дешевле.
Развитие языков программирования
Парадигмы программирования
Синтаксис языка описывает систему правил написания различных языковых конструкций, а семантика языка программирования определяет смысл этих конструкций. Синтаксис языка программирования может быть описан с помощью НБФ-нотаций.
Код программы на языке системы правил может быть записан следующим образом:
В настоящий момент наибольшее распространение получили языки, основанные на объектно-ориентированной модели. Они, реализуя процедурную модель построения языка, поддерживают аппликативность конструкций, позволяя представлять блок-схему выполнения структурированной программы как некоторый набор аппликативных функций.
Стандартизация языков программирования
Концепция языка программирования неотрывно связана с его реализацией. Для того чтобы компиляция одной и той же программы различными компиляторами всегда давала одинаковый результат, разрабатываются стандарты языков программирования. Существует ряд организаций, целенаправленно занимающихся вопросами стандартизации. Это Американский национальный институт стандартов ANSI (American National Standards Institute), Институт инженеров по электротехнике и электронике IEEE (Institute of Electrical and Electronic Engineers ), Организация международных стандартов ISO ( International Organization for Standardization ).
Как правило, при создании языка выпускается частный стандарт, определяемый разработчиками языка. Если язык получает широкое распространение, то со временем появляются различные версии компиляторов, которые не точно следуют частному стандарту. В большинстве случаев идет расширение зафиксированных первоначально возможностей языка. Для приведения наиболее популярных реализаций языка в соответствие друг с другом разрабатывается согласительный стандарт. Очень важным фактором стандартизации языка программирования является своевременность появления стандарта – до широкого распространения языка и создания множества несовместимых реализаций. В процессе развития языка могут появляться новые стандарты, отражающие современные нововведения. Так, язык FORTRAN первоначально был стандартизирован в 1966 году. В результате был издан стандарт FORTRAN 66. Далее этот стандарт несколько раз пересматривался (в 1977 году был выпущен FORTRAN 77, затем появился и FORTRAN 90).
Среда проектирования
С развитием языков программирования совершенствовались и средства разработки программ – от режима командной строки до интегрированной среды проектирования. Такая среда предоставляет удобный графический интерфейс разработки и большой спектр сервисов, включающих управление версиями хранимых данных, утилиты просмотра и управления информацией, библиотеки классов, мастера создания шаблонов приложений и т.п.
Интегрированная среда проектирования VisualStudio. NET позволяет создавать и компилировать приложения на языках C++, C#, Visual Basic и VisualJ. Для разработки приложений на языке С++ предназначается также среда CBuilder.
Для проектирования приложений на языке Object Pascal используется интегрированная среда проектирования Delphi.
Наиболее удобной средой разработки программ на языке Java является интегрированная среда проектирования JBuilder.
Структура языка программирования
Содержание
Дополнительно
Согласованные, высококачественные стандарты программирования повышают качество программного обеспечения, сокращают время его разработки, способствуют командной работе, снижают затраты времени на решение несущественных вопросов и облегчают сопровождение программ.
1. Оформление кода
1.1. Лесенка в 4 или 8 пробелов
Обязательна «лесенка» с отступом в 4 пробела (half-tab) или 8 пробелов (tab). При этом запрещается в редакторе изменять размер отображаемой табуляции, например выставлять отображение табуляции в 4 символа. Код, созданный Вами при таких настройках, будет некорректно отображаться в других редакторах с другими настройками.
1.2. Пробелы после запятых
После запятых и точек с запятой (если, конечно, они не расположены в конце строки) ставятся пробелы. Перед запятой и точкой с запятой пробелы не ставятся:
1.3. Пробелы вокруг знаков операций
Любые операторы / знаки операций ( например «=», «==», «=>», » «, «&&», «||» и т.п.) отделяются пробелами с обоих сторон
В арифметических выражениях количество пробелов вокруг знаков операций можно варьировать, чтобы подчеркнуть приоритет операций. Примеры:
1.4. Пробелы вокруг сложных индексных выражений
В случае, если Вы обращаетесь к элементу массива или хэша по индексу и индексное выражение достаточно сложное, отделяйте его пробелами для улучшения удобочитаемости. Если выражение простое — пробелы не обязательны.
1.5. Пробелы после знака комментария
После символа начала комментария («//») перед текстом самого комментария ставится пробел.
1.6. «Опять пробелы. »
Для того, чтобы понять, насколько хорошо отформатирован Ваш исходный текст: достаточно ли отступов, пробелов и пустых строк — попробуйте отключить подсветку синтаксиса в Вашем редакторе. Если после отключения подсветки код по-прежнему легко читаем (просмотр и анализ текста производится легко, любые конструкции легко выделяются визуально) — значит код действительно удобочитаем.
Не стоит полагаться на подсветку синтаксиса как на «костыль», скрывающий недостатки форматирования.
1.7. Выравнивайте комментарии точно так же, как и код
Левый край комментариев выравнивается точно так же, как и основной код, т.е. используется принцип «лесенки».
Ставить символы «//» вначале строки, если левая граница кода находится правее, не допускается.
1.8. Максимальная длина строк. Разбиение длинных строк.
Строки желательно не оставлять слишком длинными; условное ограничение — 80-100-120 символов в строке. При необходимости строка разбивается на несколько.
Примеры допустимого разбивания конструкций:
1.9. Открывающая фигурная скобка на той же строке, что и ключевое слово
Старайтесь придерживаться компактного (K&R) стиля оформления циклов и блоков ветвления: открывающая фигурная скобка находится на той же строке, что и ключевое слово «for», «if», «else», «while» и т.п.
Закрывающая фигурная скобка блока, состоящего из нескольких строк, должна находиться на одной вертикали с ключевым словом начинающим конструкцию.
Примеры:
1.10. Пробел перед открывающей фигурной скобкой
Перед открывающей фигурной скобкой в блочных конструкциях ставится пробел:
if (condition) <
statement;
>
1.11. Допускается компактное оформление блоков из одного оператора
Однострочные блоки, состоящие из единственного оператора, могут быть помещены в одну строку вместе с открывающими и закрывающими скобками:
1.14. Разбивайте код на абзацы, при необходимости снабжённые комментариями
Код внутри функций должен быть разделён на смысловые блоки, выполняющие определённую узкую задачу. Смысловые блоки отделяются друг от друга пустыми строками. Для дальнейшего улучшения сопровождабельности кода, добавляйте вначале каждого абзаца однострочный комментарий, объясняющий, что делает эта последовательность операторов.
1.15. Выравнивайте сходные элементы кода по вертикали.
Выравнивайте сходные элементы по вертикали, особенно если они достаточно короткие чтоб поместиться в одну строку:
2. Переменные и константы
2.1. Не отделяйте имена переменных и функций от следующей за ними открывающей скобки
Важно ставить открывающую скобку слитно с именем функции или переменной. В противном случае можно визуально спутать функцию с ключевым словом, а начало выражения для элемента массива или хэша со скаляром.
2.2. Осмысленные названия идентификаторов
2.3. Строчные буквы для названий переменных и функций
2.4. Заглавные буквы для констант
Константы именуются только с использованием заглавных букв:
2.5. Именуйте массивы во множественном числе, а скаляры в единственном
3. Функции
3.1. Одна функция выполняет одну задачу
Если функция выполняет несколько разных, слабо связанных друг с другом задач, подумайте о том, чтобы разбить эту функцию на несколько.
3.2. Имена функций являются глаголами
Наименования функций по-возможности должны представлять из себя глагол, например get_domain_name, или chash_my_program.
3.3. Имена private-функций начинаются с подчёркивания
Если в модуле присутствуют функции, предназначенные только для внутреннего использования, которые никогда не будут вызваны за пределами модуля (за исключением случая автоматического тестирования), имеет смысл предварять названия этих private-функций знаком подчёркивания.
3.4. Отступы и комментарии для функций
Функции отделены друг от друга минимум одной пустой строкой. Для каждой функции необходимо краткое однострочное описание того, что она делает:
3.5. Приём входных параметров функций
Параметры принимаются с использованием конструкции:
В случае переменного количества параметров, если количество и смысл последующих параметров может варьироваться в зависимости от значения предыдущих параметров, допускается принимать эти первые по счёту параметры с помощью shift:
3.6. Документирование входных параметров функций
Если аргументы функции нетривиальны (их назначение и набор допустимых значений не очевидны из их названия и контекста), после описания функции добавляется строка пояснения по аргументам. Если какой-либо аргумент может принимать конечное дискретное множество значений — это множество также перечисляется в комментариях. Если используются именованные параметры — все возможные параметры также перечисляются в комментариях, обязательные параметры обозначаются звёздочкой:
3.7. Не более 3-х позиционных параметров у функций
Функция может принимать не более 2-х, максимум 3-х ПОЗИЦИОННЫХ аргументов. При большем количестве аргументов либо проводится рефакторинг с целью уменьшения количества входных параметров, либо используются именованные параметры:
Именованные параметры обязательно документируются (см. п. 2.6)
3.8. Проверка аргументов
В случае использования именованных параметров, если есть как обязательные, так и необязательные параметры, необходимо проверять наличие обязательных параметров. В случае их отсутствия — вызывать исключение с помощью Carp::confess (для получения stack backtrace) или Carp::croak. В случае использования позиционных параметров проверка наличия и корректности переданных аргументов также приветствуется.
3.9. Документирование выходных параметров функций
Если выходные параметры функции не очевидны / нетривиальны, особенно это касается возврата сложных структур данных, желательно их документировать (после описания входных параметров).
3.10. Возврат скаляра или списка, в зависимости от wantarray
Если функция возвращает список значений, но из возвращаемого списка часто может использовать только первое значение, желательно выдавать только первое значение или весь список в зависимости от контекста:
4. Модули
4.1. Наименование моделей в стиле MyModuleName
4.2. Комментарий вначале модуля
Вначале модуля желателен комментарий, описывающий назначение модуля.
4.3. После последней строки модуля обязателен перенос
Последняя строка кода модуля обязательно заканчивается переносом строки.
4.4. use strict; use warnings;
Обязательное включение всех предупреждений и максимальное ужесточение автоматического контроля:
4.5. Динамическая подгрузка тяжёлых опциональных модулей
Если требуется использовать «тяжёлую» библиотеку или модуль (скажем, отъедающую 5 Мб памяти и более), при этом, необходимость в этой библиотеке возникает лишь изредка, при определённых условиях — лучше загружать такой модуль динамически, когда в нём возникает необходимость:
4.6. Не стоит злоупотреблять экспортированием функций
Не стоит экспортировать функции направо и налево без серьёзной необходимости. Во-первых, в этом случае засоряется namespace модулей, а во-вторых голое название функции без квалификатора может ввести в заблуждение: не очевидно, в каком модуле функция определена — это увеличивает время на понимание чужого (да и своего) кода и время на отладку.
Используйте либо название функции с полным квалификатором:
либо используйте ОО-интерфейс в Ваших модулях:
4.7. Don’t use Exporter
Старайтесь не использовать модуль Exporter: во-первых, он слишком тяжёл, во-вторых, злоупотребление экспортированием функций — признак дурного тона (см. п. 3.6). Если уж Вы используете этот модуль, лучше делать это так:
нежели использовать Exporter в виде базового класса:
В первом случае, по крайней мере, расходуется меньше ресурсов (которые не тратятся на создание лишнего предка в цепочке наследования).
5. Регулярные выражения
5.1. Используйте флаг «x» для сложных регулярных выражений
Если вы используете действительно сложное регулярное выражение, используйте модификатор «x» и разделите текст пробелами, чтоб он не выглядел как нагромождение мусора.
5.2. Используйте удобные ограничители для регулярных выражений
Не используйте наклонную черту в качестве ограничителя когда ваше выражение содержит прямые или обратные наклонные черты:
6. Безопасность и надёжность кода
6.1. Осторожное использование вызовов внешних команд
Прямое использование внешних вызовов команд (через «system» или ««») допускается только в особых случаях, при этом, если командная строка формируется внутри кода, необходимо быть абсолютно уверенным, что в командную строку не могут попасть входные переменные и параметры HTTP-запроса (см. п. 4.2).
6.2. Всегда проверяйте коды возврата системных вызовов.
Всегда проверяйте коды возврата системных вызовов. Если ошибка фатальна — вызывайте исключение с помощью die, Carp::confess или Carp::croak, передавая соответствующее сообщение об ошибке. Хорошее сообщение об ошибке должно включать: в каком месте программы возникла проблема, какой системный вызов был произведен, с какими аргументами, и (ОЧЕНЬ ВАЖНО) должно содержать стандартное системное описание ошибки.
Безопасность кода при работе с БД
6.3. Недопущение возможностей для SQL-inject:
Подстановка данных в SQL-запросы ТОЛЬКО через placeholders («?»).
6.4. Минимизация изменений тела запроса
В особых случаях (если необходимо подставить имя поля или название таблицы) допускается подстановка переменных напрямую в тело запроса, при этом должны быть соблюдены два условия:
если подставялется имя таблицы или поля, то оно обязательно заключается в кавычки: `fieldname`,
Вы должны быть АБСОЛЮТНО уверены в том, что значения переменных НЕ извлекается напрямую из входных параметров/переменных HTTP-запроса, а генерируется внутри кода и могут принимать только конечное дискретное множество значений.
Пример:
7. Лаконичность кода
7.1. Сокращённая форма записи, основанная на ||
Приветствуется использование сокращённой формы записи, основанной на применении логического оператора «или». Например:
и тем более лучше, чем
7.2. Сокращённая форма записи, основанная на &&
7.3. Используйте and и or вместо условных конструкций if
В ряде случаях (когда при каком либо условии нужно выполнить всего один оператор) удобнее выполнять условный код с помощью and или or, чем громоздить блоки if:
7.4. Минимизация использования циклов for и обращений к элементам по индексу
Старайтесь избегать использование классического цикла for с целочисленным индексом, везде, где это возможно. В целом, старайтесь минимизировать обращение к элементам массивов по индексам. При обработке элементов списка отдавайте предпочтение циклам foreach, а также функциям, обрабатывающим сразу весь список сразу, таким как grep, map, sort, join, split и т.д.:
Как правило требуется обработка всех элементов массива сразу, а в этом случае удобнее использовать циклы foreach или функции, обрабатывающие массив целиком (см. п 5.4.). В случае использования foreach, grep, map элементы массива при каждой итерации предстают в виде переменной «$_» (или, для циклов foreach, любой другой переменной, какой Вы укажете), с которой работать куда удобнее, чем каждый раз обращаться к элементам массива по индексу.
7.5. Использование лаконичных вариантов функций DBI
Вместо последовательности DBI вызовов prepare / execute для изменения данных предпочтительнее использовать единственный вызов do.
Вместо последовательности DBI вызовов prepare / execute / fetch_* для выборки данных предпочтительнее использовать единственный вызов selectrow_* / selectall_* / selectcol_*.
8.1. Тесты для всех функций / методов
Для каждой новой функции или метода должен быть написан автоматический тест. Лучше — несколько тестов, для проверки реакции на некорректные входные данные. Если Вы вносите серьёзные изменения в функцию и для неё не написаны тесты — создайте их.
Если какие-то чужие тесты у Вас не проходят, то это повод либо поправить исходный код (свой или чужой — не важно), либо тесты, если они не актуальны.
При создании тестов необходимо придерживаться следующих правил:
Все изменения, производимые при работе тестов на Вашей машине (например, изменения в БД), должны откатываться. Т.е. после успешного выполнения любого из тестовых скриптов, различные хранилища и базы должны возвращаться к исходному виду,
Исключение составляют записи в логах — логи откатывать не нужно.
Любые действия, производимые в процессе тестирования, меняющие состояние каких либо систем не должны покидать границ Вашей локальной машины. Т.е. запуск тестов у Вас не должен приводить к каким-либо изменениям во «внешнем мире» (логгирование Ваших операций чтения внешними системами — не в счёт). Например, исходящие письма, вместо отправки их реальным пользователям на реальные адреса в Интернете, должны отправляться на какой-либо тестовый ящик на локальной машине.
Исключение из этого правила составляют модификации, вносимые в специальные ТЕСТОВЫЕ внешние системы (через различные тестовые эккаунты). В тестовых эккаунтах допустимы любые действия, если они не приведут к невозможности дальнейшего использования этого эккаунта для тестирования.
8.2. Рефакторинг
Если код Вам перестаёт нравится: функция слишком сложная и длинная (более 100 строк), слишком много входных и выходных параметров, неудачное название функции и т.п. — делайте рефакторинг. После проведения рефакторинга обязательно запускайте автоматические тесты. Если для функции, над которой Вы работали, тесты не предусмотрены — создайте их.
9. Общие замечания
9.1. Don’t Reinvent Wheel — Не переизобретайте колесо
Не переизобретайте колесо — если подобное колесо уже существует, просто адаптируйте его для своих нужд. Вероятно, для решения данной проблемы уже существует стандартный модуль в дистрибутиве Perl, или модуль из CPAN, или модуль, разработанный другими людьми внутри организации.
9.2. Do not Repeat Youself — не повторяй самого себя
9.3. KISS — Keep It Simple, Stupid
Всегда и везде стОит придерживаться максимально простых решений, как в области архитектуры, так и в области непосредственно кодирования.
Не делайте лишних движений и лишних разработок до тех пор, пока Вам реально не понадобиться подобная функциональность. Возможно, ситуация / требования изменятся и то, что Вы делаете, не понадобиться никогда.
9.4. Не живите с разбитыми окнами
Не оставляйте «разбитые окна» (неудачные конструкции, неверные решения или некачественный текст программы) без внимания. Как только Вы их обнаружите — чините сразу. Часто безошибочные, функциональные системы быстро портились, как только окна начали разбиваться. Не давайте энтропии победить себя.
9.5. Выкладывайте все модули общего назначения в общий доступ
Если создаваемый Вами модуль или группа модулей жёстко не привязаны к разрабатываемой системе, а являются модулями «общего назначения», которые могут быть интересны другим разработчикам, лучше выделять такие модули в отдельные дистрибутивы и выкладывать на CPAN (или хотя бы на собственные домашние странички).
Спросите, Зачем?
Система и основной репозиторий «не захламляются» тем самым модулями общего назначения. В результате в основной системе легче ориентироваться
Подготовка модулей к выкладке в общий доступ неизбежно повышает их качество (как минимум надо создавать документацию и тесты, «выпрямлять» код)
Получаем все преимущества OpenSource (другие люди присылают багрепорты и патчи, способствуя улучшению модулей)
Мы должны не только брать, но и отдавать что-то OpenSource-сообществу, возвращая тем самым свой долг
Приятно раскручивать своё имя в CPAN 
10. SQL, базы данных
10.1. Форматирование SQL-запросов
Запросы длиной более 50 символов (примерно) рекомендуется разбивать на несколько строк, подгоняя текст по горизонтали. Например так:
10.2. Ключевые слова — заглавными буквами
Все ключевые слова SQL записываются заглавными буквами, все наименование таблиц, полей, пользовательских функций — строчными.
10.3. Названия полей и таблиц — строчными буквами
При именовании таблиц и полей не допускается использование заглавных букв. Допускаются только строчные латинские буквы, цифры и знак подчёркивания. Пример: «name_of_the_table».
10.4. Названия таблиц — во множественном числе
Таблицы следует именовать по-английски, во множественном числе. Например: «domains», «users».
10.5. Первичный ключ с именем «id» *
В каждой таблице (за исключением таблиц, где необходимы составные ключи, например таблиц для обеспечения связей многие-ко-многим) обязательно должно быть поле с именем «id» и типом INT, для которого должен быть создан первичный ключ:
Поле для первичного ключа может быть названо по другому и иметь другой тип, но это обязательно обсуждается с другими членами команды и выносится соответствующее обоснование.
10.6. Ссылочные поля — с именем » _id» *
Все поля, использующиеся для связи с другими таблицами по их первичному ключу, именуются как » _id», где » » — имя таблицы в единственном числе. Примеры наименований: domain_id, user_id.
11. Шаблоны Template Toolkit
11.1. Экранирование поставляемых данных во избежание XSS-атак
При подстановке в шаблон данных, передаваемых пользователем (например, переданных ранее через форму на сайте), эти данные обязательно экранируются с помощью фильтра html:
Во избежание атак XSS.
11.2. Пробелы
К оформлению кода внутри шаблонов применяются те же самые требования, что и к оформлению кода на Perl. В частности это касается расстановки пробелов (пробелы вокруг операторов, пробелы после запятых, вокруг сложных индексных выражений и т.п.) Например,
11.3. Лесенка
При использовании логических / блочных конструкций TT данные, внутри блока сдвигаются вправо для улучшения удобочитаемости:
11.4. Проверки на непустоту списков
В случае необходимости отображения списка или таблицы, где строки передаются в виде массива, должна быть проверка на непустоту этого массива и соответствующая адекватная реакция. Например, вместо вывода пустой таблицы или списка лучше вывести пояснительный текст: «Заказы пока отсутствуют» или «Новостей на сегодня нет».
11.5. Шаблон должен интерпретироваться без ошибок, даже если отсутствуют необходимые данные
Шаблон должен интерпретироваться без ошибок даже в случае, если требуемые шаблоном переменные не передаются шаблонизатору. Это означает, что в шаблонах должна быть предусмотрена адекватная защита, на случае, если данные не передаются.
Если при обработке шаблона, в случае отсутствия необходимых данных, возникают фатальные ошибки или предупреждения, это не позволяет применять процедуры автоматического тестирования, проверающие валидность всех шаблонов. В частности валидность шаблона нельзя будет в произвольный момент времени проверить с помощью утилит tpage или ttree.
12. HTML-код
12.1. HTML-код должен соответствовать спецификации XHTML
HTML-код по-возможности должен соответствовать спецификации XHTML 1.1, а это означает, что:
Все элементы должны быть закрыты. Теги, которые не имеют закрывающего тега (например, или
) должны иметь на конце / (например,
).
Булевы атрибуты записываются в развёрнутой форме. Например, следует писать или
Все значения атрибутов обязательно должны быть заключены в двойные кавычки.
Имена тегов и атрибутов должны быть записаны строчными буквами (например, вместо ).
HTML гораздо строже относится к ошибкам в коде; Символы » » и «&» должны быть записаны как и & соответственно.
12.2. Тире всегда записывается как —
Тире всегда записывается как —. Использование дефиса вместо тире не допускается. Более подробно тема раскрыта в параграфе Арт. Лебедева «Тире, минус и дефис, или Черты русской типографики».
12.3. Кавычки-«ёлочки» вместо «английских двойных».
В HTML-документах, создаваемых для русскоянычной аудитории, желательно использовать кавычки-«ёлочки» (символы « и »). В документах, создаваемых для внутреннего использования (внутренняя документация, технические задания, должностные инструкции и т.п.) допускается использование «английских двойных» кавычек.
12.4. Не использовать спецсимволы, записанные в национальной кодировке
Не использовать знаки номера, копирайта, спец-кавычек и т.п., записанные в виде символов в национальной кодировке, скажем cp1251. Далеко не во всех редакторах и операционных системах Ваши символы будут корректно отображаться. Для вставки подобных знаков используются html-entities:
Краткий справочник:
12.5. Для каждого чекбокса должен быть label
12.6. Грамотно используйте табличную форму представления инфрмации
Вначале немного терминологии, касающейся таблиц. Содержимое таблицы организуется в колонки (графы). Таблица состоит из следующих основных элементов: нумерационного и тематического заголовков (номер таблицы и её название), головки (заголовочная часть таблицы), хвоста (вся остальная часть таблицы без головки), боковика (первая слева графа таблицы) и прографки (хвостовая часть таблицы без боковика).
Заполняя таблицу текстовыми или цифровыми данными полезно следовать правилам:
Выносить данные общие для каждого элемента графы в её заголовок, а общие для каждого элемента строки в заголовок боковика.
По возможности употреблять числа не более чем из четырёх значащих цифр. Для этого более многозначные числа следует округлять. Общий множитель следует вынести в заголовок. То же самое нужно сделать и с единицами измерения.
Всегда перед знаком, отделяющим целую часть числа от дробной, должна быть цифра. То есть правильно писать «0.1», но не «.1».
Проставлять вместо отсутствующих данных многоточие «…», «Нет свед.». Если данных в принципе быть не может, то лучше отметить это с помощью тире «—».
Взято отсюда.
13. Система управления версиями
13.1. Одна фича — один коммит
Лучше не объединять несколько разных фич (или несколько разных багфиксов) в одном коммите. Сделал что-то одно — протестировал — закоммитил.
Не нужно бояться, что изменений для одного коммита «слишком мало». Коммит может содержать исправление и 1-й буквы, в этом нет ничего страшного.
Если патчи достаточно малы — проще делать откат и ревизию изменений. То есть производимые Вами изменения легче будет анализировать.
Если Вы «заработались» и у Вас накопилось несколько логически не связыннах изменений, их можно закоммитить выборочно:
13.2. Все скрипты должны иметь установленный exec-флаг
Все скрипты должны иметь установленое свойство svn:exec. Если добавлять скрипты в репозитарий, когда они уже имеют установленные права на исполнение — свойство это выставляется автоматически. Иначе свойство надо выставлять «руками»:
svn propedit
13.3. Чаше заливать свои изменения и получать апдейты
Чем быстрее вы выкладываете изменения (svn commit), тем быстрее их можем протестировать / проконтролировать, найти ошибки, ускоряется обратная связь и, как следствие, разработка вцелом.
Чем чаще вы получаете изменения (svn update), тем меньше вероятность нарваться на конфликт и тем согласованнее будут работа над кодом.