Войти
Соглашения по кодированию - это набор руководящих принципов для конкретного языка программирования, которые рекомендуют стиль программирования, практики и методы для каждого аспекта программы, написанной на этом языке. Эти соглашения обычно охватывают файловую организацию, отступ, комментарии, объявления, утверждения, пробел, соглашения об именах, практики программирования, принципы программирования, практические правила программирования, передовые методы архитектуры и т. д. Это рекомендации для программного обеспечения качество конструкции. Программистам настоятельно рекомендуется следовать этим рекомендациям, чтобы улучшить читаемость их исходного кода и упростить обслуживание программного обеспечения. Соглашения о кодировании применимы только к людям, сопровождающим и рецензентам программного проекта. Условные обозначения могут быть формализованы в виде задокументированного набора правил, которым следует вся команда или компания, или могут быть столь же неформальными, как обычные методы кодирования отдельных лиц. компиляторы.
Снижение затрат на обслуживание программного обеспечения является наиболее часто цитируемой причиной соблюдения соглашений о кодировании. В своем введении к соглашениям о коде для языка программирования Java Sun Microsystems приводит следующее обоснование:
Соглашения о коде важны для программистов по ряду причин:
Партнерская проверка программного обеспечения часто предполагает чтение исходного кода. Этот тип экспертной оценки - это, прежде всего, деятельность по обнаружению дефектов. По определению, только первоначальный автор фрагмента кода прочитал исходный файл перед отправкой кода на рассмотрение. Код, написанный с использованием последовательных руководящих принципов, легче понять и усвоить другим рецензентам, что повышает эффективность процесса обнаружения дефектов.
Даже для первоначального автора последовательно закодированное программное обеспечение облегчает сопровождение. Нет никакой гарантии, что человек запомнит точное объяснение того, почему конкретный фрагмент кода был написан определенным образом спустя долгое время после того, как код был написан изначально. Соглашения о кодировании могут помочь. Последовательное использование пробелов улучшает читаемость и сокращает время, необходимое для понимания программного обеспечения.
Если соглашения о кодировании были специально разработаны для создания высококачественного кода и затем были официально приняты, они затем становятся стандартами кодирования. Конкретные стили, независимо от того, широко ли они приняты, не создают автоматически качественный код.
Сложность - фактор, идущий против безопасности.
Управление сложностью включает следующий основной принцип: минимизировать количество кода, написанного во время разработки проекта. Это предотвращает ненужную работу, что предотвращает ненужные затраты как на начальных, так и на последующих этапах. Это просто потому, что чем меньше кода, тем меньше работы не только для создания приложения, но и для его поддержки.
Сложность контролируется как на этапе проектирования (как строится проект), так и на этапе разработки (за счет более простого кода). Если кодирование останется базовым и простым, то сложность будет сведена к минимуму. Очень часто это делается для того, чтобы кодирование было как можно более «физическим» - кодирование очень прямым и не слишком абстрактным способом. Это создает оптимальный код, который легко читать и следить за ним. Сложности также можно избежать, просто не используя сложные инструменты для простых работ.
Чем сложнее код, тем больше вероятность того, что он содержит ошибки, тем сложнее найти ошибки и тем больше вероятность наличия скрытых ошибок.
Рефакторинг относится к деятельности по обслуживанию программного обеспечения, при которой исходный код изменяется для улучшения читаемости или улучшения его структуры. Программное обеспечение часто подвергается рефакторингу, чтобы привести его в соответствие с заявленными стандартами кодирования команды после его первоначального выпуска. Любое изменение, не влияющее на поведение программного обеспечения, можно рассматривать как рефакторинг. Обычными действиями по рефакторингу являются изменение имен переменных, переименование методов, перемещение методов или целых классов и разбиение больших методов (или функций ) на более мелкие.
Гибкие методологии разработки программного обеспечения планируют регулярный (или даже непрерывный) рефакторинг, делая его неотъемлемой частью команды процесс разработки программного обеспечения.
Соглашения о кодировании позволяют сценарии или программы, задача которых - обрабатывать исходный код с какой-либо целью, кроме компиляции его в исполняемый файл. Обычной практикой является подсчет размера программного обеспечения (Исходные строки кода ), чтобы отслеживать текущий прогресс проекта или установить базовый уровень для будущих оценок проекта.
Последовательные стандарты кодирования, в свою очередь, могут сделать измерения более последовательные. Специальные теги в комментариях исходного кода часто используются для обработки документации, двумя примечательными примерами являются javadoc и doxygen. Инструменты определяют использование набора тегов, но их использование в проекте определяется соглашением.
Соглашения о кодировании упрощают написание нового программного обеспечения, задачей которого является обработка существующего программного обеспечения. Использование статического анализа кода постоянно растет с 1950-х годов. Отчасти рост этого класса инструментов разработки связан с возросшей зрелостью и сложностью самих специалистов (и современным акцентом на безопасность и безопасность ), но также и из природы сами языки.
Все специалисты по программному обеспечению должны столкнуться с проблемой организации и управления большим количеством иногда сложных инструкций. Для всех программных проектов, кроме самых маленьких, исходный код (инструкции) разделен на отдельные файлы и часто между множеством каталогов. Для программистов было естественным собирать тесно связанные функции (поведения) в одном файле и собирать связанные файлы в каталоги. По мере того, как разработка программного обеспечения перешла от чисто процедурного программирования (например, в FORTRAN ) к более объектно-ориентированным конструкциям (например, в C ++ ), стало практикой писать код для одного (общедоступного) класса в одном файле (соглашение «один класс на файл»). Java пошла еще дальше - компилятор Java возвращает ошибку, если находит более одного общедоступного класса для каждого файла.
Соглашение на одном языке может быть требованием для другого. Языковые соглашения также влияют на отдельные исходные файлы. Каждый компилятор (или интерпретатор), используемый для обработки исходного кода, уникален. Правила, которые компилятор применяет к источнику, создают неявные стандарты. Например, код Python имеет гораздо более последовательный отступ, чем, скажем, Perl, потому что пробелы (отступы) на самом деле важны для интерпретатора. Python не использует синтаксис фигурных скобок, который Perl использует для разграничения функций. Изменения в отступах служат в качестве разделителей. Tcl, который использует синтаксис фигурных скобок, подобный Perl или C / C ++ для разграничения функций, не позволяет следующее, что кажется вполне разумным программисту на C:
set i = 0 while {$ i < 10} { puts "$i squared = [expr $i*$i]" incr i }Причина в том, что в Tcl фигурные скобки используются не только для ограничения функций, как в C или Java. В более общем смысле фигурные скобки используются для объединения слов в один аргумент. В Tcl слово, а принимает два аргумента, условие и действие. В приведенном выше примере у, а у отсутствует второй аргумент, его действие (поскольку Tcl также использует символ новой строки для обозначения конца команды).
Существует большое количество соглашений о кодировании; см. Стиль кодирования для многочисленных примеров и обсуждения. Общие соглашения о кодировании могут охватывать следующие области:
Стандарты кодирования включают стандарт кодирования CERT C, MISRA C, High Integrity C ++.
 | В Викиучебнике есть книга по теме: Руководство по стилю Ada |
| В Викиучебниках есть книга по темам: Компьютерное программирование / стиль кодирования |
