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

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

Было высказано предположение , что стиль программирования быть объединены в этой статье. ( Обсудить ) Предлагается с апреля 2021 года.

Соглашения о кодировании - это набор руководящих принципов для конкретного языка программирования, которые рекомендуют стиль , практики и методы программирования для каждого аспекта программы, написанной на этом языке. Эти соглашения , как правило , охватывают организации файлов, отступы , комментарии , заявление , заявление , пустое пространство , именование , программирование практики , принципов программирования , программирование эмпирических правил , архитектурный передовой опыт и т.д. Это рекомендация для программного обеспечения структурного качества . Программисты-программистынастоятельно рекомендуется следовать этим правилам , чтобы помочь улучшить читаемость их исходного кода и сделать обслуживание программного обеспечения проще. Соглашения о кодировании применимы только к специалистам по сопровождению и рецензентам программного проекта. Условные обозначения могут быть формализованы в виде задокументированного набора правил, которым следует вся команда или компания ^[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 }  {  положить  "$ i в квадрате = [expr $ i * $ i]"  incr i }

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

Общие соглашения [ править ]

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

• Соглашения о комментариях
• Соглашения о стилях отступа
• Соглашения о длине линии
• Соглашения об именах
• Практика программирования
• Принципы программирования
• Соглашения о стилях программирования

Стандарты кодирования включают CERT C Coding Standard , MISRA C , High Integrity C ++ , см. Список ниже.

См. Также [ править ]

• Сравнение языков программирования (синтаксис)
• Венгерская нотация
• Стиль отступа
• Список инструментов для статического анализа кода
• Список философий разработки программного обеспечения
• MISRA
• Стиль программирования
• Показатели программного обеспечения
• Качество программного обеспечения
• Сила 10 правил

Ссылки [ править ]

Список стандартов кодирования [ править ]

В Викиучебнике есть книга на тему: Руководство по стилю Ada.

В Викиучебнике есть книга на тему: Компьютерное программирование / Стиль программирования.

Правила кодирования для языков [ править ]

• ActionScript: соглашения и рекомендации по кодированию Flex SDK
• Ada: Руководство по качеству и стилю Ada 95: Рекомендации для профессиональных программистов
• Ada: Руководство по использованию языка программирования Ada в системах с высокой степенью интеграции (ISO / IEC TR 15942: 2000)
• Ada: Отделение полетного программного обеспечения НАСА - стандарт кодирования на языке Ada
• Ада: Стандарт кодирования Ада ЕКА - BSSC (98) 3, выпуск 1, октябрь 1998 г.
• Ада: Разработка и стандартизация программного обеспечения Европейского космического агентства
• C: Стандарт кодирования CERT C Стандарт кодирования CERT C (SEI)
• C: Встроенный стандарт кодирования C (Barr Group)
• C: Стандарт разработки прошивки (Джек Ганссл)
• C: MISRA C
• C: Стандарт TIOBE C ^[1]
• C ++: Основные принципы C ++ ( Бьярн Страуструп , Херб Саттер )
• C ++: стандарт кодирования C / C ++ Quantum Leaps
• C ++: Программирование на C ++ / Языки программирования / C ++ / Код / Соглашения о стилях
• C ++: Рекомендации GeoSoft по стилю программирования на C ++
• C ++: Руководство по стилю C ++ от Google
• C ++: C ++ с высокой степенью целостности
• C ++: MISRA C ++
• C ++: стандарт программирования C ++ для здравоохранения Philips ^[2]
• C / C ++: Рекомендации по кодированию C / C ++ от деволо
• C #: C # Coding Conventions (Руководство по программированию на C #)
• C #: Рекомендации по проектированию для разработки библиотек классов
• C #: Брэд Абрамс
• C #: стандарт кодирования C # Philips Healthcare или Philips Healthcare ^[3]
• D: Стиль D
• Дротик: Руководство по стилю Дротика
• Erlang: правила и соглашения программирования на Erlang
• Flex: условные обозначения кода для Flex SDK
• Java: стандарты кодирования Ambysoft для Java
• Java: Соглашения о коде для языка программирования Java (Активно не поддерживается. Последняя версия: 1999-APR-20.)
• Java: Руководство GeoSoft по стилю программирования на Java
• Java: стандарты кодирования Java в Curlie
• Java: Стандарт Java TIOBE ^[4]
• Java: соглашения о кодировании SoftwareMonkey для Java и других языков синтаксиса фигурных скобок
• JavaScript: условные обозначения кода для языка программирования JavaScript
• Лисп: правила стиля Лиспа Риастрада
• MATLAB: Соглашения о кодировании нейробатов для MATLAB
• Object Pascal: Руководство по стилям Object Pascal
• Perl: Руководство по стилям Perl
• PHP :: PEAR: Стандарты кодирования PHP :: PEAR
• PHP :: FIG: группа взаимодействия PHP Framework
• PL / I: Руководство по стилю PL / I
• Python: Руководство по стилю кода Python
• Ruby: неофициальное руководство по использованию Ruby
• Ruby: руководство по стилю Ruby на GitHub
• Оболочка: Руководство по стилю оболочки от Google

Правила кодирования для проектов [ править ]

• Руководство по стилю языка C для разработчиков Apache
• Стандарты кодирования PHP на Drupal
• Стандарты кодирования GNU
• «Стиль программирования GNAT: Руководство для разработчиков GNAT» . Электронная документация GCC . Фонд свободного программного обеспечения . Проверено 19 января 2009 . CS1 maint: discouraged parameter (link)( PDF )
• Стиль кодирования ядра Linux (или Documentation / CodingStyle в дереве исходных кодов ядра Linux)
• Руководство по стилю кодирования Mozilla
• Моно: стиль программирования для моно.
• Руководство по стилю исходного файла ядра OpenBSD (KNF)
• Рекомендации по C ++ для Road Intranet
• Руководства по стилю для проектов с открытым исходным кодом, созданных Google
• Руководство по стилю исходного кода NetBSD (ранее известное как стандартная форма ядра BSD)
• Стандарты кодирования Zend Framework
• Языковой стиль ZeroMQ C для масштабируемости (КЛАСС)