Прочитав еще больше плохих советов о стандартах форматирования кода ( один раз , два , тысячи из них ), не мог не поделиться своими мыслями на эту тему.
Многие годы я питал в своем подсознании ощущение «здесь что-то не так».
И вот пришло время решить, что не так и почему.
Рискуя быть засыпанным гнилыми бананами, я все же пишу эту статью здесь, а не в своем личном блоге, потому что это очень важная тема и я хочу, чтобы как можно больше разработчиков поняли ее суть и, возможно, переосмыслили их взгляды на жизнь.
код.
Стандарты кодирования
Типичные проблемы со многими из этих руководств по стилю: 1. Их целесообразность слабо обоснована 2. Они декларируют конкретные правила вместо принципов.3. Эти правила слабо обоснованы и зачастую построены на противоречивых принципах.
В упомянутой статье все обоснование необходимости стандартизации звучит так:
Хорошее руководство по коду позволит достичь следующего: 1. Установление стандарта качества кода для всех источников; 2. Обеспечение согласованности источников; 3. Соблюдение стандартов всеми застройщиками; 4. Повышенная производительность.1. [вот картинка о другом стандарте] «Стандарт нужен для того, чтобы был стандарт» не оправдывает его существование.
2. В любом более-менее большом проекте всегда будет куча кода, не соответствующего текущим тенденциям дизайнерской моды: изменения руководства по стилю с течением времени, устаревший код, код из сторонних библиотек, автогенерация код. Это неизбежно и не так плохо, как может показаться на первый взгляд. 3. То же, что и первый пункт. 4. Уже потеплело, но опять же нет обоснования, почему от этого должна увеличиться производительность, а главное, насколько.
По своему опыту могу сказать, что худшее решение — это привыкнуть писать и читать код в одном определенном стиле, из-за чего любой код, написанный «не по правилам», будет вызывать раздражение, тревогу, гнев и желание навязать свои привычки на других.
Гораздо полезнее научиться воспринимать исходный код, игнорируя дизайн.
И для этого наличие разноформатного кода даже полезно.
Я не говорю, что надо расслабиться и написать все в одну строку, но чтобы этого не делать, есть куда более практические причины, чем «нужен стандарт, чтобы все было стандартно».
Как написать грамотный стандарт: 1. Определились с целями 2. Сформулировать принципы и проверить их соответствие целям.
3. Сформулируйте минимум правил для реализации этих принципов.
Так давайте попробуем
Цель: снизить стоимость поддержки, наложив ограничения на себя и свою команду.
Какая поддержка:
1. написание нового кода
2. изменение существующего, в том числе автоматическое
3. поиск необходимого фрагмента кода
4. анализ логики кода
5. Поиск источника неправильного поведения
6. сравнение разных версий одного и того же кода
7. перемещение кода между ветками
Какие принципы помогут вам достичь цели:
1. Строки файла должны быть максимально независимыми.
Причина проста: если изменение одной строки требует изменения других, то это увеличивает риск конфликтов при слиянии ветвей.
Каждый конфликт означает дополнительное, иногда значительное время для его разрешения.
Несмотря на то, что эта простая идея фигурирует в одном из правил, упомянутых в начале статьи, в другом правиле мы видим явно противоречивую рекомендацию: Теги: #JavaScript #руководство по стилю #CSS #руководство по стилю #стандарты маленького города #CSS #JavaScript #программирование
-
Цукерберг «Позвонит» Ищет Редактора Новостей
19 Oct, 24 -
Немного О Ux И Ui В Приложении Ridewithme
19 Oct, 24 -
Почему Ооп
19 Oct, 24 -
Миллиарды Устройств С Bluetooth
19 Oct, 24 -
Атрибут «Align» Элемента «Img»
19 Oct, 24 -
#11 Джокаст
19 Oct, 24
