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

Соглашения по кодированию — это набор рекомендаций для конкретного языка программирования , которые рекомендуют стиль , методы и методы программирования для каждого аспекта программы, написанной на этом языке. Эти соглашения обычно охватывают организацию файлов, отступы , комментарии , объявления , инструкции , пробелы , соглашения об именах , методы программирования , принципы программирования , практические правила программирования , лучшие архитектурные практики и т. д. Это рекомендации по структурному качеству программного обеспечения . Программистам программного обеспечения настоятельно рекомендуется следовать этим рекомендациям, чтобы улучшить читаемость и исходного кода упростить обслуживание программного обеспечения . Соглашения о кодировании применимы только к людям, сопровождающим и рецензентам программного проекта. Соглашения могут быть формализованы в виде документированного набора правил, которым следует вся команда или компания. ^{[ 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:

 set i = 0
 while {$i < 10} 
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

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

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

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

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

См. также

Ссылки

^ «EditorConfig помогает разработчикам определять и поддерживать согласованные стили кодирования в различных редакторах и IDE» . РедакторКонфиг .
^ «Соглашения о коде для языка программирования Java: зачем нужны соглашения о коде» . Sun Microsystems, Inc., 20 апреля 1999 г.
^ Роберт Л. Гласс: Факты и заблуждения программной инженерии; Эддисон Уэсли, 2003.
^ Том Гиллис. «Сложность — враг безопасности» .
^ Джеффрис, Рон (08 ноября 2001 г.). «Что такое экстремальное программирование?: Улучшение дизайна» . Журнал XP. Архивировано из оригинала 15 декабря 2006 г.
^ Хофф, Тодд (9 января 2007 г.). «Стандарт кодирования C++: именование файлов классов» .
^ Стандарты кодирования FIFE
^ ван Россум, Гвидо (19 сентября 2006 г.). Фред Л. Дрейк-младший (ред.). «Урок по Python: первые шаги к программированию» . Фонд программного обеспечения Python. Архивировано из оригинала 28 сентября 2008 г. Проверено 17 августа 2014 г.
^ Раймонд, Эрик (01 мая 2000 г.). «Почему Питон?» . Linux-журнал.
^ Разработчик Tcl Xchange. «Краткое описание синтаксиса языка Tcl» . АктивСтате.
^ Стэплин, Джордж Питер (16 июля 2006 г.). «Почему я не могу начать новую строку перед группой скобок» . «Вики Тклера».

[1] «EditorConfig помогает разработчикам определять и поддерживать согласованные стили кодирования в различных редакторах и IDE» . РедакторКонфиг .

[2] «Соглашения о коде для языка программирования Java: зачем нужны соглашения о коде» . Sun Microsystems, Inc., 20 апреля 1999 г.

[3] Роберт Л. Гласс: Факты и заблуждения программной инженерии; Эддисон Уэсли, 2003.

[4] Том Гиллис. «Сложность — враг безопасности» .

[5] Джеффрис, Рон (08 ноября 2001 г.). «Что такое экстремальное программирование?: Улучшение дизайна» . Журнал XP. Архивировано из оригинала 15 декабря 2006 г.

[6] Хофф, Тодд (9 января 2007 г.). «Стандарт кодирования C++: именование файлов классов» .

[7] Стандарты кодирования FIFE

[8] ван Россум, Гвидо (19 сентября 2006 г.). Фред Л. Дрейк-младший (ред.). «Урок по Python: первые шаги к программированию» . Фонд программного обеспечения Python. Архивировано из оригинала 28 сентября 2008 г. Проверено 17 августа 2014 г.

[9] Раймонд, Эрик (01 мая 2000 г.). «Почему Питон?» . Linux-журнал.

[10] Разработчик Tcl Xchange. «Краткое описание синтаксиса языка Tcl» . АктивСтате.

[11] Стэплин, Джордж Питер (16 июля 2006 г.). «Почему я не могу начать новую строку перед группой скобок» . «Вики Тклера».

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]