1. 16. Именование сущностей
При написании кода в любом языке программирования каждый разработчик неизбежно сталкивается с вопросом правильного именования.
Если разработчик пишет код на JS, PHP, Python или любом другом языке программирования — ему приходится придумывать названия для переменных, функций, классов и так далее.
В нашем случае мы занимаемся вёрсткой, а в вёрстке нужно придумывать классы для элементов, id, а также названия для файлов (картинки, шрифты, файлы разметки, папки с файлами и тому подобное).
В этой статье постараемся разобраться, как можно хорошо именовать сущности и есть ли в этом вообще какой-то смысл.
Зачем именовать правильно
Можно подумать так: «Классы могут состоять даже из одной буквы. Зачем стараться выдумывать названия тогда, если и так будет всё отлично работать?» (вместо слова «классы» можно подставить что угодно — id, картинки, файлы разметки, переменные и так далее, суть не изменится). Почему бы действительно не писать вот так:
И действительно, такой код без проблем отработает в браузере: заголовок станет красным, а абзац — зеленым. Всё понятно, элементы простые, несложно догадаться, что к чему.
Но если посмотреть на чуть более сложную структуру:
Понятного мало. Какие-то div с буквами, совершенно не ясно, для чего они, может половину из них можно вовсе удалить и ничего не произойдет? В общем, чтобы понять, что это за элемент — проще будет посмотреть на сайт через «Инструменты разработчика» в браузере. А это значит надо открыть страницу с этим кодом, найти в «Инструментах разработчика» именно этот участок и начать нажимать на каждый из элементов, чтобы разобраться, какой div за что отвечает. Кажется, слишком долгий процесс.
Взглянем на эту же часть разметки, но с другими названиями классов:
Первый элемент — называется дословно «контент-конструктор» (content-constructor). Ага, в контенте сайта есть какой-то конструктор. Смотрим дальше: pizza pizza-foundation-big-tomato переводим — «пицца пицца-основа-большой-помидор». Уже вырисовывается картина — это конструктор пиццы, а данная разметка предназначена для отображения большой пиццы с основой из томатов (ну вероятнее всего томатный соус на пицце).
Хорошо, посмотрим следующие элементы. pizza-wrapper — обёртка пиццы, скорее всего какой-то служебный элемент (название wrapper чаще всего используется, когда нужно сделать обёртку, которая будет отвечать, возможно, за flex-контейнер, или быть position: relative; для того, чтобы расставить элементы внутри с помощью absolute).
Смотрим далее: три элемента, у которых по одному одинаковому классу и по одному разному. Зачем так сделано?
Одинаковые классы чаще всего устанавливают, чтобы написать разным элементам идентичные стили, а разные дополнительные классы в них делают для того, чтобы описать отличия от «оригинала» (тех самых идентичных стилей). Проще всего понять на примере. Представим, что нам нужно сверстать три кнопки:
Они полностью идентичны по размерам, скруглению углов, обводке, и другим параметрам, но у них разные фоновые цвета. Значит можно задать один класс общий для всех трёх кнопок и в этом классе будут общие параметры, а для отличительных черт (разных фоновых цветов) задать разные классы. Код этого участка будет такой:
Чтобы не писать каждой кнопке: button-red, button-blue, button-green каждый раз border, width, мы написали один общий класс и просто в «отличительных» классах описали то самое отличие от оригинала. Это сокращает количество кода и улучшает понимание того, что же у нас тут написано.
Вернёмся к примеру с пиццей:
Тот самый одинаковый класс pizza-filling (или если перевести — пицца-начинка) явно задает какие-то общие свойства для всех трёх div. Отличительные классы задают то самое отличие от оригинала (как это было в кнопках): pizza-filling-ananas — пицца-начинка-ананас, pizza-filling-bacon — пицца-начинка-бекон, pizza-filling-cheddar — пицца-начинка-чеддер (конечно, имеется в виду сыр чеддер). Из этого мы можем сделать вывод, что каждый из этих div отвечает за отображение той или иной начинки в конструкторе пиццы.
То есть посмотрев только на разметку, мы смогли определить, что перед нами разметка для отображения конструктора пиццы. Более того, понятно даже какой элемент за что отвечает. Нам не пришлось заходить на сайт и искать через инструменты разработчика элемент. Всё вполне понятно прямо в коде. Именно для этого нужно именование — сократить время на понимание кода.
Во всех языках программирования принцип именования абсолютно тот же. К примеру, в Javascript (или любом подобном, где есть функции, переменные), правильное именование поможет понять, какое действие выполняет функция, даже не читая код самой функции, или какое итоговое значение будет в переменной после манипуляций с ней.
Ошибки при именовании
Разобраться с тем, как правильно именовать сущности, проще всего разобрав ошибки в именовании.
Один из примеров мы уже разобрали выше — когда совершенно неясно, что за элемент перед нами: <div class="c">. Название класса слишком короткое, чтобы разобраться в сути элемента. Но можно написать и более подробно, целым словом, а понятнее при этом не станет. К примеру просто назвать <div class="container">. Что за контейнер? Для чего он? Вроде служебное название какое-то. Хорошо, для центровщиков на сайте часто используется такой класс, но допустим по разметке видно, что он точно не для центрирования. Тогда зачем он? Возникает сразу множество вопросов.
Или к примеру <li class="item">. Item переводится как пункт. Что за пункт? Ну понятно, пункт списка. Какого? Надо посмотреть обертку <ul> или <ol>, что там за название класса. Хорошо, но это лишнее действие — искать родителя. А вдруг родитель вообще в другом файле? (разметку можно поделить на отдельные файлы, это делается для удобства работы с отдельными компонентами страниц на больших проектах). Получается название item слишком общее, слишком неточное, чтобы понимать, что же делает элемент.
Таких общих названий много. Даже то самое wrapper— слишком общее название, хотя мы его использовали в примере выше. Но в чём отличие примера выше и почему там wrapper всё же использовался? Название класса было pizza-wrapper, то есть слово wrapper было частью названия класса и если посмотреть на всё название целиком — становится понятно, что это за элемент.
Из этого можно сделать вывод: названия, которые не передают сути кода (что делает код, какой участок описывает, к какому результату приведёт) — лучше не использовать или использовать вместе с дополнительными словами, которые внесут большую ясность.
Действует ли для именования файлов тот же принцип? Конечно.
Представим, что у нас на сайте есть картинки котиков, и все котики разные. Нам нужно вставить эти картинки в разметку. Насколько удобно будет искать изображение рыжего большого кота, если все названия картинок имеют только цифры 1.jpg, 2.jpg, 3.jpg, … 10.jpg? Нужно будет открывать каждую картинку и искать этого рыжего кота. Насколько было бы проще видеть название cat-big-orange.jpg, cat-small-white.jpg и так далее. За счёт названия мы быстро можем определить, где нужное нам изображение. А если именовать c-b-o.jpg? Может, разработчику сайта это название и будет понятно прямо сейчас, но с вероятностью 99% другому разработчику, который будет дорабатывать этот сайт, данное название ни о чём не скажет. Более того, даже когда тот разработчик, который делал данный сайт и сам так называл картинку, вернётся через полгода и будет дорабатывать данный сайт, скорее всего, сам забудет, что он именно так именовал картинку рыжего большого кота.
На самом деле, из этого можно сделать ещё один важный вывод: не нужно именовать с помощью сокращений, которые будут понятны только вам. Да, возможно, кто-то ещё поймет, что c-b-o.jpg — это картинка с большим рыжим котом, или что класс p-f-b (или вообще pfb) — это начинка «бекон» для пиццы (p — pizza, f — filling, b — bacon). Даже в этой статье пришлось расшифровывать, что же такое pfb. Представьте, каково будет работать с кодом, в котором куча подобных сокращений.
Хорошо, сокращения, слишком общие названия — да, это непонятно и лучше так не делать. А если написать так: <b class="cena-tovara-na-sklade">10р.</b>? Или допустим название частично на английском и частично транслитом: <button class="remove-from-sklads">Удалить</button>?
Транслит — тоже плохо, хотя вроде бы с первого взгляда понятно, что тут написано. Но почему плохо тогда? Дело в том, что есть такая особенность у человека — усталость от чтения. Так как код нам как раз необходимо читать — усталость от чтения транслита приходит очень быстро. Проблема состоит в том, что в наборе эталонов слов человека нет шаблона для слова sklads. Приходится читать его по-английски, вокализировать, находить аналогию в русском языке. Это увеличивает время первого прочтения примерно в три раза.
Можно возразить: «Но я не знаю английский, слово filling мне не понятно, если было бы написано nachinka — мне не пришлось бы идти в переводчик и смотреть значение слова». Программирование неразрывно связано с английским языком и основная масса разработчиков знает этот язык, пусть и далеко не в совершенстве. Конечно, во время учёбы может быть понятнее транслит, но при дальнейшей работе придётся использовать чистый английский, поэтому лучше сразу начинать писать правильно, заодно пополнять постепенно словарный запас.
Можно ещё долго обсуждать проблемы транслита в именовании, по этому поводу даже есть большие статьи, но мы этого касаться не будем. Скажем только, что это тоже плохо и так делать не нужно.
Также одна из часто встречающихся проблем — слишком длинные названия. К примеру <h3 class="hotel-list-item-title-small-green">. Необходимости так подробно описывать данный элемент нет. Почему — это очень долго читается, долго пишется и плохо запоминается (а запоминать нужно, для того чтобы сделать такой же элемент далее в коде).
Возможно, достаточно будет названия hotel-title, а если такое уже есть — подумать над тем, как можно сделать более уникальное название для заголовков, либо сделать общие классы для всех заголовков одного типа, а отличительные черты писать в дополнительных классах. В таком случае можно будет снова использовать эту часть кода в другом месте, что крайне удобно. Например: <h3 class="main-title hotel-card-title">.
Как именовать правильно
Чтобы правильно задать название любой сущности (будь то класс в разметке, папка на компьютере, название файла или что-то другое) — нужно не допускать ошибок, перечисленных выше, но при этом дополнительно будет хорошо придерживаться общепринятых норм:
По возможности исключить цифры из названия. Вернёмся к котикам. cat1.jpg, cat2.jpg … cat10.jpg — найти того самого большого рыжего кота сложно. Нужно открывать и просматривать картинки. Для классов, переменных, функций и прочего действует тот же принцип. Иногда хочется назвать элемент как <li class="product-1">, первый продукт в списке. Но поменялась сортировка товаров (была от самого дешевого к самому дорогому, а стала наоборот — от дорогого к дешевому) и уже первый продукт совсем другой. Стоит подумать, точно ли всегда без исключений элемент, переменная, файл, в целом любая сущность будет первой, или есть вероятность, что она может стать другой по порядку. Со словами first, second и тому подобное стоит также быть осторожными.
Правильно разделять слова. Можно отразить правильно суть — «cat big orange.jpg» или <div class="pizzafillingbacon">. Но в первом случае проблема — пробел является спецсимволом, браузер не понимает пробел как пустоту, а переводит его в код %20. То же самое происходит и с многими другими спецсимволами и даже с кириллицей. Поэтому стоит избегать спецсимволов и кириллицы. Во втором случае pizzafillingbacon — одно целое слово и читать его неудобно. Для разделения можно использовать дефисы или знаки подчёркивания: pizza-filling-bacon или pizza_filling_bacon. Для именования картинок, папок, любых других файлов подчёркивания и дефисы также подходят. Но важно использовать один тип разделителя, а не несколько. Либо дефис, либо подчёркивание (про именование методом БЭМ, когда название может иметь и нижние подчёркивания и дефисы, подробно будет рассказано на курсе «HTML и CSS. Адаптивная вёрстка и автоматизация»).
Сокращать общепринятыми словами: btn — кнопка, img — картинка, wrap — обёртка и другие. Список часто употребляемых слов для именования, а также сокращений можно посмотреть тут.
В именовании классов и id использовать всегда строчные буквы. Для файлов лучше также придерживаться только строчных букв. Почему так — сервера, на которых располагаются файлы сайта, могут быть настроены по-разному. Некоторые сервера считают, что Cat-Big-Orange.jpg — то же самое, что и cat-big-orange.jpg, а некоторые считают, что это два совершенно разных названия, поэтому лучше всегда именовать строчными. В языках программирования иногда применяются названия с большой буквы, но правила именования в этих языках будут рассмотрены в соответствующих курсах.
Итоги
Основные ошибки именования:
Слишком общие названия, не передающие сути.
Непонятные сокращения.
Транслит.
Основные правила:
Как можно меньше использовать цифры или любое указание на порядок, если это не требуется.
Разделители слов — дефисы
-и нижние подчёркивания_.Общепринятые слова и сокращения.
Использование строчных букв.
Не использовать спецсимволы, пробелы, кириллицу.
Хороший код всегда понятен, даже если сильно не вчитываться, а также его можно прочитать быстро, не испытывая трудностей.
Last updated
