SQM 22/24: Code Style [software quality crash course] [eng sub]

• Лекция обсуждает различные способы оценки качества кода, включая размер, сложность, историю кода и комментарии.  

• В следующих трех лекциях будут рассмотрены стиль кода, количество подозрительных мест и метрики для оценки качества кода.  

• Рассматриваются три программы на разных языках, выполняющие одну и ту же функцию.  

• Программа на языке Си выглядит наименее симпатично, с непоследовательным форматированием.  

• Программа на языке Java выглядит более симпатично, с более строгим форматированием.  

• Брайан Керниган и Филипп Плауга написали книгу о красивом программировании в 1974 году.  

• В книге заложены основы, которые продолжают использоваться, хотя и не всегда осознаются.  

• Авторы обсуждают, что чем сложнее код для понимания, тем больше ошибок он содержит.  

• Они рекомендуют писать код так, чтобы он был понятен не только компьютеру, но и другим программистам.  

• В 1981 году был предложен первый стиль для языка Паскаль.  

• Он рекомендовал использовать пробелы, пустые строки и специальные символы для подсветки логической структуры программы.  

• В 1982 году был создан первый стайл-чекер для языка Паскаль.  

• Он оценивал качество кода, но не объяснял, почему код не соответствует стилю.  

• Современные стайл-чекеры работают иначе, они показывают, где есть проблемы с кодом и предлагают исправления.  

• Авторы предлагают использовать метрику, которая оценивает количество символов на строку кода.  

• Они предполагают, что идеальная средняя длина строки на языке Паскаль составляет от 15 до 25 символов.  

• Если количество символов на строку меньше 10, то качество кода будет низким, а если больше 30, то качество также будет низким.  

• Авторы предлагают свою систему оценки качества кода на языке Си, которая включает процент комментариев, процент отступов, процент пустых строк и символов на строку.  

• Они утверждают, что эта система имеет смысл только если она коррелирует с другими метриками, такими как количество ошибок или сложность программы.  

• В 1985 году люди пытались найти связь между стилем программирования и качеством кода, но это было сложно из-за отсутствия жестких метрик оценки качества.  

• В 1986 году авторы попытались найти такую связь, но не смогли найти ее, так как не было понимания, как это связано с конечным результатом и прибылью компании.  

• В 1986 году было проведено исследование, которое показало, что количество ошибок в коде не коррелирует с его стилем.  

• В настоящее время ситуация изменилась, и стиль кода может влиять на его качество.  

• Стайл-чекеры - это инструменты, которые помогают найти ошибки в коде, такие как лишние скобки или пробелы.  

• Они могут быть полезны для улучшения читаемости кода и обнаружения ошибок.  

• Количество правил, через которые проходит код, может быть использовано как метрика качества кода.  

• Однако, правила могут быть разными по сложности и значимости, поэтому необходимо учитывать их при оценке качества кода.  

• Стайл-чекеры помогают контролировать стиль кода, но не всегда могут определить все ошибки.  

• Количество правил в стайл-чекерах определяет их мощность и возможность обнаружения ошибок.  

• Существуют стайл-чекеры для проверки оформления файлов, таких как markdown.  

• Добавление дополнительных стайл-чекеров в сборку может улучшить качество кода.  

• Шел-чек для проверки кода на языке bash, чек-мейк для проверки качества make-файлов и их конфигурации.  

• Икс-коп для контроля форматирования файлов в репозиториях.  

• Автор обсуждает важность использования стайл-чекеров для повышения качества кода.  

• Он также упоминает об обфускации кода для защиты от декомпиляции и реверс-инжиниринга.  

• Автор обсуждает статью, в которой авторы пытаются найти корреляцию между ошибками в коде и красотой кода.  

• Они обнаружили, что девять из 72 правил стандарта Мистра действительно коррелируют с ошибками в коде, но 29 правил не имеют такой связи.  

• Автор обсуждает статью, в которой говорится, что стиль кода является второй причиной режекта кода.  

• Это означает, что соблюдение стиля кода может помочь быстрее интегрировать код в общий репозиторий.  

• Исследование показывает, что большинство людей используют стайл-чекеры, но не всегда в их дефолтной конфигурации.  

• Многие пользователи изменяют конфигурацию, добавляя свои кастомные правила.  

• Стайл-чекеры могут быть основной причиной билд-брейков, когда код не соответствует стандартам кодирования.  

• Рекомендуется использовать стайл-чекеры как ограничивающие или запрещающие инструменты, чтобы они останавливали сборку при нарушении стандартов.  

• Стайл-чекинг не поможет в понимании кода, если есть проблемы с его сложностью или непонятностью.  

• Стайл-чекинг становится важным, когда размер кода увеличивается, и его красота начинает влиять на понимание.  

• Статья 2019 года показывает, что если пул реквест совпадает с ожиданиями по стилистике, он легче и быстрее попадает в репозитории.  

• Рекомендуется писать красиво и настраивать контроль стилистики через инструменты, такие как GitHub Actions.  

• Не нужно описывать свои ожидания по стилистике, можно использовать существующие стили, такие как Ruby Style Guide, Java Style Guide, и т.д.  

• Если хотите изменить стандарт, рекомендуется отправить предложение в репозитории, такие как Ruby или Python.  

• Важно следить за обновлениями и изменениями в стилевых чекерах, чтобы код был актуальным и соответствовал современным требованиям.