Правила іменування об’єктів (images, css, js)?

Я все ще намагаюся знайти хорошу конвенцію щодо імен для таких ресурсів, як зображення, js та css-файли, що використовуються в моїх веб-проектах.

Отже, мій струм буде:

CSS: style-{name}.css
приклади: style-main.css, style-no_flash.css, і style-print.cssт.д.

JS: script-{name}.js
приклади: script-main.js, і script-nav.jsт.д.

Зображення: {imageType}-{name}.{imageExtension}
{imageType} є будь-яким із цих

• піктограми (наприклад, піктограма знака запитання для вмісту довідки)
• img (наприклад, зображення заголовка, вставлене через <img />елемент)
• кнопка (наприклад, графічна кнопка надсилання)
• bg (зображення використовується як фонове зображення в css)
• спрайт (зображення використовується як фонове зображення в css і містить кілька "версій")

Приклад найменування будуть: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, і bg-gradient.gifт.д.

Отже, що ви думаєте і яка ваша угода про іменування ?

Я розміщую файли CSS у папці css, Javascript у js, зображення у images, ... Додаю підпапки, як вважаю за потрібне. Немає потреби в будь-якій конвенції щодо імен на рівні окремих файлів.

Я помітив, що багато розробників зовнішнього інтерфейсу відходять від cssі jsна користь stylesі scriptsтому , що , як правило , інші речі там, такі як .less, .styl, і .sass, а також, для деяких .coffee. Факт полягає в тому, що використання конкретних технологій у виборі організації папок - погана ідея, навіть якщо це роблять усі. Я й надалі використовуватиму стандарт, який бачу від цих шанованих розробників:

• src/html
• src/images
• src/styles
• src/styles/fonts
• src/scripts

І їх призначення збирають еквіваленти, які іноді мають префікс, destзалежно від того, що вони будують:

• ./
• images
• styles
• styles/fonts
• scripts

Це дозволяє тим, хто хоче об’єднати всі файли (а не розбивати srcкаталог), зберігати це і зберігати речі, чітко пов’язані з тими, хто все-таки зривається.

Я насправді піду трохи далі і додаю

• scripts/before
• scripts/after

Які згладжуються удвох main-before.min.jsі main-after.min.jsсценарії, один для заголовка (з основними елементами normalizeі, modernizrякі повинні запускатися раніше, наприклад), і afterдля останньої речі в тілі, оскільки цей javascript може зачекати. Вони не призначені для читання, подібно до головної сторінки Google.

Якщо є сценарії та таблиці стилів, які має сенс зменшити та залишити пов’язаними наодинці через певний підхід управління кешем, про який піклуються в правилах збірки.

У наші дні, якщо ви не використовуєте якийсь процес збірки, такий як залп чи бурчання , ви, мабуть, не досягаєте більшості цілей ефективності, орієнтованих на мобільні пристрої, які ви, мабуть, повинні розглянути.

/ Активи /
  / Css
  / Зображення
  / Javascript (або сценарій)
    / Зменшене
    / Джерело

Це найкраща структура, яку я бачив, і та, яку я віддаю перевагу. У папках вам насправді не потрібно префіксувати ваш CSS тощо описовими назвами.

Для великих сайтів, де css може визначити багато фонових зображень, дозвіл імен файлів для цих ресурсів дуже зручний для подальших змін.

Наприклад:

[component].[function-description].[filetype]

footer.bkg-image.png
footer.copyright-gradient.png

Ми також обговорювали додавання типу елемента, але я не впевнений, наскільки це корисно і може ввести в оману для майбутніх необхідних змін:

[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png

Ви можете назвати це так:

/ assets / css / - Для файлів CSS

/ assets / font / - Для файлів шрифтів. (Здебільшого ви можете просто перейти до шрифтів Google для пошуку корисних шрифтів.)

/ assets / images / - для файлів зображень.

/ assets / scripts / or / assets / js / - Для файлів JavaScript.

/ assets / media / - Для відео та іншого. файлів.

Ви також можете замінити "активи" на ім'я папки "ресурс" або "файли" і зберегти ім'я його підпапок. Добре мати таку структуру папок замовлення не дуже важливо, важливо лише те, що вам просто потрібно розташувати файли за форматом. як створення папки "/ css /" для файлів CSS або "/ images /" для файлів зображень.

По- перше, я ділю в папки: css, js, img.

У межах css та js я додаю префікси до файлів із назвою проекту, оскільки ваш сайт може містити файли js та css, які є компонентами, це дає зрозуміти, де саме файли для вашого сайту, чи стосуються плагінів.

css/mysite.main.css css/mysite.main.js

Інші файли можуть бути такими

js/jquery-1.6.1.js js/jquery.validate.js

Нарешті, зображення поділяються за їх використанням.

• img/btn/submit.png кнопку
• img/lgo/mysite-logo.png логотип
• img/bkg/header.gif фон
• img/dcl/top-left-widget.jpg елемент наклейки
• img/con/portait-of-something.jpg вміст зображення

Важливо підтримувати впорядкованість зображень, оскільки їх може бути більше 100, і їх можна легко змішати і заплутати.

Я схильний уникати чогось загального, наприклад, того, що запропонував smdrager. "mysite.main.css" взагалі нічого не означає.

Що таке "мізит" ?? Цей, над яким я працюю? Якщо так, то очевидно насправді, але це вже змушує мене думати, що це може бути, і якщо це очевидно!

Що таке "Головне"? Слово "Main" не має визначення поза знаннями кодерів про те, що знаходиться в цьому файлі css.

Хоча нормально в деяких сценаріях, уникайте імен, таких як "top" або "left" теж: "top-nav.css" або "top-main-logo.png".
Можливо, ви захочете використати те саме в іншому місці, і розміщення зображення в нижньому колонтитулі або в вмісті головної сторінки під назвою "top-banner.png" дуже заплутане!

Я не бачу жодної проблеми з наявністю великої кількості таблиць стилів, щоб дозволити гідну конвенцію іменування, щоб зобразити, що css знаходиться у даному файлі.
Скільки їх повністю залежить від розміру сайту та його функцій, а також скільки різних блоків на сайті.

Я не думаю, що вам взагалі потрібно вказувати "CSS" або "STYLE" в іменах файлів css, оскільки той факт, що він знаходиться в папці "css" або "стилі" і має розширення, .cssі головним чином, оскільки ці файли лише колись називаються в <head>районі я досить чітко знаю, що це таке.

Тим не менш, я роблю це з бібліотекою, JS та файлами конфігурації (і т.д.). наприклад, libSomeLibrary.php або JSSomeScript.php. Оскільки файли PHP та JS включаються або використовуються в різних областях інших файлів, корисно мати інформацію про те, що головне призначення файлу в імені.

наприклад: Перегляд імені файлу require('libContactFormValidation.php');корисний. Я знаю, що це бібліотечний файл (lib) і з назви, що він робить.

Для папок із зображеннями я зазвичай маю images/content-images/і images/style-images/. Я не думаю, що потрібно більше розлучатись, але знову ж таки це залежить від проекту.

Тоді кожне зображення буде називатися відповідно до того, що воно є, і знову ж таки, я не думаю, що є необхідність визначати файл, це зображення в назві файлу. Розміри можуть бути корисними, особливо коли зображення мають різний розмір.

site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
тощо

Хорошим правилом, яке слід дотримуватися, є: якщо новий розробник прийде до файлів, чи сидить він, чухаючи голову годинами, чи, можливо, зрозуміє, що робить, і потребує лише трохи часу на дослідження (чого не уникнути)?

Однак, як нічого подібного, одне з найважливіших правил - це просто сталість !
Переконайтеся, що ви дотримуєтеся тієї самої логіки та закономірностей, незважаючи на всі ваші правила імен!
Від простих імен файлів css, до файлів бібліотеки PHP до назв таблиць та стовпців бази даних.

Це старе запитання, але все ще актуальне.

Моя поточна рекомендація полягає у використанні чогось із цих рядків:

• активи (або активи-павутина або активи-www); цей призначений для статичного вмісту, що використовується клієнтом (браузером)
  • дані; деякі xml-файли та інше
  • шрифти
  • зображення
  • ЗМІ
  • стилі
  • сценарії
  • lib (або сторонній); цей призначений для коду, який ви не створюєте та не модифікуєте, для бібліотек у міру їх отримання
  • lib-модифікований (або сторонній модифікований); цей призначений для коду, який ви не очікували модифікувати, але мусили, як, наприклад, застосовуючи обхідний шлях / виправлення, тим часом постачальник бібліотеки випускає його
• inc (або сервер активів, або актив локальний); цей призначений для вмісту, що використовується на стороні сервера, а не для використання клієнтом, як бібліотеки на таких мовах, як PHP або скрипти сервера, наприклад файли bash
  • шрифти
  • lib
  • lib-модифікований

Я виділив жирним шрифтом звичайні, інші - не звичайний зміст.

Причиною основного поділу є те, що в майбутньому ви можете вирішити сервер веб-активів із CDN або обмежити доступ клієнта до серверних активів з міркувань безпеки.

Наприклад, у каталогах lib я описую бібліотеки, наприклад

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [шлях]
      • [назва бібліотеки / проекту]
        • vX.YZ (версія)

так що ви можете замінити бібліотеку новою, не порушуючи код, а також дозволяючи майбутнім розробникам коду, включаючи вас, знаходити бібліотеку та оновлювати її або отримувати підтримку.

Крім того, сміливо впорядковуйте вміст усередині відповідно до його використання, тому зображення / логотипи та зображення / піктограми - це очікувані каталоги в деяких проектах.

Як допоміжне зауваження, назва активів є значущою, і не тільки означає, що ми маємо ресурси там, але означає, що ресурси там повинні мати цінність для проекту, а не мертву вагу.

BBC має безліч стандартів, що стосуються веб-розробки.

Їх стандарт досить простий для файлів CSS:

http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml

Ви можете знайти щось корисне на їх головному сайті:

http://www.bbc.co.uk/guidelines/futuremedia/