Convenção de nomenclatura para ativos (imagens, css, js)?

Ainda estou lutando para encontrar uma boa convenção de nomenclatura para ativos como imagens, arquivos js e css usados ​​em meus projetos da web.

Então, minha corrente seria:

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

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

Imagens: {imageType}-{name}.{imageExtension}
{imageType} qualquer uma dessas

• ícone (por exemplo, ícone de ponto de interrogação para conteúdo de ajuda)
• img (por exemplo, uma imagem de cabeçalho inserida por meio do <img />elemento)
• botão (por exemplo, um botão gráfico de envio)
• bg (a imagem é usada como imagem de fundo em css)
• sprite (a imagem é usada como imagem de fundo no css e contém várias "versões")

Exemplo nomes seriam: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifetc.

Então, o que você acha e qual é a sua convenção de nomenclatura ?

Coloco arquivos CSS em uma pasta css, Javascript em js, imagens em images, ... Adiciono subpastas como você vê o ajuste. Não há necessidade de qualquer convenção de nomenclatura no nível de arquivos individuais.

Tenho notado um monte de desenvolvedores de frontend estão se afastando csse jsem favor de stylese scriptsporque geralmente há outras coisas lá, como .less, .styl, e .sass, bem como, para alguns, .coffee. O fato é que usar seleções de tecnologia específicas em sua escolha de organização de pasta é uma má ideia, mesmo que todos façam isso. Vou continuar a usar o padrão que vejo desses desenvolvedores altamente respeitados:

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

E seus equivalentes de compilação de destino, que às vezes são prefixados destdependendo do que estão construindo:

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

Isso permite que aqueles que desejam colocar todos os arquivos juntos (em vez de separar um srcdiretório) mantenham isso e mantenha as coisas claramente associadas para aqueles que o fizerem.

Na verdade, vou um pouco mais longe e adiciono

• scripts/before
• scripts/after

Que se transformam em dois main-before.min.jse main-after.min.jsscripts, um para o cabeçalho (com elementos essenciais normalizee modernizrque precisam ser executados antes, por exemplo) e aftera última coisa no corpo, já que o javascript pode esperar. Eles não se destinam à leitura, como a página principal do Google.

Se houver scripts e folhas de estilo que façam sentido reduzir e deixar o link sozinho devido a uma abordagem de gerenciamento de cache específica que é tratada nas regras de construção.

Hoje em dia, se você não está usando um processo de construção de algum tipo, como gulp ou grunt , provavelmente não está atingindo a maioria das metas de desempenho centradas em dispositivos móveis que provavelmente deveria considerar.

/Ativos/
  / Css
  / Imagens
  / Javascript (ou Script)
    / Minificado
    /Fonte

É a melhor estrutura que já vi e a que prefiro. Com as pastas, você realmente não precisa prefixar seu CSS etc. com nomes descritivos.

Para sites grandes onde o css pode definir muitas imagens de fundo, uma convenção de nomenclatura de arquivo para esses ativos é muito útil para fazer alterações posteriormente.

Por exemplo:

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

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

Também discutimos a adição do tipo de elemento, mas não tenho certeza de quão útil isso é e pode ser enganoso para futuras alterações necessárias:

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

Você pode nomeá-lo assim:

/ assets / css / - Para arquivos CSS

/ assets / font / - Para arquivos de fonte. (Geralmente, você pode simplesmente ir para fontes do Google para pesquisar fontes utilizáveis.)

/ assets / images / - Para arquivos de imagens.

/ assets / scripts / ou / assets / js / - Para arquivos JavaScript.

/ assets / media / - Para vídeo e diversos. arquivos.

Você também pode substituir "ativos" pelo nome da pasta "recurso" ou "arquivos" e manter o nome de suas subpastas. Bem, ter uma estrutura de pedido de pastas como esta não é muito importante, o único importante é que você apenas tem que organizar seus arquivos pelo formato. como criar uma pasta "/ css /" para arquivos CSS ou "/ images /" para arquivos de imagem.

Em primeiro lugar, divido em pastas: css, js, img.

Dentro de css e js, prefixo os arquivos com o nome do projeto porque seu site pode incluir arquivos js e css que são componentes. Isso deixa claro onde os arquivos são específicos para o seu site ou relacionados a plug-ins.

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

Outros arquivos podem ser semelhantes

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

Por fim, as imagens são divididas por uso.

• img/btn/submit.png um botão
• img/lgo/mysite-logo.png um logotipo
• img/bkg/header.gif um plano de fundo
• img/dcl/top-left-widget.jpg um elemento de decalque
• img/con/portait-of-something.jpg uma imagem de conteúdo

É importante manter as imagens organizadas, pois podem haver mais de 100 e podem ser facilmente totalmente misturadas e com nomes confusos.

Eu tendo a evitar qualquer coisa genérica, como o que o smdrager sugeriu. "mysite.main.css" não significa absolutamente nada.

O que é "meusite" ?? Este em que estou trabalhando? Se sim, então é óbvio mesmo, mas já me fez pensar o que poderia ser e se é tão óbvio!

O que é "Principal"? A palavra "Principal" não tem definição fora do conhecimento do codificador do que está dentro desse arquivo css.

Embora ok em certos cenários, evite nomes como "top" ou "left" também: "top-nav.css" ou "top-main-logo.png".
Você pode querer usar a mesma coisa em outro lugar, e colocar uma imagem em um rodapé ou dentro do conteúdo da página principal chamado "top-banner.png" é muito confuso!

Não vejo nenhum problema em ter um bom número de folhas de estilo para permitir uma convenção de nomenclatura decente para retratar o que css está dentro do arquivo fornecido.
A quantidade depende inteiramente do tamanho do site e de suas funções, e de quantos blocos diferentes existem no site.

Não acho que você precise declarar "CSS" ou "ESTILO" nos nomes dos arquivos css, pois o fato de estar na pasta "css" ou "estilos" e ter uma extensão de .csse principalmente porque esses arquivos são sempre chamados na <head>área, sei muito bem o que são.

Dito isso, eu faço isso com arquivos de biblioteca, JS e config (etc). por exemplo, libSomeLibrary.php ou JSSomeScript.php. Como os arquivos PHP e JS são incluídos ou usados ​​em várias áreas dentro de outros arquivos, é útil ter informações sobre qual é o propósito principal do arquivo dentro do nome.

por exemplo: ver o nome do arquivo require('libContactFormValidation.php');é útil. Eu sei que é um arquivo de biblioteca (lib) e pelo nome o que ele faz.

Para pastas de imagens, geralmente tenho images/content-images/e images/style-images/. Não acho que haja necessidade de mais separação, mas, novamente, depende do projeto.

Então, cada imagem será nomeada de acordo com o que é e, novamente, não acho que seja necessário definir o arquivo como uma imagem dentro do nome do arquivo. Os tamanhos podem ser úteis, especialmente quando as imagens têm tamanhos diferentes.

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

Uma boa regra a ser seguida é: se um novo desenvolvedor acessasse os arquivos, ele ficaria sentado coçando a cabeça por horas ou provavelmente entenderia o que as coisas fazem e só precisaria de um pouco de tempo pesquisando (o que é inevitável)?

Como algo assim, no entanto, uma das regras mais importantes a seguir é simplesmente constância !
Certifique-se de seguir a mesma lógica e padrões em todas as convenções de nomenclatura!
De simples nomes de arquivo css a arquivos de biblioteca PHP e nomes de colunas e tabelas de banco de dados.

Esta é uma questão antiga, mas ainda válida.

Minha recomendação atual é ir com algo nas seguintes linhas:

• ativos (ou ativos-web ou ativos-www); este se destina ao conteúdo estático usado pelo cliente (navegador)
  • dados; alguns arquivos xml e outras coisas
  • fontes
  • imagens
  • meios de comunicação
  • estilos
  • scripts
  • lib (ou terceiro); este se destina ao código que você não cria ou modifica, as bibliotecas conforme você as obtém
  • lib-modded (ou modificado por terceiros); este é destinado ao código que você não esperava que modificasse, mas teve que modificar, como aplicar uma solução alternativa / correção enquanto o provedor da biblioteca o libera
• inc (ou ativo-servidor ou ativo-local); este se destina ao conteúdo usado do lado do servidor, não para ser usado pelo cliente, como bibliotecas em linguagens como PHP ou scripts de servidor, como arquivos bash
  • fontes
  • lib
  • lib-modded

Marquei a negrito os habituais, os outros não são conteúdos habituais.

O motivo da divisão principal é que, no futuro, você poderá decidir servir os ativos da web a partir de um CDN ou restringir o acesso do cliente aos ativos do servidor, por motivos de segurança.

Dentro dos diretórios lib, eu costumo ser descritivo sobre as bibliotecas, por exemplo

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [caminho]
      • [biblioteca / nome do projeto]
        • vX.YZ (versão)

assim, você pode substituir a biblioteca por uma nova, sem quebrar o código, permitindo também que futuros mantenedores de código, incluindo você, encontrem a biblioteca e atualizem-na ou obtenham suporte.

Além disso, fique à vontade para organizar o conteúdo interno de acordo com seu uso, de modo que imagens / logotipos e imagens / ícones são diretórios esperados em alguns projetos.

Como uma observação lateral, o nome do ativo é significativo, não apenas significando que temos recursos lá, mas significando que os recursos lá devem ser de valor para o projeto e não peso morto.

A BBC tem muitos padrões relacionados ao desenvolvimento da web.

Seu padrão é bastante simples para arquivos CSS:

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

Você pode encontrar algo útil no site principal:

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