Комментарии 17
Отличная статься, все четко структурировано! Часто именно такого структурирования не хватает новичкам, которые вообще не заморачиваются с корректными наименованиями.
Отличная статья - сам в свое время долго вырабатывал принципы нейминга - в начале пути бы мне очень пригодилась. Но есть и минус - дергающийся глаз если кто-то рядом не разделяет твоих принципов нейминга...
Спасибо. Было полезно прочитать.
Небесполезно. Годная статья.
Структурно описали :)
Про нейминг файлов напишите?
Там есть интересные проблемы: признак ставить как префикс (regular-user.js, хорошо для стиля, нативно) или суффикс (user-regular.js, хорошо для сортировки и групировки вокруг сущности user), структуру папки-файлы, если у меня UserService , то его ложить в структуру юзера или сервисов, ... ?
А как относитесь к использованию "типа предмета"? Например, много переменных, но одни из них являются DOM элементами, причем различного класса. Следует ли их выделять из массы? Или константы.
Интересный вопрос. Вы имеете в виду работу с DOM в контексте нативного JS?
Я думаю, что в таком случае, "тип предмета" может быть ассоциирован с "признаком предмета", поскольку "тип" это именно тот "признак" по которому вы хотите отделить определенные переменные от других. Например, DOMuserNameInput, DOMsubmitButton.
Тут большую роль играет именно ваша мотивация. Если есть необходимость отличать переменную или группу переменных от других, используя определенный признак, то добавляем этот признак в начало.
Если признаков несколько, то они должны идти в порядке -- от более общего к более частному.
А атрибуты, напротив, от более частного к более общему.
Например: DOMactiveUserNameInput
Предмет -- User
Признаки: DOM, active. DOM более общее понятие, чем active, поэтому идет в начале.
Атрибуты: Name, Input. Input более общее понятие, чем name, поэтому идет в конце.
Да, имею в виду нативный JS. Например, есть элемент select, есть textarea, есть button и так далее. В коде, честно скажу, переменная, имеющая ссылку на элемент, прямо просится назваться так, чтобы было понятно, чем она является.
Если интересно, я в своем коде, при именовании переменных использую немного другой стиль: от общего у частному и в конце указываю тип. Сущности разделяю знаком подчеркивания, имена сущностей с маленькой буквы. Например:
Например, logoutButton, usersAddModal_createButton, usersEditModal_cancelButton, usersAddModal_userNameInput. Если скоуп небольшой, то можно отбрасывать общие сущности типа usersAddModal, оставлять только createButton.
Насчет констант, обычно название констант пишется в UPPER_SNAKE_CASE, то есть uppercase + snake_case, поэтому в названии константы обозначать, что эта переменная -- константа, нет необходимости.
Никто не сказал про ID vs Id ? У самого не хватает аргументов как правильно. getUserId вроде нормально выглядит
Чистая вкусовщина по поводу того, как использовать аббревиатуры и сокращения в названиях функций/переменных. В DOM спокойно используются аббревиатуры заглавными буквами, например, innerHTML, insertAdjacentHTML, HTMLElement, DOMContentLoaded. Но мне не нравится когда названия сущностей сливаются.
Нужен какой-то визуальный разделитель, например, название сущности начинать с заглавной (если она не первая), а остальные строчными. То есть я за вариант getUserId и против getUserID.
Кмк, в ID нет смысла - это не аббревиатура, а просто сокращение. Пользуюсь всегда Id.
Более того, даже аббревиатуры пишу в camel style: Snils, Xml и т.п. На мой взгляд приятнее смотрится )))
Оба варианта имеют право на жизнь, но ID для меня выглядит более олдскульным. В сознании id уже не воспринимается аббревиатурой.
Хороший принцип, хотя у меня часто соблазн поставить предмет на первое место: user, userActive, userActiveId, userActiveName таким образом user ставится типа namespace.
Если ставить признак перед атрибутом, то признак будет ассоциироваться с атрибутом, и это может запутать. Хотя я согласна с тем, что предмет в начале может быть удобен в определенных ситуациях, например для автозаполнения. Однако, я бы посоветовала использовать встроенные в язык средства для определения неймспейсов, такие как модули, классы, объекты или сами непосредственно неймспейсы
Основные принципы хорошего нейминга