Соглашения о кодировании - Coding conventions

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Соглашения о кодировании представляют собой набор руководящих принципов для конкретных язык программирования которые рекомендуют стиль программирования, практики и методы для каждого аспекта программы, написанной на этом языке. Эти соглашения обычно охватывают файловую организацию, отступ, Комментарии, декларации, заявления, белое пространство, соглашения об именах, практики программирования, принципы программирования, практические правила программирования, передовой архитектурный опыт и т. д. Это рекомендации для структурное качество программного обеспечения. Программисты настоятельно рекомендуется следовать этим рекомендациям, чтобы улучшить читаемость от их исходный код и сделать обслуживание программного обеспечения Полегче. Соглашения о кодировании применимы только к обслуживающему персоналу и рецензенты программного проекта. Соглашения могут быть формализованы в виде документированного набора правил, которым следует вся команда или компания.[1] или может быть столь же неформальным, как и обычная практика кодирования человека. Соглашения о кодировании не применяются компиляторы.

Сопровождение программного обеспечения

Снижение стоимости обслуживание программного обеспечения является наиболее часто упоминаемой причиной соблюдения соглашений о кодировании. В своем введении в соглашения о коде для языка программирования Java Sun Microsystems дает следующее обоснование:[2]

Условные обозначения кода важны для программистов по ряду причин:

  • 40–80% стоимости всего срока службы программного обеспечения идет на обслуживание.[3]
  • Вряд ли какое-либо программное обеспечение поддерживается первоначальным автором на протяжении всей его жизни.
  • Условные обозначения кода улучшают читаемость программного обеспечения, позволяя инженерам быстрее и тщательнее понимать новый код.
  • Если вы отправляете исходный код как продукт, вам необходимо убедиться, что он так же хорошо упакован и чист, как и любой другой созданный вами продукт.

Качественный

Экспертная оценка программного обеспечения часто предполагает чтение исходного кода. Этот тип экспертной оценки в первую очередь дефект активность обнаружения. По определению, только первоначальный автор фрагмента кода прочитал исходный файл перед отправкой кода на рассмотрение. Код, написанный с использованием последовательных руководств, легче понять и усвоить другим рецензентам, что повышает эффективность процесса обнаружения дефектов.

Последовательно запрограммированное программное обеспечение упрощает ремонтопригодность даже для первоначального автора. Нет никакой гарантии, что человек запомнит точное обоснование того, почему конкретный фрагмент кода был написан определенным образом спустя долгое время после того, как код был написан изначально. Соглашения о кодировании могут помочь. Последовательное использование пробел улучшает читаемость и сокращает время, необходимое для понимания программного обеспечения.

Стандарты кодирования

Если соглашения о кодировании были специально разработаны для создания высококачественного кода, а затем были официально приняты, они затем стали стандартами кодирования. Конкретные стили, независимо от того, широко ли они приняты, не создают автоматически качественный код.

Снижение сложности

Сложность - это фактор, идущий против безопасности.[4]

Управление сложностью включает следующий основной принцип: минимизировать количество кода, написанного во время разработки проекта. Это предотвращает ненужную работу, предотвращая ненужные затраты как на начальных, так и на последующих этапах. Это просто потому, что чем меньше кода, тем меньше работы не только для создания приложения, но и для его поддержки.

Сложность контролируется как на этапе проектирования (как строится проект), так и на этапе разработки (за счет более простого кода). Если кодирование останется базовым и простым, то сложность будет сведена к минимуму. Очень часто это делается для того, чтобы кодирование было как можно более «физическим» - кодирование очень прямым и не слишком абстрактным способом. Это создает оптимальный код, который легко читать и следить за ним. Сложности также можно избежать, просто не используя сложные инструменты для простых работ.

Чем сложнее код, тем больше вероятность того, что он содержит ошибки, тем сложнее найти ошибки и тем выше вероятность наличия скрытых ошибок.

Рефакторинг

Рефакторинг относится к деятельности по обслуживанию программного обеспечения, когда исходный код модифицирован для улучшения читаемости или улучшения его структуры. Программное обеспечение часто подвергается рефакторингу, чтобы привести его в соответствие с заявленными группой стандартов кодирования после его первоначального выпуска. Любое изменение, не влияющее на поведение программного обеспечения, можно рассматривать как рефакторинг. Общие действия по рефакторингу - это изменение имен переменных, переименование методов, перемещение методов или целых классов и нарушение больших методов (или же функции ) на более мелкие.

Методологии гибкой разработки программного обеспечения план регулярного (или даже непрерывного) рефакторинга, чтобы сделать его неотъемлемой частью команды процесс разработки программного обеспечения.[5]

Автоматизация задач

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

Согласованные стандарты кодирования, в свою очередь, могут сделать измерения более согласованными. Специальный теги в комментарии к исходному коду часто используются для обработки документации, два ярких примера: javadoc и доксиген. Инструменты определяют использование набора тегов, но их использование в проекте определяется соглашением.

Соглашения о кодировании упрощают написание нового программного обеспечения, задачей которого является обработка существующего программного обеспечения. Использование статический анализ кода стабильно растет с 1950-х годов. Отчасти рост этого класса инструментов разработки связан с возросшей зрелостью и искушенностью самих практиков (а также современным акцентом на безопасность и безопасность ), но также и от природы самих языков.

Языковые факторы

Все специалисты по программному обеспечению должны столкнуться с проблемой организации и управления большим количеством иногда сложных инструкций. Для всех программных проектов, кроме самых маленьких, исходный код (инструкции) разделен на отдельные файлы и часто среди многих каталоги. Для программистов было естественным собирать тесно связанные функции (поведения) в одном файле и собирать связанные файлы в каталоги. Поскольку разработка программного обеспечения перешла от чисто процедурное программирование (например, найденный в FORTRAN ) к большему объектно-ориентированный конструкции (например, найденные в C ++ ), стало практикой писать код для одного (общедоступного) класса в одном файле (соглашение «один класс на файл»).[6][7]Java пошла еще дальше - компилятор Java возвращает ошибку, если находит более одного общедоступного класса для каждого файла.

Соглашение на одном языке может быть требованием для другого. Языковые соглашения также влияют на отдельные исходные файлы. Каждый компилятор (или интерпретатор), используемый для обработки исходного кода, уникален. Правила, которые компилятор применяет к источнику, создают неявные стандарты. Например, код Python имеет гораздо более последовательный отступ, чем, скажем, Perl, потому что пробелы (отступы) на самом деле важны для интерпретатора. Python не использует синтаксис фигурных скобок, который Perl использует для разграничения функций. Изменения в отступах служат в качестве разделителей.[8][9] Tcl, который использует синтаксис фигурных скобок, подобный Perl или C / C ++ для разграничения функций, не позволяет следующее, что кажется вполне разумным программисту на C:

 набор я = 0 пока {$ i < 10}  {    ставит "$ i в квадрате = [выражение $ i * $ i]"    incr я }

Причина в том, что в Tcl фигурные скобки используются не только для ограничения функций, как в C или Java. В более общем смысле фигурные скобки используются для объединения слов в один аргумент.[10][11]В Tcl слово пока принимает два аргумента, a условие и действие. В приведенном выше примере пока отсутствует второй аргумент, его действие (поскольку Tcl также использует символ новой строки для обозначения конца команды).

Общие соглашения

Существует большое количество соглашений о кодировании; видеть Кодирование Стиль для многочисленных примеров и обсуждения. Общие соглашения о кодировании могут охватывать следующие области:

Стандарты кодирования включают Стандарт кодирования CERT C, MISRA C, Высокая целостность C ++.

Смотрите также

Рекомендации

  1. ^ «EditorConfig помогает разработчикам определять и поддерживать согласованные стили кодирования между различными редакторами и IDE». EditorConfig.
  2. ^ «Соглашения о коде для языка программирования Java: зачем нужны соглашения о коде». Sun Microsystems, Inc. 20 апреля 1999 г.
  3. ^ Роберт Л. Гласс: Факты и заблуждения программной инженерии; Эддисон Уэсли, 2003.
  4. ^ Том Гиллис.«Сложность - враг безопасности».
  5. ^ Джеффрис, Рон (2001-11-08). «Что такое экстремальное программирование?: Улучшение дизайна». Журнал XP. Архивировано из оригинал 15 декабря 2006 г.
  6. ^ Хофф, Тодд (2007-01-09). «Стандарт кодирования C ++: именование файлов классов».
  7. ^ Стандарты кодирования FIFE
  8. ^ ван Россум, Гвидо (19 сентября 2006 г.). Фред Л. Дрейк младший (ред.). «Учебник по Python: первые шаги к программированию». Фонд программного обеспечения Python. Архивировано из оригинал на 2008-09-28. Получено 2014-08-17.
  9. ^ Раймонд, Эрик (2000-05-01). "Почему Python?". Linux Journal.
  10. ^ Разработчик Tcl Xchange. "Краткое описание синтаксиса языка Tcl". ActiveState.
  11. ^ Стаплин, Джордж Питер (16.07.2006). "Почему я не могу начать новую строку перед фигурной скобкой". "Tcler's Wiki".

внешняя ссылка

Соглашения о кодировании для языков

Соглашения о кодировании для проектов