Convention de dénomination des actifs (images, css, js)?

J'ai encore du mal à trouver une bonne convention de dénomination pour les actifs tels que les images, les fichiers js et css utilisés dans mes projets Web.

Donc, mon courant serait:

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

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

Images: {imageType}-{name}.{imageExtension}
{imageType} est l'un de ces

• icône (par exemple, icône de point d'interrogation pour le contenu de l'aide)
• img (par exemple une image d'en-tête insérée via un <img />élément)
• bouton (par exemple, un bouton d'envoi graphique)
• bg (l'image est utilisée comme image d'arrière-plan en css)
• sprite (l'image est utilisée comme image d'arrière-plan en css et contient plusieurs "versions")

Exemple noms seraient: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifetc.

Alors, qu'en pensez-vous et quelle est votre convention de dénomination ?

Je place des fichiers CSS dans un dossier css, Javascript dans js, des images dans images, ... Ajoutez des sous-dossiers comme bon vous semble. Pas besoin de convention de dénomination au niveau des fichiers individuels.

Je l' ai remarqué beaucoup de développeurs frontend se éloignent de csset jsen faveur styleset scriptsparce qu'il ya généralement d' autres choses là - dedans, comme .less, .stylet .sassainsi que, pour certains, .coffee. Le fait est que l'utilisation de sélections technologiques spécifiques dans le choix de l'organisation des dossiers est une mauvaise idée, même si tout le monde le fait. Je vais continuer à utiliser la norme que je vois de ces développeurs très respectés:

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

Et leurs équivalents de construction de destination, qui sont parfois préfixés en destfonction de ce qu'ils construisent:

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

Cela permet à ceux qui veulent rassembler tous les fichiers (plutôt que de casser un srcrépertoire) de le garder et de garder les choses clairement associées pour ceux qui éclatent.

Je vais en fait un peu plus loin et j'ajoute

• scripts/before
• scripts/after

Lesquels sont regroupés en deux main-before.min.jset main-after.min.jsscripts, un pour l'en-tête (avec des éléments essentiels de normalizeet modernizrqui doivent être exécutés tôt, par exemple) et afterpour la dernière chose dans le corps puisque ce javascript peut attendre. Ceux-ci ne sont pas destinés à la lecture, tout comme la page principale de Google.

S'il y a des scripts et des feuilles de style qui ont du sens pour minimiser et laisser les liens seuls en raison d'une approche de gestion du cache particulière qui est prise en charge dans les règles de construction.

De nos jours, si vous n'utilisez pas un processus de construction quelconque, tel que gulp ou grunt , vous n'atteignez probablement pas la plupart des objectifs de performances centrés sur le mobile que vous devriez probablement envisager.

/Les atouts/
  / Css
  /Images
  / Javascript (ou Script)
    / Minifié
    /La source

C'est la meilleure structure que j'ai vue et celle que je préfère. Avec les dossiers, vous n'avez pas vraiment besoin de préfixer votre CSS, etc. avec des noms descriptifs.

Pour les grands sites où le CSS peut définir de nombreuses images d'arrière-plan, une convention de dénomination de fichier pour ces actifs est très pratique pour apporter des modifications ultérieurement.

Par exemple:

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

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

Nous avons également discuté de l'ajout du type d'élément, mais je ne sais pas à quel point cela est utile et pourrait éventuellement induire en erreur pour les modifications futures requises:

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

Vous pouvez le nommer comme ceci:

/ assets / css / - Pour les fichiers CSS

/ assets / font / - Pour les fichiers de polices. (La plupart du temps, vous pouvez simplement accéder aux polices google pour rechercher des polices utilisables.)

/ assets / images / - Pour les fichiers Images.

/ assets / scripts / ou / assets / js / - Pour les fichiers JavaScript.

/ assets / media / - Pour la vidéo et divers. des dossiers.

Vous pouvez également remplacer "assets" par le nom du dossier "resource" ou "files" et conserver le nom de ses sous-dossiers. Eh bien, avoir une structure de dossier de commande comme celle-ci n'est pas très important, le seul important est que vous devez simplement organiser vos fichiers selon leur format. comme créer un dossier "/ css /" pour les fichiers CSS ou "/ images /" pour les fichiers image.

Tout d' abord, je divise dans des dossiers: css, js, img.

Dans les fichiers css et js, je préfixe les fichiers avec le nom du projet car votre site peut inclure des fichiers js et css qui sont des composants, cela indique clairement où les fichiers sont spécifiques à votre site ou liés aux plugins.

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

D'autres fichiers pourraient être comme

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

Enfin, les images sont divisées par leur utilisation.

• img/btn/submit.png un bouton
• img/lgo/mysite-logo.png un logo
• img/bkg/header.gif un arrière-plan
• img/dcl/top-left-widget.jpg un élément de décalcomanie
• img/con/portait-of-something.jpg une image de contenu

Il est important de garder les images organisées car il peut y en avoir plus de 100 et peuvent facilement être totalement mélangées et nommées de manière confuse.

J'ai tendance à éviter tout ce qui est générique, comme ce que smdrager a suggéré. "mysite.main.css" ne veut rien dire du tout.

Qu'est-ce que "mysite" ?? Celui sur lequel je travaille? Si c'est le cas, alors c'est vraiment évident, mais cela me fait déjà penser à ce que cela pourrait être et si c'est aussi évident!

Qu'est-ce que "Main"? Le mot "Main" n'a aucune définition en dehors de la connaissance des codeurs de ce qu'il y a dans ce fichier css.

Bien que cela soit correct dans certains scénarios, évitez également les noms comme "top" ou "left": "top-nav.css" ou "top-main-logo.png".
Vous pourriez finir par vouloir utiliser la même chose ailleurs, et mettre une image dans un pied de page ou dans le contenu de la page principale appelé "top-banner.png" est très déroutant!

Je ne vois aucun problème à avoir un bon nombre de feuilles de style pour permettre une convention de dénomination décente pour décrire ce que css est dans le fichier donné.
Le nombre dépend entièrement de la taille du site et de ses fonctions, et du nombre de blocs différents sur le site.

Je ne pense pas que vous ayez besoin d'indiquer "CSS" ou "STYLE" dans les noms de fichiers css, car le fait qu'il se trouve dans le dossier "css" ou "styles" et qu'il ait une extension .csset surtout que ces fichiers ne sont appelés que dans la <head>région, je sais assez clairement ce qu'ils sont.

Cela dit, je fais cela avec des fichiers de bibliothèque, JS et de configuration (etc.) par exemple libSomeLibrary.php ou JSSomeScript.php. Comme les fichiers PHP et JS sont inclus ou utilisés dans divers domaines d'autres fichiers, il est utile d'avoir des informations sur l'objectif principal du fichier dans le nom.

par exemple: voir le nom du fichier require('libContactFormValidation.php');est utile. Je sais que c'est un fichier de bibliothèque (lib) et d'après le nom ce qu'il fait.

Pour les dossiers d'images, j'ai généralement images/content-images/et images/style-images/. Je ne pense pas qu'il soit nécessaire de séparer davantage, mais encore une fois, cela dépend du projet.

Ensuite, chaque image sera nommée en fonction de ce qu'elle est, et encore une fois, je ne pense pas qu'il soit nécessaire de définir le fichier comme une image dans le nom du fichier. Les tailles peuvent être utiles, en particulier lorsque les images ont des tailles différentes.

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

Une bonne règle à suivre est la suivante: si un nouveau développeur venait aux fichiers, serait-il assis à se gratter la tête pendant des heures, ou comprendrait-il probablement ce que font les choses et n'aura besoin que d'un peu de temps pour faire des recherches (ce qui est inévitable)?

Cependant, comme quoi que ce soit de ce genre, l'une des règles les plus importantes à suivre est simplement la constance !
Assurez-vous de suivre la même logique et les mêmes modèles dans toutes vos conventions de dénomination!
Des simples noms de fichiers css aux fichiers de bibliothèque PHP en passant par les noms de table et de colonne de base de données.

C'est une vieille question, mais toujours d'actualité.

Ma recommandation actuelle est d'aller avec quelque chose dans ces lignes:

• actifs (ou actifs-web ou actifs-www); celui-ci est destiné au contenu statique utilisé par le client (navigateur)
  • Les données; des fichiers xml et d'autres choses
  • polices
  • images
  • médias
  • modes
  • scripts
  • lib (ou tiers); celui-ci est destiné au code que vous ne créez ni ne modifiez, les bibliothèques telles que vous les obtenez
  • lib-modded (ou modifié par une tierce partie); celui-ci est destiné au code que vous ne deviez pas modifier, mais que vous deviez modifier, comme appliquer une solution de contournement / un correctif pendant que le fournisseur de bibliothèque le publie
• inc (ou actifs-serveur ou actifs-local); celui-ci est destiné au contenu utilisé côté serveur, à ne pas utiliser par le client, comme les bibliothèques dans des langages comme PHP ou les scripts serveur, comme les fichiers bash
  • polices
  • lib
  • lib-modded

J'ai marqué en gras les habituels, les autres ne sont pas du contenu habituel.

La raison de la division principale est qu'à l'avenir, vous pouvez décider de serveur les actifs Web à partir d'un CDN ou de restreindre l'accès client aux actifs du serveur, pour des raisons de sécurité.

Dans les répertoires lib que j'utilise pour décrire les bibliothèques, par exemple

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [chemin]
      • [nom de la bibliothèque / du projet]
        • vX.YZ (version)

vous pouvez donc remplacer la bibliothèque par une nouvelle, sans casser le code, permettant également aux futurs responsables du code, y compris vous-même, de trouver la bibliothèque et de la mettre à jour ou d'obtenir de l'aide.

Aussi, n'hésitez pas à organiser le contenu à l'intérieur en fonction de son utilisation, de sorte que les images / logos et images / icônes sont des répertoires attendus dans certains projets.

En passant, le nom des actifs est significatif, non seulement pour signifier que nous avons des ressources, mais aussi pour dire que les ressources doivent avoir une valeur pour le projet et non un poids mort.

La BBC a des tonnes de normes relatives au développement Web.

Leur standard est assez simple pour les fichiers CSS:

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

Vous pourrez peut-être trouver quelque chose d'utile sur leur site principal:

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