форматирование кода что это
Форматирование HTML
Существует разница между тем, что написано в вашем коде HTML и что отображается в браузере.
Мы также видели, как можно писать комментарии в коде HTML, чтобы помочь человеку с чтением кода, без необходимости отображать эти комментарии в браузере.
Другим видом написанного кода, который игнорируется браузером, является пробел, он включает в себя:
Переносы строк
Переносы строк и пустые строки (которые представляют собой последовательность переносов строк) в коде HTML игнорируются браузером. Они составляют лишь единое пространство.
Чтобы реально вставить перенос строки вам нужно использовать элемент
:
Табуляция
Во всяком случае, как и обычный пробел, табуляция невидима. Она также игнорируется браузером:
Если вы хотите добавить пространство перед словом, вам придётся использовать CSS.
Если вы хотите закрыть элемент HTML, то должны сперва закрыть все его дочерние элементы.
Форматирование в виде дерева
Поскольку элементы HTML могут быть вложены друг в друга, вы должны следить за порядком, в котором они были открыты, так как это будет влиять на порядок, в котором они закрыты.
Из-за того, что может быть сложно следить за порядком, в котором были открыты элементы HTML, рекомендуется писать HTML в виде дерева:
Форматирование в виде дерева позволяет визуально воспроизвести уровень вложенности вашего кода HTML. Это позволяет легко увидеть, что:
Пишите HTML для себя, чтобы его читать
Табуляция, пустые строки, набор пробелов и переносы строк опускаются компьютером и все они превращаются в один пробел.
HTML-документ пишется и читается человеком, но компьютером только читается. Учитывая, что табуляция, пробелы и переносы строк не влияют на то, как браузер будет читать и впоследствии отображать веб-страницу, вы можете отформатировать свой документ наиболее читаемым для себя способом.
Нет конкретных правил, касающихся форматирования HTML, но есть неявные соглашения, в частности:
Урок №18. Базовое форматирование кода
Обновл. 11 Сен 2021 |
Пробелы относятся к символам, которые используются в форматировании кода, вместе с символами табуляции и, иногда, разрывом строки. Компилятор, как правило, игнорирует пробелы, но все же есть небольшие исключения.
В следующем примере все строки кода выполняют одно и то же:
Даже последний стейтмент с разрывом строки успешно скомпилируется.
Разрыв/перевод строки не допускается в цитируемом тексте:
Еще одним исключением, где компилятор обращает внимание на пробелы, являются однострочные комментарии: они занимают только одну строку. Перенос однострочного комментария на вторую строку вызовет ошибку компиляции, например:
Основные рекомендации
В отличие от других языков программирования, C++ не имеет каких-либо ограничений в форматировании кода со стороны программистов. Основное правило заключается в том, чтобы использовать только те способы, которые максимально улучшают читабельность и логичность кода.
Вот 6 основных рекомендаций:
Рекомендация №1: Вместо символа табуляции (клавиша Tab) используйте 4 пробела. В некоторых IDE по умолчанию используются три пробела в качестве одного символа табуляции — это тоже нормально (количество пробелов можно легко настроить в соответствующих пунктах меню вашей IDE).
Причиной использования пробелов вместо символов табуляции является то, что если вы откроете свой код в другом редакторе, то он сохранит правильные отступы, в отличие от использования символов табуляции.
Рекомендация №2: Открытие и закрытие фигурных скобок функции должно находиться на одном уровне на отдельных строках:
Хотя есть еще и следующий вариант (вы также можете его использовать):
Первый вариант хорош тем, что в случае возникновения ошибки несоответствия скобок, найти те самые проблемные скобки визуально будет проще.
Рекомендация №3: Каждый стейтмент функции должен быть с соответствующим отступом (клавиша Tab или 4 пробела):
Рекомендация №4: Строки не должны быть слишком длинными. 72, 78 или 80 символов — это оптимальный максимум строки. Если она будет длиннее, то её следует разбить на несколько отдельных строк:
Рекомендация №5: Если длинная строка разбита на части с помощью определенного оператора (например, std :: cout «This is a really, really, really, really, really, really, really, «
Рекомендация №6: Используйте пробелы и пропуски строк между стейтментами для улучшения читабельности вашего кода.
Язык C++ позволяет выбрать вам тот стиль форматирования вашего кода, в котором вам будет наиболее комфортно работать.
Поделиться в социальных сетях:
Комментариев: 27
Юрий, когда я напишу игру своей мечты, то пришлю вам её) Спасибо за труд
Пожалуйста) Буду ждать тогда вашу игру)
Я, конечно, не далеко не профи в программировании, мягко говоря, но логично предположить, что спор о скобочках решается просто — у нормальной конторы наверняка существует определенный стандарт по оформлению кода, проекта, да даже рабочего стола. Думаю скобочки (и прочее, ну вы поняли) лучше писать там, где их пишут все в вашем микроклимате. «Часть корабля, часть команды», так сказать )))
Использование пробелов заместо табуляции, на мой взгляд, является извратом. Мало когда написанный в команде или же для себя код будет открываться в другом редакторе.
Спасибо Юрий! Всё понятно и просто. За ваши труды вам воздастся!
«Мало когда будет открываться»==»Будет открываться». Поэтому лучше использовать только пробелы. Но это, конечно, пожалуй, наименее значимый фактор качества форматирования. Грамотное построение кода, грамотное комментирование, расстановка отступов и скобок дают наибольший вклад в читабельность.
Главное тут то, что подход с позиции «больше никто это читать не будет» изначально дефектен: наступит день и будут. А ещё более вероятное событие — что однажды понадобится самому пересматривать и вспоминать когда-то написанный и давно забытый код. И с привычкой писать как-попало и то и другое будет выглядеть печально.
А реально неудобства с табуляцией бывают в тех случаях, когда символы табуляции смешиваются с пробелами. Так или иначе, но на практике такое встречается и вот это как раз уже больше тянет на изврат.
PPS:
И самое главное: называйте идентификаторы по их смыслу, отвечая на вопрос: «что делает эта функция» и «что содержит эта переменная/константа». Это не только просто «улучшает читаемость», но и помогает в отладке. Если форматирование кода — это скорее к поиску опечаток и забытых скобок, т.е. тому, о чём подскажет добрый компилятор (но надо помнить, что не во всех языках он столь любезен), то осмысленное именование — это уже к отладке логики. Гораздо проще понять, верно-ли написана функция, выражение, и т.д., когда ясно, что она/оно должно делать или содержать. Потому ошибка — это и есть ситуация, когда действительное не совпадает с должным.
По вашему комментарию к пункту 2 есть также рекомендация, которую советую придерживаться новичкам особенно. ВСЕГДА ставить фигурные скобки, даже если оператор один. Во-первых читаемость лучше. Во-вторых, в рабочих проектах даже встречал, когда был один оператор, а потом потребовалось что-то добавить в обработку условия, про скобки благополучно не вспомнили, компилятор ошибки никакой не выдаёт. А в работу программу запустили через месяц и очень долго потом искали, а почему же работает не так, как надо. На эту же тему, кстати, почему обязательно надо использовать систему управления версиями, когда пишешь код.
Фигурные скобки — это т.н. «составной оператор». Соответственно если они ставятся, значит предполагается, что в них будет несколько операторов. И это надо понимать, а не просто бездумно писать какие-то скобочки и другие значки. Это в смысле новичков. И новичкам я бы посоветовал всегда думать над тем «какой смысл и назначение в языке у тех букв, знаков, операторов, конструкций и т.д., которые ты пишешь?», «соответствует-ли то, что ты используешь тому, что ты хочешь выразить?».
А по принципу «а если потом потребуется» можно наворотить такого, что при самом прекрасном форматировании кода никто просто не поймёт, за чем там всё это понаписано. Если человек не осознаёт, что и для чего он пишет, то ни какие ухищрения не помогут избежать кривого кода. Скорее наоборот, имхо. Ну и от того, чтобы банально где-то ступить, что-то забыть — от этого, имхо, тоже никто не застрахован. Но если код написан осмысленно (ключевое слово — осмысленно) и осмысленно прокомментирован, то не будет проблем с поиском явных ошибок.
ps: Комментарии в коде — это как избыточное кодирование в передаче данных. Этакая контрольная сумма. Если смысл, заявленный в комментарии не совпадает со смыслом, написанным в коде — значит где-то ошибка. То же самое и со смыслами в идентификаторах переменных, функций и т.д.
Поэтому рекомендация, которой я советую придерживаться особенно всем, — всегда и везде ставьте смысл.
Автор в этой статье начал молча использовать using namespace std, не предупредив, не объяснив что это и для чего, и в дальнейшем без объяснения причин и как это работает продолжает использовать.
Форматирование кода с помощью Prettier в Visual Studio Code
Published on November 2, 2020
Введение
Согласованное форматирование кода — сложная задача, но современные инструменты разработчиков позволяют автоматически обеспечивать согласованность базы кода вашей команды.
В этой статье мы настроим Prettier для автоматического форматирования кода в Visual Studio Code или VS Code.
Для демонстрации мы будем форматировать следующий код:
Если вы знакомы с форматированием кода, вы можете заметить некоторые упущения:
Предварительные требования
Для прохождения этого учебного модуля вам нужно будет загрузить и установить Visual Studio Code.
Шаг 1 — Использование команды форматирования документа
После установки расширения Prettier вы можете использовать его для форматирования вашего кода. Для начала выполним обзор, используя команду Format Document. Эта команда сделает ваш код более согласованным с отформатированными пробелами, переносами строк и кавычками.
Чтобы открыть палитру команд, вы можете использовать COMMAND + SHIFT + P в macOS или CTRL + SHIFT + P в Windows.
Выполните в палитре команд поиск по ключевому слову format и выберите Format Document.
Возможно, вам будет предложено выбрать формат для использования. Для этого нажмите кнопку Configure:
Теперь ваш код отформатирован с пробелами, переносами строк и единообразными кавычками:
Это работает и для файлов CSS. Вы можете превращать код с несогласованными отступами, скобками, разрывами строк и точками с запятой в хорошо отформатированный код. Например:
Будет переформатирован как:
Мы изучили эту команду, и теперь посмотрим, как можно реализовать ее автоматическое выполнение.
Шаг 2 — Форматирование кода при сохранении
До сих пор вам нужно было вручную запускать команды для форматирования кода. Чтобы автоматизировать этот процесс, вы можете выбрать в VS Code настройку, чтобы ваши файлы автоматически форматировались при сохранении. Это также гарантирует, что неформатированный код не попадет в систему контроля версий.
Чтобы изменить эту настройку, нажмите COMMAND + в macOS или CTRL + в Windows, чтобы открыть меню Settings (Настройки). Выполните в меню поиск Editor: Format On Save и убедитесь, что эта опция включена:
Теперь вы можете писать код как обычно, и он будет автоматически форматироваться при сохранении файла.
Шаг 3 — Изменение параметров конфигурации Prettier
Prettier выполняет много действий по умолчанию, но вы также можете внести индивидуальные изменения в его настройки.
Откройте меню Settings (Настройки). Выполните поиск Prettier. Вы увидите список всех параметров, которые вы можете изменить:
Вот несколько наиболее распространенных параметров:
Недостаток использования меню встроенных параметров VS Code заключается в том, что при этом не обеспечивается согласованность между разработчиками в вашей команде.
Шаг 4 — Создание файла конфигурации Prettier
Если вы измените настройки VS Code, у другого разработчика может оказаться совершенно иная конфигурация. Вы можете обеспечить единство форматирования в своей команде, создав файл конфигурации для вашего проекта.
Вот пример простого файла конфигурации в формате JSON:
Более конкретную информацию о файлах конфигурации можно найти в документации по Prettier. После создания такого файла и его добавления в проект вы можете быть уверены, что все члены команды используют одинаковые правила форматирования.
Заключение
Иметь согласованный код — очень хорошая практика. Это особенно полезно при работе над проектом с несколькими участниками. Согласование конфигурации делает код более удобочитаемым и понятным. Это позволяет уделить больше времени решению технических проблем, а не тратить время на исправление отступов.
Prettier обеспечивает согласованность форматирования кода и позволяет автоматизировать этот процесс.
Кафедра Информатики и Математического Обеспечения
Цели хорошего форматирования кода
Многие решения о том, как должно выглядеть хорошее форматирование, представляют собой субъективные эстетические оценки; часто можно достичь одной и той же цели по разному, но хорошая схема форматирования должна делать следующие вещи:
Стиль форматирования
Базовый стандарт оформления кода: Kernighan & Ritchie (K&R)
Данный стиль использует стиль расстановки скобок при котором скобка переносится на новую строку при определении пространств имен (namespaces), классов (classes), функций, в остальных случаях скобка остается на той же строке, где располагается часть кода, к которой она (скобка) принадлежит. Отступ в данном стиле равняется 4-м пробелам.
Расстановка скобок как в стиле (K&R) соответствует формату явных блоков для управляющих структур.
Способы форматирования
Неотображаемые символы, к которым относятся пробелы, знаки табуляции, переводы строк и пустые строки, — это основное средство для демонстрации структуры программы.
Способ применения неотображаемых символов — группировка взаимосвязанных выражений, т.е. выделение связанных между собой конструкций в отдельный блок. Кроме необходимости группировать взаимосвязанные операторы, очень важно отделять несвязанные выражения друг от друга. Для этого можно использовать пустые строки. Они позволяют продемонстрировать организацию программы. Вы можете использовать их для деления групп взаимосвязанных операторов, отделения методов друг от друга и выделения комментариев.
Отступы применяются для демонстрации логической структуры программы. Как правило, операторы выделяются отступами, когда они следуют после некоторого выражения, от которого они логически зависят.
Скобки применяются для разъяснения выражений, состоящих из двух и более членов. Возможно, в скобках нет нужды, но они добавляют ясности в код.
Форматируйте блоки из одного оператора единообразно. Блоком из одного оператора называется единственный оператор, следующий за управляющей структурой. Причем форматирование с использованием скобок более предпочтително.
Форматирование строк, длина операторов/выражений
Старайтесь не превышать длину строки в 80 символов. Если аргументы функции не помещаются на одной строке, их следует разбивать на несколько строк.
В сложных выражениях размещайте каждое условие на отдельной строке.
Делайте так, чтобы незавершенность выражения была очевидна, например, помещая оператор соединяющий выражения в начале новой строки (см. также пример выше).
Не выравнивайте правые части выражений присваивания, в дальнейшем поддержка такого форматирования может привести только к пустой трате времени.
Пример (не нужное выравнивание):
Всегда располагайте один оператор на строке. Это даст следующее:
Функции
Операторы if/else, do, while
Расстановка скобок cоответствует формату явных блоков.
Расставляйте скобки так, что бы не было «висячих» операторов else, лучше всегда выделять скобками блоки кода, даже когда скобки могут быть опущены. else if следует писать так:
do / while следует писать так:
Операции
Необходимо вставлять пробел между операциями присваивания, логическими и арифметическими операциями.
Не оставлять пробела после унарной операции.
Правила именования
Комментирование
Начинайте каждый файл с комментария, информации о правах и лицензии:
или более краткая версия:
Комментарии описывают, что делает код, а не как, во всяком случае пока из кода можно легко понять его работу.
Заголовочные файлы
В заголовочный файл можно помещать следующее:
В заголовочном файле не должно быть:
В простейшем варианте определения функций и данных помещаются в подходящее число исходных файлов а типы данных и необходимые для их взаимодействия функции, описываются в одном заголовочном файле, который включается во все остальные файлы.
Для того, что бы не проиcходило повторного включения заголовочного файла, включайте в него следующие инструкции:
Настройка GNU Emacs
Если вы пользуетесь редактором GNU Emacs, то добавьте в файл
/.emacs следующие строки для того, чтобы описанный в этом документе стиль использовался по умолчанию при редактировании исходного кода на языке C:
Руководство по оформлению HTML/CSS кода от Google
От переводчика
С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.
Введение
Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.
Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.
Общие правила оформления
Протокол
Не указывайте протокол при включении ресурсов на страницу.
Отсутствие протокола делает ссылку относительной, что предотвращает смешивание ресурсов из разных протоколов и незначительно уменьшает размер файлов.
Не рекомендуется:
Рекомендуется:
Не рекомендуется:
Рекомендуется:
Общее форматирование
Отступы
Всегда используйте для отступа два пробела.
Не используйте табуляцию и не смешивайте табуляцию с пробелами.
Регистр
Всегда пишите в нижнем регистре.
Весь код должен быть написан в нижнем регистре: Это относится к названиям элементов, названиям атрибутов, значениям атрибутов (кроме текста/ CDATA ), селекторам, свойствам и их значениям (кроме текста).
Пробелы в конце строки
Убирайте пробелы в конце строки.
Пробелы в конце строк не обязательны и усложняют использование diff.
Не рекомендуется:
Рекомендуется:
Общие мета правила
Кодировка
Используйте UTF-8 (без BOM).
Убедитесь, что ваш редактор использует кодировку UTF-8 без метки порядка байтов (BOM).
(Вы можете узнать больше о кодировках, и о том, как их использовать, по этой ссылке: Наборы символов и кодировки в XHTML, HTML CSS (англ.).)
Комментарии
По возможности поясняйте свой код, где это необходимо.
Используйте комментарии, чтобы пояснить свой код: что он делает, за что отвечает, и почему используется выбранное решение.
(Этот пункт не обязателен, потому что нет смысла ожидать, что код всегда будет хорошо задокументирован. Полезность комментирования зависит от сложности проекта и может различаться для HTML и CSS кода. )
Задачи
Правила оформления HTML
Тип документа
Валидность HTML
По возможности используйте валидный HTML.
Используйте валидный HTML код, кроме случаев, когда использование не позволяет достичь размера файла, необходимого для нужного уровня производительности.
Используйте такие инструменты как W3C HTML validator (англ.) чтобы проверить валидность кода.
Валидность — это важное и при этом измеряемое качество кода. Написание валидного HTML способствует изучению технических требований и ограничений и обеспечивает правильное использование HTML.
Не рекомендуется:
Рекомендуется:
Семантика
Используйте HTML так, как это было задумано.
Используйте элементы (Иногда неверно называемые “тегами”) по назначению: заголовки для заголовков, p для абзацев, a для ссылок и т.д.
Это облегчает чтение, редактирование и поддержку кода.
Не рекомендуется:
Рекомендуется:
Альтернатива для мультимедиа
Всегда указывайте альтернативное содержимое для мультимедиа.
(Если для картинки alt избыточен, или она используется только в декоративных целях в местах, где нельзя использовать CSS, используйте пустой альтернативный текст alt=»» )
Не рекомендуется:
Рекомендуется:
Разделение ответственности
Разделяйте структуру, оформление и поведение.
Держите структуру (разметка), оформление (стили) и поведение (скрипты) раздельно и постарайтесь свести взаимодействие между ними к минимуму.
Убедитесь, что документы и шаблоны содержат только HTML, и что HTML служит только для задания структуры документа. Весь код, отвечающий за оформление, перенесите в файлы стилей, а код отвечающий за поведение — в скрипты.
Старайтесь сократить их пересечения к минимуму, включая в шаблоны минимальное количество файлов стилей и скриптов.
Отделение структуры от представления и поведения помогает облегчить поддержку кода. Изменение шаблонов и HTML-документов всегда занимает больше времени чем изменение файлов стилей или скриптов.
Не рекомендуется:
Рекомендуется:
Ссылки-мнемоники
Не используйте ссылки-мнемоники.
Единственное исключение из этого правила — служебные символы HTML (например и & ) а так же вспомогательные и “невидимые” символы (например неразрывный пробел).
Не рекомендуется:
Рекомендуется:
Необязательные теги
Не используйте необязательные теги. (не обязательно)
Для уменьшения размера файлов и лучшей читаемости кода можно опускать необязательные теги. В спецификации HTML5 (англ.) есть список необязательных тегов.
(Может потребоваться некоторое время для того, чтобы этот подход начал использоваться повсеместно, потому что это сильно отличается от того, чему обычно учат веб-разработчиков. С точки зрения, согласованности, и простоты кода лучше всего опускать все необязательные теги, а не некоторые из них).
Не рекомендуется:
Рекомендуется:
Атрибут ‘type’
Не указывайте атрибут type при подключении стилей и скриптов в документ.
Не используйте атрибут type при подключении стилей (кроме вариантов когда используется что-то кроме CSS) и скриптов (кроме вариантов когда это не JavaScript).
Указывать атрибут type в данном случае не обязательно потому что HTML5 использует text/css (англ.) и text/javascript (англ.) по умолчанию. Это будет работать даже в старых браузерах.
Не рекомендуется:
Рекомендуется:
Не рекомендуется:
Рекомендуется:
Правила форматирования HTML
Форматирование
Выделяйте новую строку для каждого блочного, табличного или списочного элемента и ставьте отступы для каждого дочернего элемента.
Независимо от стилей заданных для элемента (CSS позволяет изменить поведение элемента с помощью свойства display ), переносите каждый блочный или табличный элемент на новую строку.
Также ставьте отступы для всех элементов вложенных в блочный или табличный элемент.
(Если у вас возникнут сложности из-за пробельных символов между списочными элементами, допускается поместить все li элементы в одну строку. Линту [утилита для проверки качества кода прим. пер.] рекомендуется в данном случае выдавать предупреждение вместо ошибки.
Рекомендуется:
Рекомендуется:
Рекомендуется:
Правила оформления CSS
Валидность CSS
По возможности используйте валидный CSS-код.
Кроме случаев, где необходим браузеро-зависимый код, или ошибок валидатора, используйте валидный CSS код.
Используйте такие инструменты как W3C CSS Валидатор (англ.) для проверки своего кода.
Валидность — это важное и при этом измеряемое качество кода. Написание валидного CSS помогает избавиться от избыточного кода и обеспечивает правильное использование таблиц стилей…
Идентификаторы и названия классов
Используйте шаблонные или имеющие смысл имена классов и идентификаторы.
Вместо использования шифров, или описания внешнего вида элемента, попробуйте в имени класса или идентификатора выразить смысл его создания, или дайте ему шаблонное имя…
рекомендуется выбирать имена, отражающие сущность класса, потому что их проще понять и, скорее всего, не понадобится менять в будущем.
Шаблонные имена — это просто вариант названия для элементов, у которых нет специального предназначения или которые не отличаются от своих братьев и сестер. Обычно они необходимы в качестве “Помощников.”
Использование функциональных или шаблонных имен уменьшает необходимость ненужных изменений в документа или шаблонах.
Не рекомендуется:
Рекомендуется:
Названия идентификаторов и классов
Для идентификаторов и классов используйте настолько длинные имена, насколько нужно, но настолько короткие, насколько возможно.
Попробуйте сформулировать, что именно должен делать данный элемент, при этом будьте кратки насколько возможно.
Такое использование классов и идентификаторов вносит свой вклад в облегчение понимания и увеличение эффективности кода.
Не рекомендуется:
Рекомендуется:
Селекторы типа
Избегайте использование имен классов или идентификаторов с селекторами типа (тега) элемента.
Кроме случаев когда это не обходимо (например с классами-помощниками), не используйте названия элементов с именами классов или идентификаторами.
Не рекомендуется:
Рекомендуется:
Сокращенные формы записи свойств
Используйте сокращенные формы записи свойств, где возможно.
CSS предлагает множество различных сокращенных (англ.) форм записи (например font ), которые рекомендуется использовать везде где это возможно, даже если задается только одно из значений.
Использование сокращенной записи свойств полезно для большей эффективности и лучшего понимания кода.
Не рекомендуется:
Рекомендуется:
0 и единицы измерения
Не указывайте единицы измерения для нулевых значений
Не указывайте единицы измерения для нулевых значений если на это нет причины.
0 в целой части дроби
Не ставьте “0” в целой части дробных чисел.
Кавычки в ссылках
Не используйте кавычки в ссылках
Шестнадцатеричные названия цветов
Используйте трехсимвольную шестнадцатеричную запись где это возможно.
Трехсимвольная шестнадцатиричная запись для цветов короче и занимает меньше места.
Не рекомендуется:
Рекомендуется:
Префиксы
Предваряйте селекторы уникальными для текущего приложения префиксами. (не обязательно)
В больших проектах, а так же в коде, который будет использоваться для других проектов или в других сайтах, используйте префиксы (в качестве пространств имен) для идентификаторов и имен классов. Используйте короткие уникальные названия с последующим дефисом.
Использование пространств имен позволяет предотвратить конфликты имен и может облегчить обслуживание сайта. Например при поиске и замене.
Разделители в классах и идентификаторах
Разделяйте слова в идентификаторах и именах классов с помощью дефиса.
Не используйте ничего, кроме дефиса, для соединения слов и сокращений в селекторах, чтобы повысить удобство чтения и легкость понимания кода.
Не рекомендуется:
Рекомендуется:
Избегайте использования информации о версии браузеров, или CSS “хаков”— сперва попробуйте другие способы.
Кажется заманчивым бороться с различиями в работе разных браузеров с помощью CSS-фильтров, хаков или прочих обходных путей. Все эти подходы могут быть рассмотрены лишь в качестве последнего средства, если вы хотите получить эффективную и легко поддерживаемую кодовую базу. Проще говоря, допущение хаков и определения браузера повредит проекту в долгосрочной перспективе, так как это означает, что проект идет по пути наименьшего сопротивления. Что облегчает использование хаков и позволяет использовать их все чаще и чаще, что в результате приведет к слишком частому их использованию.
Правила форматирования CSS
Упорядочивание объявлений
Сортируйте объявления по алфавиту.
Задавайте объявления в алфавитном порядке, чтобы получить согласованный код, с которым легко работать.
При сортировке игнорируйте браузерные префиксы. При этом, если для одного свойства используются несколько браузерных префиксов, они также должны быть отсортированы (например -moz должен быть перед —webkit )
Отступы в блоках.
Всегда ставьте отступы для содержимого блоков.
Всегда ставьте отступы для любого блочного содержимого (англ.), Например для правил внутри правил или объявлений, чтобы отобразить иерархию и облегчить понимание кода.
После объявлений
Ставьте точку с запятой после каждого объявления.
После каждого объявления ставьте точку с запятой для согласованности кода и облегчения добавления новых свойств.
Не рекомендуется:
Рекомендуется:
После названий свойств
Используйте пробелы после двоеточий в объявлениях.
Всегда используйте один пробел после двоеточия (но не до) в объявлениях, для порядка в коде.
Не рекомендуется:
Рекомендуется:
Отделение селектора и объявления
Отделяйте селекторы и объявления переносом строки.
Начинайте каждый селектор или объявление с новой строки.
Не рекомендуется:
Рекомендуется:
Разделение правил
Разделяйте правила переносом строки.
Всегда ставьте перенос строки между правилами.
Мета правила CSS
Группировка правил
Группируйте правила и обозначайте группы комментарием. (не обязательно)
По возможности объединяйте правила в группы. Обозначайте группы комментариями и разделяйте переносом строки.
Заключение
Если вы редактируете код, потратьте несколько минут, чтобы разобраться в том, как он написан. Если математические операторы обособлены пробелами, делайте то же самое. Если комментарии окружены скобочками или черточками, сделайте то же со своими комментариями.
Идея этого руководства в том, чтобы создать общий словарь, который позволил бы разработчикам сконцентрироваться на том что они хотят выразить, а не на том, как.
Мы предлагаем единые правила оформления позволяющие писать код в одном стиле, но стиль кода, уже используемый в проекте, также важен.
Если ваш код будет сильно отличаться от существующего, это может сбить читающего с ритма и затруднить чтение. Постарайтесь этого избежать.
Примечание от переводчика
Хочется еще отметить, что Google ориентируется в первую очередь на большие высоконагруженные проекты, где каждый байт дорог, поэтому стоит учитывать, что если они рекомендуют начинать каждый селектор с новой строки, или использовать пробелы вместо табов, то это в первую очередь подразумевает, что код будет обязательно минифицирован и сжат до использования на сайте.