Лучшие практики кодирования
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
Лучшие практики кодирования или лучшие практики программирования — это набор неформальных, иногда личных, правил ( лучших практик многие разработчики программного обеспечения в области компьютерного программирования ), которым следуют для улучшения качества программного обеспечения . [1] Многие компьютерные программы требуют устойчивости и надежности в течение длительных периодов времени. [2] поэтому любые правила должны облегчать как первоначальную разработку, так и последующую поддержку исходного кода людьми, не являющимися первоначальными авторами.
В правиле девяносто-девяноста Том Каргилл объясняет, почему проекты по программированию часто задерживаются: «Первые 90% кода занимают первые 90% времени разработки. Последние 10% занимают еще 90% времени». [3] Любые рекомендации, которые могут исправить эту недальновидность, заслуживают рассмотрения.
Размер проекта или программы оказывает существенное влияние на частоту ошибок, производительность программистов и объем необходимого управления. [4]
Качество программного обеспечения
[ редактировать ]связано с множеством атрибутов Как указано ниже, хорошее программное обеспечение . Некоторые из них могут быть взаимопротиворечивыми (например, очень высокая скорость или тщательная проверка ошибок), а разные клиенты и участники могут иметь разные приоритеты. Вайнберг приводит пример того, как разные цели могут существенно повлиять как на требуемые усилия, так и на эффективность. [5] Более того, он отмечает, что программисты обычно стремятся достичь любых явных целей, которые могут быть поставлены, возможно, за счет любых других атрибутов качества.
Соммервилль выделил четыре обобщенных атрибута, которые связаны не с тем, что делает программа, а с тем, насколько хорошо она это делает: ремонтопригодность , надежность , эффективность и удобство использования . [6]
Вайнберг определил четыре цели, которым должна соответствовать хорошая программа: [7]
- Соответствует ли программа своей спецификации («правильный вывод для каждого возможного ввода»)?
- Выполняется ли программа по графику (и в рамках бюджета)?
- Насколько адаптируема программа к изменяющимся требованиям?
- Достаточно ли эффективна программа для среды, в которой она используется?
Хоар определил семнадцать целей, связанных с качеством программного обеспечения, в том числе: [8]
- Четкое определение цели.
- Простота использования.
- Надежность (трудно использовать неправильно, не допускает ошибок).
- Ранняя доступность (доставка вовремя, когда это необходимо).
- Надежность.
- Расширяемость в свете опыта.
- Краткость.
- Эффективность (достаточно быстрая для той цели, для которой она предназначена).
- Минимальные затраты на разработку.
- Соответствие всем соответствующим стандартам (включая стандарты для конкретных языков программирования ).
- Четкие, точные и точные пользовательские документы .
Предварительные условия
[ редактировать ]Прежде чем начать кодирование, важно убедиться, что все необходимые предварительные условия выполнены (или, по крайней мере, продвинулись достаточно далеко, чтобы обеспечить прочную основу для кодирования). Если различные предварительные условия не выполнены, то программное обеспечение, скорее всего, будет неудовлетворительным, даже если оно завершено.
От Meek & Heath: «То, что происходит до того, как человек переходит к этапу кодирования, часто имеет решающее значение для успеха проекта». [9]
Предварительные условия, изложенные ниже, охватывают такие вопросы, как:
- Как построена разработка? (жизненный цикл)
- Для чего предназначено программное обеспечение? (требования)
- Какова общая структура программной системы? (архитектура)
- Какова детальная проработка отдельных компонентов? (дизайн)
- Каков выбор языка(ов) программирования?
Для небольших простых проектов может оказаться целесообразным объединить архитектуру с дизайном и принять очень простой жизненный цикл.
Жизненный цикл
[ редактировать ]Методология разработки программного обеспечения — это структура, которая используется для структурирования, планирования и контроля жизненного цикла программного продукта. Общие методологии включают водопад , прототипирование , итеративную и инкрементную разработку , спиральную разработку , гибкую разработку программного обеспечения , быструю разработку приложений и экстремальное программирование .
Водопадная модель представляет собой последовательный подход к разработке; в частности, предполагается, что требования могут быть полностью определены в начале проекта. Однако МакКоннелл цитирует три исследования, которые показывают, что в среднем требования меняются примерно на 25% в ходе проекта. [10] Другие упомянутые выше методологии пытаются уменьшить влияние таких изменений требований, часто с помощью той или иной формы поэтапного, инкрементального или итеративного подхода. Для разных сред разработки могут подходить разные методологии.
С момента своего появления в 2001 году популярность гибкой разработки программного обеспечения возросла, чему способствовали разработчики программного обеспечения, стремящиеся к более итеративному и совместному подходу к разработке программного обеспечения. [11]
Требования
[ редактировать ]МакКоннелл заявляет: «Первое предварительное условие, которое вам необходимо выполнить перед началом строительства, — это четкое определение проблемы, которую должна решить система». [12]
Мик и Хит подчеркивают, что целью, к которой следует стремиться, является ясная, полная, точная и недвусмысленная письменная спецификация. [13] Обратите внимание, что достичь этой цели может быть невозможно, и цель, скорее всего, все равно изменится (как упоминалось в предыдущем разделе).
Соммервилль различает менее подробные требования пользователя и более подробные системные требования. [14] Он также различает функциональные требования (например, обновление записи) и нефункциональные требования (например, время ответа должно быть менее 1 секунды).
Архитектура
[ редактировать ]Хоар указывает: «есть два способа создания проекта программного обеспечения: один способ — сделать его настолько простым, чтобы не было очевидных недостатков; другой способ — сделать его настолько сложным, чтобы не было очевидных недостатков. Первый метод — это гораздо сложнее». [15]
Архитектура программного обеспечения связана с решением того, что должно быть сделано и какой программный компонент будет это делать (то, как что-то будет сделано, остается на этапе детального проектирования ниже). Это особенно важно, когда система программного обеспечения содержит более одной программы, поскольку она эффективно определяет интерфейс между этими различными программами. Он также должен включать в себя некоторое рассмотрение любых пользовательских интерфейсов, не вдаваясь в чрезмерные детали.
На этом этапе необходимо учитывать любые нефункциональные требования к системе (время отклика, надежность, ремонтопригодность и т. д.). [16]
Архитектура программного обеспечения также представляет интерес для различных заинтересованных сторон (спонсоров, конечных пользователей и т. д.), поскольку дает им возможность проверить, могут ли быть выполнены их требования.
Дизайн
[ редактировать ]Основная цель дизайна — заполнить детали, которые были упущены в архитектурном проекте. Цель состоит в том, чтобы проект был достаточно подробным, чтобы обеспечить хорошее руководство для фактического кодирования, включая детали любых конкретных алгоритмов, которые будут использоваться. Например, на архитектурном уровне можно было отметить, что некоторые данные необходимо отсортировать, а на уровне проектирования необходимо решить, какой алгоритм сортировки использовать. В качестве еще одного примера: если используется объектно-ориентированный подход, необходимо определить детали объектов (атрибуты и методы).
Выбор языка(ов) программирования
[ редактировать ]Майер утверждает: «Ни один язык программирования не идеален. Не существует даже одного лучшего языка; есть только языки, которые хорошо или, возможно, плохо подходят для определенных целей. Понимание проблемы и связанных с ней требований программирования необходимо для выбора языка, лучше всего подходящего для конкретной цели». решение." [17]
Из книги Мика и Хита: «Суть искусства выбора языка состоит в том, чтобы начать с проблемы, решить, каковы ее требования и их относительную важность, поскольку, вероятно, будет невозможно одинаково хорошо удовлетворить их все. Затем должны быть доступны доступные языки. оцениваться по списку требований и выбирать наиболее подходящий (или наименее неудовлетворительный)». [18]
Вполне возможно, что разные языки программирования подходят для разных аспектов проблемы. Если языки или их компиляторы позволяют, возможно объединить в одной программе подпрограммы, написанные на разных языках.
Даже если нет выбора, какой язык программирования использовать, МакКоннелл дает несколько советов: «У каждого языка программирования есть сильные и слабые стороны. Помните о конкретных сильных и слабых сторонах языка, который вы используете». [19]
Стандарты кодирования
[ редактировать ]Этот раздел также является необходимым условием для кодирования, как отмечает МакКоннелл: «Определите соглашения программирования, прежде чем приступить к программированию. Почти невозможно изменить код, чтобы он соответствовал им позже». [19]
Как указано в конце соглашений о кодировании , для разных языков программирования существуют разные соглашения, поэтому применять одни и те же соглашения к разным языкам может быть контрпродуктивно. Важно отметить, что для любого языка программирования не существует какого-то одного конкретного соглашения по кодированию. Каждая организация имеет собственный стандарт кодирования для каждого типа программного проекта. Поэтому крайне важно, чтобы программист выбрал или составил определенный набор рекомендаций по кодированию до начала проекта программного обеспечения. Некоторые соглашения по кодированию являются общими и могут не применяться к каждому программному проекту, написанному на определенном языке программирования.
Использование соглашений о кодировании особенно важно, когда в проекте участвует более одного программиста (были проекты с участием тысяч программистов). Программисту гораздо легче читать код, написанный кем-то другим, если весь код соответствует одним и тем же соглашениям.
В качестве примеров плохих соглашений по кодированию Роуди Грин приводит длинную (ироничную) статью о том, как создавать неподдерживаемый код. [20]
Комментирование
[ редактировать ]Из-за ограничений по времени или из-за программистов-энтузиастов, которые хотят немедленных результатов для своего кода, комментирование кода часто отходит на второй план. Программисты, работающие в команде, считают, что лучше оставлять комментарии, поскольку кодирование обычно следует циклам или над конкретным модулем может работать несколько человек. Однако некоторые комментарии могут снизить стоимость передачи знаний между разработчиками, работающими над одним и тем же модулем.
На заре компьютерной эры одной из практик комментирования было оставлять краткое описание следующего:
- Название модуля
- Цель модуля
- Описание модуля
- Оригинальный автор
- Модификации
- Авторы, изменившие код, с описанием причин его изменения.
«Описание модуля» должно быть максимально кратким, но без ущерба для ясности и полноты.
Однако последние два пункта в значительной степени устарели с появлением систем контроля версий . Изменения и их авторство можно надежно отслеживать с помощью таких инструментов, а не с помощью комментариев.
Кроме того, если используется сложная логика, рекомендуется оставлять «блок» комментария рядом с этой частью, чтобы другой программист мог понять, что именно происходит.
Модульное тестирование может быть еще одним способом показать, как предполагается использовать код.
Соглашения об именах
[ редактировать ]Использование правильных соглашений об именах считается хорошей практикой. Иногда программисты склонны использовать X1, Y1 и т. д. в качестве переменных и забывают заменить их значимыми, что приводит к путанице.
Обычно считается хорошей практикой использовать описательные имена.
Пример. Переменная, которая принимает вес в качестве параметра для грузовика, может называться TrkWeight, TruckWeightKilograms или Truck_Weight_Kilograms, при этом TruckWeightKilograms (см. именование переменных в регистре Pascal ) часто является предпочтительным, поскольку ее можно сразу распознать, но соглашение об именах не всегда соблюдается. согласованность между проектами и/или компаниями.
Сохраняйте код простым
[ редактировать ]Код, который пишет программист, должен быть простым. Сложная логика для достижения простой цели должна быть сведена к минимуму, поскольку в будущем код может быть изменен другим программистом. Логика, реализованная одним программистом, может не иметь смысла для другого. Поэтому всегда старайтесь сделать код максимально простым. [21]
Портативность
[ редактировать ]Код программы не должен содержать «жестко закодированных» (буквальных) значений, относящихся к параметрам среды, таким как абсолютные пути к файлам, имена файлов, имена пользователей, имена хостов, IP-адреса и URL-адреса, порты UDP/TCP. В противном случае приложение не будет работать на хосте, дизайн которого отличается от ожидаемого. Осторожный программист может параметризовать такие переменные и настроить их для среды размещения за пределами самого приложения (например, в файлах свойств, на сервере приложений или даже в базе данных). Сравните мантру о «единой точке определения». [22] (НИЖНИЙ).
В качестве расширения такие ресурсы, как файлы XML, также должны содержать переменные, а не литеральные значения, иначе приложение не будет перенесено в другую среду без редактирования файлов XML. Например, если приложения J2EE работают на сервере приложений, такие параметры среды могут быть определены в области JVM, и приложение должно получать значения оттуда.
Масштабируемость
[ редактировать ]Разрабатывайте код с масштабируемостью в качестве цели проектирования, потому что очень часто в проектах программного обеспечения в проект, который становится больше, всегда добавляются новые функции. Таким образом, возможность добавлять новые функции в базу кода программного обеспечения становится неоценимым методом написания программного обеспечения.
Многоразовое использование
[ редактировать ]Повторное использование — очень важная цель проектирования при разработке программного обеспечения. Повторное использование сокращает затраты на разработку, а также сокращает время разработки, если повторно используемые компоненты или модули уже протестированы. Очень часто проекты программного обеспечения начинаются с существующей базовой версии, которая содержит проект в его предыдущей версии, и в зависимости от проекта многие существующие программные модули и компоненты используются повторно, что сокращает время разработки и тестирования и, следовательно, увеличивает вероятность поставки программного обеспечения. проект по графику.
Краткое руководство по строительству
[ редактировать ]Общий обзор всего вышеперечисленного:
- Знайте, что должен выполнять блок кода
- Соблюдайте единые соглашения об именах.
- Укажите краткое описание, для чего нужна переменная (ссылка на комментарий)
- Исправляйте ошибки по мере их возникновения.
- Держите свой код простым
- Разрабатывайте код с учетом масштабируемости и повторного использования.
Разработка кода
[ редактировать ]Создание кода
[ редактировать ]Лучшая практика создания кода предполагает ежедневные сборки и тестирование или, что еще лучше, непрерывную интеграцию или даже непрерывную доставку .
Тестирование
[ редактировать ]Тестирование — неотъемлемая часть разработки программного обеспечения, которую необходимо планировать. Также важно, чтобы тестирование проводилось заранее; это означает, что тестовые примеры планируются до начала кодирования, а тестовые сценарии разрабатываются во время проектирования и кодирования приложения.
Отладка кода и исправление ошибок
[ редактировать ]Программисты склонны писать полный код, а затем приступать к его отладке и проверке на наличие ошибок. Хотя этот подход может сэкономить время в небольших проектах, более крупные и сложные проекты, как правило, требуют меньше времени. иметь слишком много переменных и функций, требующих внимания. Поэтому после завершения отладки полезно отлаживать каждый модуль, а не всю программу. В конечном итоге это экономит время, и вам не придется тратить много времени на выяснение того, что не так. модульные тесты для отдельных модулей и/или функциональные тесты для веб-сервисов В этом могут помочь и веб-приложений.
Развертывание
[ редактировать ]Развертывание — это заключительный этап выпуска приложения для пользователей. Некоторые лучшие практики: [23] [24]
- Сохраняйте простую структуру установки: количество файлов и каталогов должно быть сведено к минимуму. Не устанавливайте ничего, что никогда не будет использоваться.
- Оставляйте только то, что необходимо. Действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. Неиспользуемые ресурсы (старые или вышедшие из строя версии файлов, исходный код, интерфейсы и т. д.) необходимо архивировать где-нибудь в другом месте, чтобы новые сборки оставались экономичными.
- Постоянно обновляйте все: действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. При развертывании на основе разностей перед развертыванием разностей убедитесь, что версии уже развернутых ресурсов являются самыми последними. Если вы не уверены, выполните развертывание с нуля (сначала удалите все, а затем выполните повторное развертывание).
- Примите многоэтапную стратегию: в зависимости от размера проекта иногда требуется больше развертываний. [25]
- Имейте стратегию отката: Должен быть способ вернуться к предыдущей (рабочей) версии.
- Положитесь на автоматизацию для повторяющихся процессов: существует слишком много места для человеческой ошибки, поэтому развертывание не должно выполняться вручную. Используйте инструмент, встроенный в каждую операционную систему, или используйте язык сценариев для кроссплатформенных развертываний. [26] [27]
- Воссоздайте реальную среду развертывания: учтите все (маршрутизаторы, межсетевые экраны, веб-серверы, веб-браузеры, файловые системы и т. д.).
- Не меняйте процедуры и сценарии развертывания на лету и документируйте такие изменения: дождитесь новой итерации и запишите такие изменения соответствующим образом.
- Настройка развертывания. Новые программные продукты, такие как API, микросервисы и т. д., требуют особого внимания для успешного развертывания. [28] [29] [30]
- Уменьшите риск на других этапах разработки: если другие действия, такие как тестирование и управление конфигурацией, неверны, развертывание наверняка завершится неудачей. [31] [32]
- Учитывайте влияние каждой заинтересованной стороны: организационные, социальные и правительственные соображения. [33] [34] [35]
См. также
[ редактировать ]- Лучшая практика
- Список инструментов для статического анализа кода
- Ассоциация надежности программного обеспечения для автомобильной промышленности (MISRA)
- Обеспечение программного обеспечения
- Качество программного обеспечения
- Список философий разработки программного обеспечения
- Собор и базар - книга, сравнивающая программное обеспечение с открытым исходным кодом «сверху вниз» и «снизу вверх».
- Дэвис 201 Принципы разработки программного обеспечения [36]
- Где теория программной инженерии? [37]
- Не заставляйте меня думать (Принципы интуитивной навигации и информационного дизайна) [38]
Примечания
[ редактировать ]Ссылки
[ редактировать ]- ^ МакКоннелл, Стив (2004). Код завершен . Редмонд, Вашингтон: Microsoft Press. п. [ нужна страница ] . ISBN 978-0-7356-9125-4 . OCLC 61315783 .
- ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. п. 38. ISBN 0-321-21026-3 .
- ^ Бентли, Джон (1985). «Жемчужины программирования: информатика на бампере» . Коммуникации АКМ . 28 (9): 896–901. дои : 10.1145/4284.315122 . ISSN 0001-0782 . S2CID 5832776 .
- ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. стр. 649–659 . ISBN 0-7356-1967-0 .
- ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (изд. Серебряного юбилея). Издательство Дорсет Хаус, Нью-Йорк. стр. 128–132. ISBN 978-0-932633-42-2 .
- ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 12–13. ISBN 0-321-21026-3 .
- ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (изд. Серебряного юбилея). Издательство Дорсет Хаус, Нью-Йорк. стр. 15–25. ISBN 978-0-932633-42-2 .
- ^ Хоар, ЦАР (1972). «Качество программного обеспечения» . Программное обеспечение: практика и опыт . 2 (2). Уайли: 103–105. дои : 10.1002/спе.4380020202 .
- ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 14
- ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 40 . ISBN 0-7356-1967-0 .
- ^ Саколик, Исаак (8 апреля 2022 г.). «Краткая история гибкой методологии» . Инфомир . Проверено 6 февраля 2023 г.
- ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 36 . ISBN 0-7356-1967-0 .
- ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 15
- ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 118–123. ISBN 0-321-21026-3 .
- ^ Хоар, ЦАР (1981). «Старая одежда императора» (PDF) . Коммуникации АКМ . 24 (2). АКМ: 75–83. дои : 10.1145/358549.358561 . S2CID 97895 . Проверено 25 ноября 2019 г.
- ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 242–243. ISBN 0-321-21026-3 .
- ^ Майер, Герберт (1989). Продвинутое программирование на языке C на IBM PC . Книги Виндкреста. п. xii (предисловие). ISBN 0830693637 .
- ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 37
- ^ Jump up to: а б МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 70 . ISBN 0-7356-1967-0 .
- ^ Роуди Грин. «неподдерживаемый код: Глоссарий Java» . Проверено 26 ноября 2013 г.
- ^ Несколько (вики). «Лучшие практики» . Докфорж . Проверено 13 ноября 2012 г.
- ^ «Единая точка определения на примере» . Проверено 30 ноября 2015 г.
— Ничего не повторяй. Стремитесь к единой точке определения для каждого аспекта вашего приложения [...]».
- ^ «7 лучших практик по развертыванию приложений – Done Devops» . dzone.com .
- ^ «Семь смертных грехов развертывания программного обеспечения [LWN.net]» . lwn.net .
- ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
- ^ Круз, Виктор (3 апреля 2013 г.). «Почему 30% развертываний приложений терпят неудачу» . Проводной – через www.wired.com.
- ^ «Правила развертывания программного обеспечения» . Архивировано из оригинала 13 мая 2010 г.
- ^ «Инструменты, необходимые для ускорения развертывания в соответствии со спросом» . 3 февраля 2017 г.
- ^ Анкерхольц, Эмбер (14 сентября 2016 г.). «DevOps и искусство безопасного развертывания приложений» .
- ^ «Организация развертывания программного обеспечения с учетом условий сбоя» . Веб-сервисы Amazon . 5 мая 2014 г.
- ^ «Лучшие практики для безопасного развертывания» . TheServerSide.com .
- ^ Эмблер, Скотт. «Эффективное развертывание программного обеспечения» . Доктор Добб .
- ^ «Развертывание корпоративных приложений: гуманность внедрения программного обеспечения» . Архивировано из оригинала 21 августа 2016 г.
- ^ «Хакерская бюрократия: улучшение найма и развертывания программного обеспечения | 18F: Предоставление цифровых услуг» . 18f.gsa.gov . 14 мая 2014 г.
- ^ «Плохое развертывание программного обеспечения хуже, чем ничего не делать» . Неповрежденная технология . 1 июня 2016 г.
- ^ Дэвис, Алан Марк. (1995). 201 принцип разработки программного обеспечения . Нью-Йорк: МакГроу-Хилл. ISBN 0-07-015840-1 . OCLC 31814837 .
- ^ Джонсон, Понт; Экстедт, Матиас; Джейкобсон, Ивар (2012). «Где теория разработки программного обеспечения?». Программное обеспечение IEEE . 29 (5): 96. doi : 10.1109/MS.2012.127 . ISSN 0740-7459 . S2CID 38239662 .
- ^ Круг, Стив (2014). Не заставляйте меня думать, еще раз: подход здравого смысла к удобству использования Интернета . Бэйл, Элизабет, Стрейгер, Арен, Матчо, Марк (Третье изд.). [Сан-Франциско, Калифорния]. ISBN 978-0-321-96551-6 . OCLC 859556499 .
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
- Харбисон, Сэмюэл П.; Стил, Гай Л. (2002). C-Справочное руководство . ISBN 978-0-13-089592-9 .
- Расширение жизненного цикла разработки безопасного программного обеспечения, версия 2.0, октябрь 2008 г., описывает принципы и методы безопасности, которые разработчики программного обеспечения, тестировщики и интеграторы могут использовать для достижения двойной цели: создания более безопасных программно-емких систем и проверки безопасности. программного обеспечения, которое они производят.
- Дутта, Шив; Крюк, Гэри (26 июня 2003 г.). «Лучшие практики программирования на языке C» . РазработчикWorks . ИБМ . Архивировано из оригинала 13 июля 2009 года . Проверено 21 января 2010 г.
Внешние ссылки
[ редактировать ]- Пол Берден, соавтор стандартов кодирования MISRA C и представитель PRQA в рабочей группе MISRA C более 10 лет, обсуждает распространенную ошибку стандарта кодирования: «Нам не нужен стандарт кодирования!, нам просто нужно выявлять ошибки». !"