¿Convención de nomenclatura para activos (imágenes, css, js)?

Todavía estoy luchando por encontrar una buena convención de nomenclatura para activos como imágenes, archivos js y css utilizados en mis proyectos web.

Entonces, mi corriente sería:

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

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

Imágenes: ¿ {imageType}-{name}.{imageExtension}
{imageType} es alguna de estas

• icono (por ejemplo, icono de signo de interrogación para el contenido de ayuda)
• img (por ejemplo, una imagen de encabezado insertada a través de un <img />elemento)
• botón (por ejemplo, un botón de envío gráfico)
• bg (la imagen se usa como imagen de fondo en css)
• sprite (la imagen se usa como imagen de fondo en css y contiene múltiples "versiones")

Ejemplo-nombres serían: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifetc.

Entonces, ¿qué piensas y cuál es tu convención de nomenclatura ?

Coloco archivos CSS en una carpeta css, Javascript en js, imágenes en images, ... Agregue subcarpetas como mejor le parezca. No es necesaria ninguna convención de nomenclatura a nivel de archivos individuales.

Me he dado cuenta de una gran cantidad de desarrolladores frontend están alejando de cssy jsen favor de stylesy scriptsporque en general hay otras cosas en allí, por ejemplo .less, .styly .sassademás, para algunos, .coffee. El hecho es que utilizar selecciones de tecnología específicas en la organización de carpetas que elija es una mala idea, incluso si todos lo hacen. Continuaré usando el estándar que veo de estos desarrolladores altamente respetados:

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

Y sus equivalentes de construcción de destino, que a veces tienen el prefijo destsegún lo que están construyendo:

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

Esto permite que aquellos que quieran juntar todos los archivos (en lugar de dividir un srcdirectorio) lo mantengan y mantiene las cosas claramente asociadas para aquellos que sí se rompen.

De hecho, voy un poco más lejos y agrego

• scripts/before
• scripts/after

Que se suavizan en dos main-before.min.jsy main-after.min.jsscripts, uno para el encabezado (con elementos esenciales de normalizey modernizrque deben ejecutarse temprano, por ejemplo) y afterpara lo último en el cuerpo, ya que javascript puede esperar. Estos no están destinados a la lectura, al igual que la página principal de Google.

Si hay scripts y hojas de estilo que tengan sentido para minimizar y dejar el enlace solo debido a un enfoque particular de administración de caché que se cuida en las reglas de compilación.

En estos días, si no está utilizando un proceso de construcción de algún tipo, como gulp o gruñido , es probable que no esté alcanzando la mayoría de los objetivos de rendimiento centrados en dispositivos móviles que probablemente debería considerar.

/Bienes/
  / Css
  / Imágenes
  / Javascript (o secuencia de comandos)
    / Minificado
    /Fuente

Es la mejor estructura que he visto y la que prefiero. Con las carpetas, realmente no necesita prefijar su CSS, etc. con nombres descriptivos.

Para sitios grandes donde css podría definir muchas imágenes de fondo, una convención de nomenclatura de archivos para esos activos resulta muy útil para realizar cambios más adelante.

Por ejemplo:

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

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

También hemos discutido agregar el tipo de elemento, pero no estoy seguro de cuán útil sea y podría ser engañoso para los cambios necesarios en el futuro:

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

Puedes nombrarlo así:

/ assets / css / - Para archivos CSS

/ assets / font /: para archivos de fuentes. (En general, puede ir a las fuentes de Google para buscar fuentes utilizables).

/ assets / images /: para archivos de imágenes.

/ assets / scripts / o / assets / js /: para archivos JavaScript.

/ assets / media / - Para video y miscelánea. archivos.

También puede reemplazar "activos" con el nombre de carpeta de "recursos" o "archivos" y mantener el nombre de sus subcarpetas. Bueno, tener una estructura de carpetas de pedidos como esta no es muy importante, lo único importante es que solo tienes que organizar tus archivos por su formato. como crear una carpeta "/ css /" para archivos CSS o "/ images /" para archivos de imagen.

En primer lugar, divido en carpetas: css, js, img.

Dentro de css y js, prefijo archivos con el nombre del proyecto porque su sitio puede incluir archivos js y css que son componentes, esto deja en claro dónde los archivos son específicos para su sitio o relacionados con complementos.

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

Otros archivos pueden ser como

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

Finalmente, las imágenes se dividen según su uso.

• img/btn/submit.png un botón
• img/lgo/mysite-logo.png un logo
• img/bkg/header.gif un fondo
• img/dcl/top-left-widget.jpg un elemento de calcomanía
• img/con/portait-of-something.jpg una imagen de contenido

Es importante mantener las imágenes organizadas, ya que puede haber más de 100 y pueden mezclarse fácilmente y confundirse con nombres.

Tiendo a evitar todo lo genérico, como lo que sugirió smdrager. "mysite.main.css" no significa nada en absoluto.

¿Qué es "mysite"? ¿Este en el que estoy trabajando? Si es así, entonces es realmente obvio, ¡pero ya me hace pensar qué podría ser y si es tan obvio!

¿Qué es "Principal"? La palabra "Principal" no tiene ninguna definición fuera del conocimiento del codificador de lo que hay dentro de ese archivo css.

Si bien está bien en ciertos escenarios, evita nombres como "arriba" o "izquierda" también: "top-nav.css" o "top-main-logo.png".
Puede terminar queriendo usar lo mismo en otro lugar, y poner una imagen en un pie de página o dentro del contenido de la página principal llamada "top-banner.png" es muy confuso.

No veo ningún problema con tener una buena cantidad de hojas de estilo para permitir una convención de nomenclatura decente para representar qué es css dentro del archivo dado.
La cantidad depende completamente del tamaño del sitio y de sus funciones, y de cuántos bloques diferentes hay en el sitio.

No creo que necesite indicar "CSS" o "ESTILO" en los nombres de archivo css, ya que está en la carpeta "css" o "estilos" y tiene una extensión de .cssy principalmente porque estos archivos solo se llaman en el<head> zona, sé con bastante claridad cuáles son.

Dicho esto, hago esto con archivos de biblioteca, JS y config (etc.). por ejemplo, libSomeLibrary.php o JSSomeScript.php. Como los archivos PHP y JS se incluyen o se usan en varias áreas dentro de otros archivos, es útil tener información sobre cuál es el propósito principal del archivo dentro del nombre.

Ej .: Ver el nombre del archivo require('libContactFormValidation.php');es útil. Sé que es un archivo de biblioteca (lib) y por el nombre lo que hace.

Para las carpetas de imágenes, normalmente tengo images/content-images/yimages/style-images/ . No creo que sea necesario que haya más separación, pero nuevamente depende del proyecto.

Luego, cada imagen se nombrará de acuerdo con lo que es, y nuevamente, no creo que sea necesario definir que el archivo es una imagen dentro del nombre del archivo. Los tamaños pueden ser útiles, especialmente cuando las imágenes tienen diferentes tamaños.

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

Una buena regla a seguir es: si un nuevo desarrollador llegara a los archivos, ¿se sentaría rascándose la cabeza durante horas o probablemente entendería lo que hacen las cosas y solo necesitaría un poco de tiempo investigando (lo cual es inevitable)?

Sin embargo, como algo así, una de las reglas más importantes a seguir es simplemente la constancia .
¡Asegúrese de seguir la misma lógica y patrones en todas sus convenciones de nomenclatura!
Desde simples nombres de archivos css hasta archivos de biblioteca PHP y nombres de columnas y tablas de bases de datos.

Ésta es una pregunta antigua, pero aún válida.

Mi recomendación actual es ir con algo en estas líneas:

• activos (o activos-web o activos-www); este está destinado al contenido estático utilizado por el cliente (navegador)
  • datos; algunos archivos xml y otras cosas
  • fuentes
  • imagenes
  • medios de comunicación
  • estilos
  • guiones
  • lib (o de terceros); este está destinado al código que no crea ni modifica, las bibliotecas a medida que las obtiene
  • lib-modded (o modificado por terceros); este está destinado al código que no se esperaba que modificara, pero tenía que hacerlo, como aplicar una solución / corrección mientras tanto, el proveedor de la biblioteca lo publica
• inc (o assets-server o assets-local); este está diseñado para el contenido utilizado en el lado del servidor, no para ser utilizado por el cliente, como bibliotecas en lenguajes como PHP o scripts de servidor, como archivos bash
  • fuentes
  • lib
  • lib-modded

Marqué en negrita los habituales, los demás no son contenidos habituales.

El motivo de la división principal es que, en el futuro, puede decidir si los activos web son servidores desde un CDN o restringir el acceso del cliente a los activos del servidor, por razones de seguridad.

Dentro de los directorios lib, suelo ser descriptivo sobre las bibliotecas, por ejemplo

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [camino]
      • [nombre de la biblioteca / proyecto]
        • vX.YZ (versión)

para que pueda reemplazar la biblioteca por una nueva, sin romper el código, lo que también permite que los futuros encargados del mantenimiento del código, incluido usted mismo, encuentren la biblioteca y la actualicen u obtengan soporte.

Además, siéntase libre de organizar el contenido interno de acuerdo con su uso, por lo que las imágenes / logotipos e imágenes / íconos son directorios esperados en algunos proyectos.

Como nota al margen, el nombre de los activos es significativo, no solo significa que tenemos recursos allí, sino que los recursos deben ser de valor para el proyecto y no un peso muerto.

La BBC tiene toneladas de estándares relacionados con el desarrollo web.

Su estándar es bastante simple para archivos CSS:

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

Es posible que pueda encontrar algo útil en su sitio principal:

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