Соглашения о кодировании — это набор руководств для определенного языка программирования , которые рекомендуют стиль программирования , практику и методы для каждого аспекта программы, написанной на этом языке. Эти соглашения обычно охватывают организацию файлов, отступы , комментарии , объявления , операторы , пробелы , соглашения об именовании , практику программирования , принципы программирования , практические правила программирования , архитектурные передовые практики и т. д. Это руководства по структурному качеству программного обеспечения . Программистам настоятельно рекомендуется следовать этим руководствам, чтобы улучшить читаемость исходного кода и упростить обслуживание программного обеспечения . Соглашения о кодировании применимы только к людям, занимающимся сопровождением и рецензированием программного проекта. Соглашения могут быть формализованы в виде документированного набора правил, которым следует вся команда или компания, [1] или могут быть столь же неформальными, как и привычные практики кодирования отдельного человека. Соглашения о кодировании не навязываются компиляторами .
Сокращение расходов на обслуживание программного обеспечения является наиболее часто упоминаемой причиной для следования соглашениям о кодировании. Во вводном разделе о соглашениях о кодировании для языка программирования Java компания Sun Microsystems предлагает следующее обоснование: [2]
Соглашения о коде важны для программистов по ряду причин:
- 40–80 % стоимости жизненного цикла программного обеспечения уходит на обслуживание. [3]
- Практически ни одно программное обеспечение не поддерживается первоначальным автором на протяжении всей его жизни.
- Соглашения о коде улучшают читаемость программного обеспечения, позволяя инженерам быстрее и глубже понимать новый код.
- Если вы отправляете свой исходный код как продукт, вам необходимо убедиться, что он так же хорошо упакован и чист, как и любой другой созданный вами продукт.
Обзор программного обеспечения часто включает чтение исходного кода. Этот тип обзора в первую очередь является деятельностью по обнаружению дефектов . По определению, только первоначальный автор фрагмента кода прочитал исходный файл до того, как код был отправлен на обзор. Код, написанный с использованием последовательных руководств, проще для понимания и усвоения другими рецензентами, что повышает эффективность процесса обнаружения дефектов.
Даже для оригинального автора последовательно закодированное программное обеспечение облегчает поддержку. Нет гарантии, что человек будет помнить точное обоснование того, почему определенный фрагмент кода был написан определенным образом, спустя долгое время после того, как код был изначально написан. Соглашения о кодировании могут помочь. Последовательное использование пробелов улучшает читаемость и сокращает время, необходимое для понимания программного обеспечения.
Там, где соглашения о кодировании были специально разработаны для создания высококачественного кода, а затем были официально приняты, они затем стали стандартами кодирования. Определенные стили, независимо от того, приняты ли они повсеместно, не автоматически создают код хорошего качества.
Сложность — фактор, противоречащий безопасности. [4]
Управление сложностью включает в себя следующий базовый принцип: минимизировать объем кода, написанного во время разработки проекта. Это предотвращает ненужную работу, которая предотвращает ненужные затраты, как на начальном этапе, так и на последующих этапах. Это просто потому, что чем меньше кода, тем меньше работы не только по созданию приложения, но и по его поддержке.
Сложность управляется как на этапе проектирования (как проект архитектурно оформлен), так и на этапе разработки (путем использования более простого кода). Если кодирование остается базовым и простым, то сложность будет минимизирована. Очень часто это означает сохранение кодирования как можно более «физическим» — кодирование очень прямым и не слишком абстрактным способом. Это создает оптимальный код, который легко читать и понимать. Сложности также можно избежать, просто не используя сложные инструменты для простых задач.
Чем сложнее код, тем больше вероятность, что он будет содержать ошибки, тем сложнее их обнаружить и тем больше вероятность наличия скрытых ошибок.
Рефакторинг относится к деятельности по обслуживанию программного обеспечения, при которой исходный код модифицируется для улучшения читаемости или улучшения его структуры. Программное обеспечение часто рефакторится для приведения его в соответствие с заявленными стандартами кодирования команды после его первоначального выпуска. Любое изменение, которое не меняет поведение программного обеспечения, можно считать рефакторингом. Обычные действия по рефакторингу — это изменение имен переменных, переименование методов, перемещение методов или целых классов и разбиение больших методов (или функций ) на более мелкие.
Методологии гибкой разработки программного обеспечения предусматривают регулярный (или даже непрерывный) рефакторинг, что делает его неотъемлемой частью процесса командной разработки программного обеспечения . [5]
Соглашения о кодировании позволяют программистам иметь простые скрипты или программы, чья работа заключается в обработке исходного кода для какой-либо цели, отличной от компиляции его в исполняемый файл. Обычной практикой является подсчет размера программного обеспечения ( исходных строк кода ), чтобы отслеживать текущий прогресс проекта или устанавливать базовый уровень для будущих оценок проекта .
Последовательные стандарты кодирования, в свою очередь, могут сделать измерения более последовательными. Специальные теги в комментариях исходного кода часто используются для обработки документации, два известных примера — javadoc и doxygen . Инструменты определяют использование набора тегов, но их использование в проекте определяется соглашением.
Соглашения о кодировании упрощают написание нового программного обеспечения, чья работа заключается в обработке существующего программного обеспечения. Использование статического анализа кода постоянно росло с 1950-х годов. Часть роста этого класса инструментов разработки обусловлена возросшей зрелостью и утонченностью самих практиков (и современным акцентом на безопасность ) , а также природой самих языков.
Все специалисты по программному обеспечению должны бороться с проблемой организации и управления большим количеством иногда сложных инструкций. Для всех, кроме самых маленьких программных проектов, исходный код (инструкции) разделен на отдельные файлы и часто среди многих каталогов . Для программистов было естественным собирать тесно связанные функции (поведения) в одном файле и собирать связанные файлы в каталоги. Поскольку разработка программного обеспечения перешла от чисто процедурного программирования (например, найденного в FORTRAN ) к более объектно-ориентированным конструкциям (например, найденным в C++ ), стало практикой писать код для одного (публичного) класса в одном файле (соглашение «один класс на файл»). [6] [7] Java пошла на шаг дальше — компилятор Java возвращает ошибку, если он находит более одного публичного класса на файл.
Соглашение в одном языке может быть требованием в другом. Соглашения языка также влияют на отдельные исходные файлы. Каждый компилятор (или интерпретатор), используемый для обработки исходного кода, уникален. Правила, которые компилятор применяет к источнику, создают неявные стандарты. Например, код Python имеет гораздо более последовательный отступ, чем, скажем, Perl, потому что пробелы (отступы) на самом деле имеют значение для интерпретатора. Python не использует синтаксис фигурных скобок, который Perl использует для разграничения функций. Изменения в отступах служат разделителями. [8] [9] Tcl , который использует синтаксис фигурных скобок, похожий на Perl или C/C++, для разграничения функций, не позволяет следующее, что кажется вполне разумным программисту на C:
установить i = 0 пока { $i < 10 } { puts "$i в квадрате = [expr $i*$i]" incr i } Причина в том, что в Tcl фигурные скобки используются не только для разграничения функций, как в C или Java. В более общем смысле фигурные скобки используются для группировки слов в один аргумент. [10] [11] В Tcl слово while принимает два аргумента: условие и действие . В приведенном выше примере у while отсутствует второй аргумент — его действие (потому что Tcl также использует символ новой строки для разграничения конца команды).
Существует большое количество соглашений о кодировании; см. Coding Style для многочисленных примеров и обсуждений. Общие соглашения о кодировании могут охватывать следующие области:
Стандарты кодирования включают CERT C Coding Standard , MISRA C , High Integrity C++ .