Convenzione di denominazione per le risorse (immagini, css, js)?

Sto ancora lottando per trovare una buona convenzione di denominazione per risorse come immagini, file js e css utilizzati nei miei progetti web.

Quindi, la mia corrente sarebbe:

CSS: style-{name}.css
esempi: style-main.css, style-no_flash.css, style-print.cssetc.

JS: script-{name}.js
esempi: script-main.js, script-nav.jsetc.

Immagini: {imageType}-{name}.{imageExtension}
{imageType} è una di queste

• icona (ad es. icona punto interrogativo per il contenuto della guida)
• img (ad esempio un'immagine di intestazione inserita tramite <img />elemento)
• pulsante (ad es. un pulsante di invio grafico)
• bg (l'immagine è usata come immagine di sfondo in css)
• sprite (l'immagine è usata come immagine di sfondo in css e contiene più "versioni")

Esempio nomi sarebbero: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifetc.

Allora, cosa ne pensi e qual è la tua convenzione di denominazione ?

Metto i file CSS in una cartella css, Javascript in js, immagini in images, ... Aggiungi sottocartelle come meglio credi. Non è necessaria alcuna convenzione di denominazione a livello di singoli file.

Ho notato un sacco di sviluppatori frontend si stanno allontanando da csse jsin favore di stylese scriptsperché non v'è in genere altra roba lì, come ad esempio .less, .style .sasscosì come, per alcuni, .coffee. Il fatto è che utilizzare selezioni tecnologiche specifiche nella scelta dell'organizzazione delle cartelle è una cattiva idea anche se lo fanno tutti. Continuerò a utilizzare lo standard che vedo da questi sviluppatori altamente rispettati:

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

E i loro equivalenti di build di destinazione, che a volte sono preceduti da un prefisso a destseconda di ciò che stanno costruendo:

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

Ciò consente a coloro che desiderano mettere insieme tutti i file (piuttosto che creare un file src directory) di mantenerli e mantenere le cose chiaramente associate per quelli che si rompono.

In realtà vado un po 'oltre e aggiungo

• scripts/before
• scripts/after

Che vengono divisi in due main-before.min.js e main-after.min.jsscript, uno per l'intestazione (con elementi essenziali di normalizee modernizrche devono essere eseguiti in anticipo, ad esempio) e afterper l'ultima cosa nel corpo poiché quel javascript può aspettare. Questi non sono destinati alla lettura, proprio come la pagina principale di Google.

Se ci sono script e fogli di stile che ha senso minimizzare e lasciare collegati da soli a causa di un particolare approccio di gestione della cache che viene curato nelle regole di compilazione.

Oggigiorno, se non utilizzi un processo di creazione di qualche tipo, come gulp o grunt , probabilmente non stai raggiungendo la maggior parte degli obiettivi di rendimento incentrati sui dispositivi mobili che dovresti probabilmente prendere in considerazione.

/Risorse/
  / Css
  /Immagini
  / Javascript (o Script)
    / Minificato
    /Fonte

È la migliore struttura che ho visto e quella che preferisco. Con le cartelle non è necessario anteporre al CSS ecc. Nomi descrittivi.

Per i siti di grandi dimensioni in cui CSS potrebbe definire molte immagini di sfondo, una convenzione di denominazione dei file per tali risorse è molto utile per apportare modifiche in seguito.

Per esempio:

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

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

Abbiamo anche discusso l'aggiunta del tipo di elemento, ma non sono sicuro di quanto sia utile e potrebbe essere fuorviante per le future modifiche richieste:

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

Puoi chiamarlo in questo modo:

/ assets / css / - Per i file CSS

/ assets / font / - Per i file di font. (Per lo più puoi semplicemente andare su Google Fonts per cercare caratteri utilizzabili.)

/ assets / images / - Per i file di immagini.

/ assets / scripts / o / assets / js / - Per i file JavaScript.

/ assets / media / - Per video e varie. File.

Puoi anche sostituire "risorse" con il nome della cartella "risorsa" o "file" e mantenere il nome delle sue sottocartelle. Bene, avere una struttura di cartelle di ordini come questa non è molto importante, l'unica importante è che devi solo organizzare i tuoi file in base al suo formato. come creare una cartella "/ css /" per i file CSS o "/ images /" per i file di immagine.

In primo luogo, io divido in cartelle: css, js, img.

All'interno di css e js, aggiungo il prefisso ai file con il nome del progetto perché il tuo sito potrebbe includere file js e css che sono componenti, questo rende chiaro dove i file sono specifici per il tuo sito o relativi a plugin.

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

Altri file potrebbero essere come

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

Infine le immagini sono divise in base al loro utilizzo.

• img/btn/submit.png un bottone
• img/lgo/mysite-logo.png un logo
• img/bkg/header.gif un sottofondo
• img/dcl/top-left-widget.jpg un elemento decalcomania
• img/con/portait-of-something.jpg un'immagine di contenuto

È importante mantenere le immagini organizzate poiché possono essercene più di 100 e possono essere facilmente mescolate completamente e denominate in modo confuso.

Tendo ad evitare tutto ciò che è generico, come quello suggerito da smdrager. "mysite.main.css" non ha alcun significato.

Cos'è "mysite" ?? Questo su cui sto lavorando? Se è così allora ovvio davvero, ma mi fa già pensare a cosa potrebbe essere e se è così ovvio!

Cos'è "Main"? La parola "Main" non ha alcuna definizione al di fuori della conoscenza del programmatore di ciò che è all'interno di quel file css.

Anche se va bene in certi scenari, evita anche nomi come "top" o "left": "top-nav.css" o "top-main-logo.png".
Potresti finire per voler usare la stessa cosa altrove e inserire un'immagine in un piè di pagina o all'interno del contenuto della pagina principale chiamato "top-banner.png" è molto confuso!

Non vedo alcun problema nell'avere un buon numero di fogli di stile per consentire una convenzione di denominazione decente per rappresentare ciò che css è all'interno del file dato.
Quanti dipendono interamente dalle dimensioni del sito, dalle sue funzioni e dal numero di blocchi diversi presenti sul sito.

Non penso che sia necessario indicare "CSS" o "STILE" nei nomi dei file css, poiché il fatto che si trovi nella cartella "css" o "styles" e ha un'estensione di .csse principalmente poiché questi file sono chiamati sempre e solo in <head>zona so abbastanza chiaramente cosa sono.

Detto questo, lo faccio con i file di libreria, JS e di configurazione (ecc.). ad esempio libSomeLibrary.php o JSSomeScript.php. Poiché i file PHP e JS sono inclusi o utilizzati in varie aree all'interno di altri file, è utile avere informazioni su quale sia lo scopo principale del file all'interno del nome.

es: vedere il nome del file require('libContactFormValidation.php');è utile. So che è un file di libreria (lib) e dal nome cosa fa.

Per le cartelle di immagini, di solito ho images/content-images/e images/style-images/. Non penso che ci sia bisogno di ulteriori separazioni, ma ancora una volta dipende dal progetto.

Quindi ogni immagine verrà denominata in base a ciò che è, e ancora una volta non penso che sia necessario definire che il file sia un'immagine all'interno del nome del file. Le dimensioni possono essere utili, soprattutto quando le immagini hanno dimensioni diverse.

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

Una buona regola da seguire è: se un nuovo sviluppatore si avvicinasse ai file, si siederebbe a grattarsi la testa per ore o probabilmente capirebbe cosa fa e avrebbe bisogno solo di un po 'di tempo per la ricerca (il che è inevitabile)?

Come qualcosa del genere, tuttavia, una delle regole più importanti da seguire è semplicemente la costanza !
Assicurati di seguire la stessa logica e gli stessi schemi in tutte le tue convenzioni di denominazione!
Da semplici nomi di file CSS, a file di libreria PHP a nomi di colonne e tabelle di database.

Questa è una vecchia domanda, ma ancora valida.

La mia raccomandazione attuale è di andare con qualcosa in queste righe:

• asset (o assets-web o assets-www); questo è inteso per contenuto statico utilizzato dal client (browser)
  • dati; alcuni file xml e altre cose
  • caratteri
  • immagini
  • media
  • stili
  • script
  • lib (o di terze parti); questo è inteso per il codice che non crei o modifichi, le librerie man mano che le ottieni
  • modificato da lib (o modificato da terze parti); questo è inteso per codice che non dovevi modificare, ma che dovevi, come applicare una soluzione alternativa / correzione nel frattempo il fornitore della libreria lo rilascia
• inc (o assets-server o assets-local); questo è inteso per il contenuto utilizzato lato server, per non essere utilizzato dal client, come le librerie in linguaggi come PHP o gli script del server, come i file bash
  • caratteri
  • lib
  • modificato da lib

Ho segnato in grassetto i soliti, gli altri non sono contenuti usuali.

Il motivo della divisione principale è che in futuro potrai decidere di server le risorse web da un CDN o limitare l'accesso client alle risorse del server, per motivi di sicurezza.

All'interno delle directory lib che uso per essere descrittivo sulle librerie, per esempio

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [sentiero]
      • [nome libreria / progetto]
        • vX.YZ (versione)

così puoi sostituire la libreria con una nuova, senza rompere il codice, consentendo anche ai futuri manutentori del codice, incluso te stesso, di trovare la libreria e aggiornarla o ottenere supporto.

Inoltre, sentiti libero di organizzare il contenuto all'interno in base al suo utilizzo, quindi immagini / loghi e immagini / icone sono directory previste in alcuni progetti.

Come nota a margine, il nome delle risorse è significativo, non solo significa che abbiamo risorse lì dentro, ma significa che le risorse lì dentro devono essere di valore per il progetto e non peso morto.

La BBC ha tonnellate di standard relativi allo sviluppo web.

Il loro standard è abbastanza semplice per i file CSS:

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

Potresti riuscire a trovare qualcosa di utile sul loro sito principale:

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