Konwencja nazewnictwa zasobów (obrazy, css, js)?

Wciąż staram się znaleźć dobrą konwencję nazewnictwa dla zasobów, takich jak obrazy, pliki js i css, używanych w moich projektach internetowych.

Tak więc mój obecny byłby:

CSS: style-{name}.css
przykłady: style-main.css, style-no_flash.css, style-print.cssetc.

JS: script-{name}.js
przykłady: script-main.js, script-nav.jsetc.

Obrazy: {imageType}-{name}.{imageExtension}
{imageType} to którykolwiek z tych

• ikona (np. ikona znaku zapytania dla treści pomocy)
• img (np. obraz nagłówka wstawiony przez <img />element)
• przycisk (np. graficzny przycisk przesyłania)
• bg (obraz jest używany jako obraz tła w css)
• sprite (obraz jest używany jako obraz tła w css i zawiera wiele „wersji”)

PRZYKŁAD nazwy to: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifetc.

Co o tym myślisz i jaka jest Twoja konwencja nazywania ?

Umieszczam pliki CSS w folderze css, JavaScript w js, obrazy w images... Dodaj podfoldery według własnego uznania. Brak konieczności stosowania konwencji nazewnictwa na poziomie pojedynczych plików.

Zauważyłem wiele programistów frontend odchodzą od cssi jsna korzyść styles, a scriptsponieważ nie ma zazwyczaj inne rzeczy tam, takie jak .less, .styli .sassjak również dla niektórych .coffee. Faktem jest, że używanie określonych technologii przy wyborze organizacji folderów jest złym pomysłem, nawet jeśli wszyscy to robią. Nadal będę używać standardu, który widzę od tych szanowanych programistów:

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

Oraz ich docelowe odpowiedniki kompilacji, które czasami są poprzedzone przedrostkiem w destzależności od tego, co budują:

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

Pozwala to tym, którzy chcą zebrać wszystkie pliki razem (zamiast srcrozbijać katalog), zachować to i zachować wyraźne skojarzenia z tymi, które się wyłamują.

Właściwie idę trochę dalej i dodaję

• scripts/before
• scripts/after

Które są wygładzane na dwa main-before.min.jsi main-after.min.jsskrypty, jeden dla nagłówka (na przykład z podstawowymi elementami normalizei modernizrktóre muszą działać wcześnie) i afterdla ostatniej rzeczy w treści, ponieważ ten javascript może czekać. Nie są one przeznaczone do czytania, podobnie jak główna strona Google.

Jeśli istnieją skrypty i arkusze stylów, których zminimalizowanie i pozostawienie linków w spokoju ma sens, ze względu na szczególne podejście do zarządzania pamięcią podręczną, które jest uwzględnione w regułach kompilacji.

W dzisiejszych czasach, jeśli nie używasz jakiegoś procesu kompilacji, takiego jak łyk lub chrząknięcie , prawdopodobnie nie osiągasz większości celów wydajnościowych zorientowanych na urządzenia mobilne, które prawdopodobnie powinieneś rozważyć.

/Majątek/
  / Css
  /Zdjęcia
  / Javascript (lub Script)
    / Zminimalizowany
    /Źródło

To najlepsza konstrukcja, jaką widziałem i którą preferuję. W przypadku folderów tak naprawdę nie musisz poprzedzać swojego kodu CSS itp. Opisowymi nazwami.

W przypadku dużych witryn, w których css może definiować wiele obrazów tła, konwencja nazewnictwa plików dla tych zasobów jest bardzo przydatna do późniejszego wprowadzania zmian.

Na przykład:

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

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

Omówiliśmy również dodanie typu elementu, ale nie jestem pewien, jak pomocne jest to i może wprowadzać w błąd w przypadku przyszłych wymaganych zmian:

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

Możesz to nazwać tak:

/ asset / css / - dla plików CSS

/ asset / font / - dla plików czcionek. (Przeważnie możesz po prostu przejść do czcionek Google, aby wyszukać przydatne czcionki).

/ asset / images / - dla plików graficznych.

/ asset / scripts / lub / asset / js / - dla plików JavaScript.

/ asset / media / - W przypadku plików wideo i misc. akta.

Możesz również zastąpić „zasoby” nazwą folderu „zasób” lub „pliki” i zachować nazwę jego podfolderów. Cóż, posiadanie takiej struktury folderów zamówienia nie jest bardzo ważne, jedyne ważne jest to, że musisz po prostu uporządkować pliki według ich formatu. na przykład tworzenie folderu „/ css /” dla plików CSS lub „/ images /” dla plików graficznych.

Po pierwsze, ja podzielić na folderach: css, js, img.

W ramach css i js poprzedzam pliki nazwą projektu, ponieważ witryna może zawierać pliki js i css, które są komponentami, dzięki czemu jest jasne, gdzie pliki są specyficzne dla Twojej witryny lub odnoszą się do wtyczek.

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

Inne pliki mogą być takie jak

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

Wreszcie obrazy są podzielone według ich zastosowania.

• img/btn/submit.png przycisk
• img/lgo/mysite-logo.png logo
• img/bkg/header.gif tło
• img/dcl/top-left-widget.jpg element kalkomanii
• img/con/portait-of-something.jpg obraz treści

Ważne jest, aby obrazy były uporządkowane, ponieważ może być ich ponad 100 i można je łatwo całkowicie wymieszać i nazwać myląco.

Staram się unikać wszystkiego, co ogólne, na przykład tego, co sugerował smdrager. „mysite.main.css” w ogóle nic nie znaczy.

Co to jest „mysite”? Ten nad którym pracuję? Jeśli tak, to naprawdę oczywiste, ale już zastanawiałem się, co to może być i czy to takie oczywiste!

Co to jest „Main”? Słowo „Main” nie ma definicji poza wiedzą programisty o tym, co znajduje się w tym pliku css.

Chociaż w niektórych sytuacjach jest to w porządku, unikaj też nazw takich jak „top” lub „left”: „top-nav.css” lub „top-main-logo.png”.
Może się zdarzyć, że będziesz chciał użyć tego samego w innym miejscu, a umieszczenie obrazu w stopce lub w treści strony głównej o nazwie „top-banner.png” jest bardzo mylące!

Nie widzę żadnego problemu z posiadaniem dużej liczby arkuszy stylów, aby umożliwić przyzwoitą konwencję nazewnictwa, aby zobrazować, co css znajduje się w danym pliku.
Ile zależy całkowicie od rozmiaru witryny i jej funkcji oraz liczby różnych bloków w witrynie.

Wydaje mi się, że nie musisz w ogóle wpisywać „CSS” lub „STYLE” w nazwach plików css, ponieważ znajduje się w folderze „css” lub „styles” i ma rozszerzenie .cssi głównie dlatego, że te pliki są zawsze nazywane w <head>okolicy wiem całkiem wyraźnie, czym one są.

To powiedziawszy, robię to z plikami bibliotek, JS i config (itp.). np. libSomeLibrary.php lub JSSomeScript.php. Ponieważ pliki PHP i JS są dołączane lub używane w różnych obszarach w innych plikach, przydatne jest posiadanie informacji o głównym celu pliku w nazwie.

np .: require('libContactFormValidation.php');Przydatne jest sprawdzenie nazwy pliku . Wiem, że to plik biblioteki (lib) i po nazwie, co robi.

W przypadku folderów z obrazami zwykle mam images/content-images/i images/style-images/. Nie sądzę, aby było konieczne dalsze rozdzielanie, ale znowu zależy to od projektu.

Następnie każdy obraz zostanie nazwany zgodnie z tym, czym jest, i znowu nie sądzę, aby istniała potrzeba definiowania pliku jako obrazu w nazwie pliku. Rozmiary mogą być przydatne, zwłaszcza gdy obrazy mają różne rozmiary.

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

Dobra zasada, której należy przestrzegać, brzmi: jeśli nowy programista przyjdzie do plików, czy będzie siedział godzinami drapiąc się po głowie, czy też prawdopodobnie zrozumie, co się dzieje i potrzebuje tylko trochę czasu na badanie (co jest nieuniknione)?

Jednak jak w każdym przypadku, jedną z najważniejszych zasad, których należy przestrzegać, jest po prostu stałość !
Upewnij się, że przestrzegasz tej samej logiki i wzorców we wszystkich konwencjach nazewnictwa!
Od prostych nazw plików css, przez pliki bibliotek PHP po tabele bazy danych i nazwy kolumn.

To stare pytanie, ale wciąż aktualne.

Moja obecna rekomendacja jest taka, aby wybrać coś w tych wierszach:

• aktywa (lub asset-web lub asset-www); ten jest przeznaczony do treści statycznych używanych przez klienta (przeglądarkę)
  • dane; niektóre pliki xml i inne rzeczy
  • czcionki
  • zdjęcia
  • głoska bezdźwięczna
  • style
  • skrypty
  • lib (lub innej firmy); ten jest przeznaczony dla kodu, którego nie tworzysz ani nie modyfikujesz, bibliotek w stanie, w jakim je otrzymasz
  • lib-modded (lub zmodyfikowany przez inną firmę); ten jest przeznaczony dla kodu, którego nie miałeś modyfikować, ale musiałeś, na przykład zastosować obejście / poprawkę w międzyczasie, dostawca biblioteki wydaje go
• inc (lub asset-server lub asset-local); ten jest przeznaczony dla treści używanych po stronie serwera, nie może być używany przez klienta, jak biblioteki w językach takich jak PHP lub skrypty serwera, takie jak pliki bash
  • czcionki
  • lib
  • lib-modded

Pogrubioną czcionką zaznaczyłem zwykłe, pozostałe nie są zwykłą treścią.

Przyczyną głównego podziału jest to, że w przyszłości możesz zdecydować się na serwer zasobów internetowych z CDN lub ograniczyć dostęp klienta do zasobów serwera ze względów bezpieczeństwa.

Na przykład w katalogach lib opisuję biblioteki

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [ścieżka]
      • [nazwa biblioteki / projektu]
        • vX.YZ (wersja)

więc możesz wymienić bibliotekę na nową, bez łamania kodu, umożliwiając również przyszłym opiekunom kodu, w tym sobie, znalezienie biblioteki i zaktualizowanie jej lub uzyskanie wsparcia.

Możesz również uporządkować zawartość zgodnie z jej wykorzystaniem, więc obrazy / logo i obrazy / ikony są oczekiwanymi katalogami w niektórych projektach.

Na marginesie, nazwa zasobów ma znaczenie, nie tylko oznacza to, że mamy tam zasoby, ale także oznacza, że ​​zasoby, które się tam znajdują, muszą mieć wartość dla projektu, a nie wagę własną.

BBC ma mnóstwo standardów dotyczących tworzenia stron internetowych.

Ich standard jest dość prosty dla plików CSS:

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

Możesz znaleźć coś przydatnego na ich głównej stronie:

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