Qual é a convenção de nomenclatura padrão para ids e classes html / css?


250

Depende da plataforma que você está usando ou existe uma convenção comum que a maioria dos desenvolvedores sugere / segue?

Existem várias opções:

  1. id="someIdentifier"' - parece bastante consistente com o código javascript.
  2. id="some-identifier" - parece mais com atributos do tipo html5 e outras coisas em html.
  3. id="some_identifier" - parece bastante consistente com o código ruby ​​e ainda é um identificador válido dentro do Javascript

Eu estava pensando que os itens 1 e 3 acima fazem mais sentido, porque eles são mais agradáveis ​​com Javascript.

Existe uma resposta certa para isso?



Respostas:


256

Não há um.

Uso sublinhados o tempo todo, devido a hífens atrapalhando o destaque da sintaxe do meu editor de texto (Gedit), mas essa é a preferência pessoal.

Eu já vi todas essas convenções usadas em todo o lugar. Use o que você achar melhor - o que parecer melhor / mais fácil de ler para você e mais fácil de digitar, porque você o usará muito. Por exemplo, se você tiver sua tecla de sublinhado na parte inferior do teclado (improvável, mas inteiramente possível), atenha-se a hífens. Basta ir com o que é melhor para si mesmo. Além disso, todas essas três convenções são facilmente legíveis. Se você estiver trabalhando em uma equipe, lembre-se de manter a convenção especificada pela equipe (se houver).

Atualização 2012

Eu mudei como eu programo ao longo do tempo. Agora eu uso camel case ( thisIsASelector) em vez de hífens agora; Acho o último bastante feio. Use o que você preferir, o que pode mudar facilmente com o tempo.

Atualização 2013

Parece que eu gosto de misturar as coisas anualmente ... Depois de mudar para o Sublime Text e usar o Bootstrap por um tempo, voltei aos traços. Para mim agora eles parecem muito mais limpos que un_der_scores ou camelCase. Meu argumento original ainda permanece: não um padrão.

Atualização 2015

Um caso interessante de canto com convenções aqui é Rust . Eu realmente gosto da linguagem, mas o compilador avisará se você definir coisas usando algo diferente underscore_case. Você pode desativar o aviso, mas é interessante que o compilador sugira fortemente uma convenção por padrão. Eu imagino que em projetos maiores isso leva a um código mais limpo, o que não é ruim.

Atualização 2016 ( você pediu)

Adotei o padrão BEM para meus projetos daqui para frente. Os nomes das classes acabam sendo bastante detalhados, mas acho que fornece boa estrutura e reutilização para as classes e CSS que os acompanham. Suponho que o BEM seja realmente um padrão (então o meu nose torna um yestalvez), mas ainda depende de você o que você decide usar em um projeto. Mais importante: seja consistente com o que você escolher.

Atualização 2019 ( você pediu)

Depois de escrever um CSS por um bom tempo, comecei a trabalhar em um local que usa o OOCSS em um de seus produtos. Pessoalmente, acho bastante desagradável classificar as classes em todos os lugares, mas não basta alternar entre HTML e CSS o tempo todo é bastante produtivo.

Ainda estou decidido pelo BEM. É detalhado, mas o espaço para nome torna o trabalho com ele nos componentes React muito natural. Também é ótimo para selecionar elementos específicos ao testar o navegador.

OOCSS e BEM são apenas alguns dos padrões de CSS existentes. Escolha um que funcione para você - todos eles estão cheios de compromissos porque o CSS não é tão bom .

Atualização 2020

Uma atualização chata este ano. Eu ainda estou usando o BEM. Minha posição não mudou muito a partir da atualização de 2019 pelos motivos listados acima. Use o que funciona melhor para você, que se adapta ao tamanho da sua equipe e oculta tanto ou tão pouco o conjunto de recursos ruins do CSS que você desejar.


10
Penso que, à medida que a sua aplicação aumenta, os seus IDs começam a ser longos e complexos e, nesse momento, os traços não parecem bons. Também estou usando o Sublime e o Twitter Bootstrap, e estou de acordo em usar traços para classes como o Bootstrap. Mas o ids é mais para JavaScript, então eu prefiro usar camelCase nesse caso.
glrodasz

3
Para mim, ainda prefiro o estilo sublinhado. Simplesmente porque todas as tags e atributos HTML são minúsculos. Estou evitando letras maiúsculas aqui.
yaoxing 23/05

3
Um quase-padrão que eu já vi (o Bootstrap parece fazer parte disso) é anexar "js-" a qualquer classe ou ID de CSS usado especificamente para Javascript. Talvez isso vai fazer o corte para 2016 :)
Dolan Antenucci

1
@Bojangles - O BEM parece interessante, embora o uso de hífens e sublinhados para diferentes propósitos levasse algum tempo para se acostumar; Da mesma forma, os traços duplos / sublinhados faria bem :) Obrigado por compartilhar
Dolan Antenucci

7
Uma razão pela qual acredito que as pessoas preferem traços nos IDs de CSS e as classes são para funcionalidade. O uso da opção + seta para a esquerda / direita para percorrer o seu código palavra por palavra para em cada traço, permitindo percorrer facilmente o ID ou o nome da classe usando atalhos de teclado. Sublinhados e camelcase não são captados e o cursor passa à direita sobre eles como se fosse uma única palavra.
precisa saber é o seguinte


33

Sugiro que você use um sublinhado em vez de um hífen (-), pois ...

<form name="myForm">
  <input name="myInput" id="my-Id" value="myValue"/>
</form>

<script>
  var x = document.myForm.my-Id.value;
  alert(x);
</script>

você pode acessar o valor por id facilmente dessa maneira. Mas se você usar um hífen, ele causará um erro de sintaxe.

Esta é uma amostra antiga, mas pode funcionar sem jquery - :)

graças a @jean_ralphio, há uma maneira de evitar isso

var x = document.myForm['my-Id'].value;

O estilo traço seria um estilo de código do google, mas eu realmente não gosto disso. Eu preferiria TitleCase para id e camelCase para classe.


5
Alguém sinalizou isso. Seu inglês poderia ser melhor, mas, assumindo que isso esteja correto, parece uma adição útil ao corpus de conhecimento aqui; portanto, votarei contra a exclusão.
precisa saber é o seguinte

3
Esta resposta é subestimada!
K - A toxicidade no SO está crescendo.

19
A solução alternativa évar x = document.myForm['my-Id'].value;
ethan

Eu não usaria nenhum desses métodos, mas sim getElementById('whatever-you-want_my_friend'). Depende. Se o seu código possui HTML de renderização de código de back-end (lado do servidor), usando camelCase para corresponder às suas convenções de nomenclatura, ou snake_case, qualquer que seja a linguagem de codificação usada, é provavelmente o melhor para que a pesquisa no seu código de front-end e back-end seja concordante.
Oliver Williams

12

tl; dr;

Não existe uma resposta verdadeira. Você pode escolher um dos muitos por aí ou criar seus próprios padrões com base no que faz sentido, dependendo de com quem você está trabalhando. E é 100% dependente da plataforma.


Correio Original

Apenas mais um padrão alternativo a ser considerado:

<div id="id_name" class="class-name"></div>

E no seu script:

var variableName = $("#id_name .class-name");

Isso apenas usa camelCase, under_score e hifenização respectivamente para variáveis, IDs e classes. Eu li sobre esse padrão em alguns sites diferentes. Embora um pouco redundante nos seletores css / jquery, as redundâncias facilitam a captura de erros. por exemplo: se você vê .unknown_nameou está #unknownNameno seu arquivo CSS, sabe que precisa descobrir a que isso realmente se refere.


ATUALIZAR 2019

(Os hífens são chamados de 'kebab-case', os sublinhados são chamados de 'snake_case' e, em seguida, você tem 'TitleCase', 'pascalCase')

Eu pessoalmente não gosto de hífens. Eu originalmente postei isso como uma alternativa (porque as regras são simples). No entanto, os hífens dificultam muito os atalhos de seleção (clique duas vezes em ctrl/ option+ left/ righte ctrl/ cmd+ Dno vsCode. Além disso, os nomes das classes e dos arquivos são o único local em que os hífens funcionam, porque quase sempre estão entre aspas ou css, etc. Mas o atalho ainda se aplica.

Além de variáveis, nomes de classe e IDs, você também deseja examinar as convenções de nome de arquivo. E Git Ramos.

O grupo de codificação do meu escritório teve uma reunião um ou dois meses atrás para discutir como íamos nomear as coisas. Para ramificações git, não podemos decidir entre 321-the_issue_description ou 321_the-issue-description. (Eu queria 321_theIssueDescription, mas meus colegas de trabalho não gostaram disso.)

Um exemplo, para demonstrar o trabalho com os padrões de outras pessoas ...

O Vue.js tem um padrão. Na verdade, eles têm dois padrões alternativos para vários de seus itens. Não gosto das duas versões dos nomes de arquivos. Eles recomendam "/path/kebab-case.vue"ou "/path/TitleCase.Vue". O primeiro é mais difícil de renomear, a menos que você esteja tentando renomear parte dele. O último não é bom para compatibilidade entre plataformas. Eu preferiria "/path/snake_case.vue". No entanto, ao trabalhar com outras pessoas ou projetos existentes, é importante seguir qualquer padrão já definido. Portanto, eu escolho o kebab-case para nomes de arquivos no Vue, mesmo que eu reclame totalmente. Porque não seguir isso significa alterar muitos arquivos que o vue-cli configura.


mesmo que a minha preferência. camelCase para variáveis ​​e under_score para id, no entanto, normalmente aplico under_scores para classes e nomes também.
Vincent Edward Gedaria Binua

Gostei porque é o mesmo que prefiro usar. 'snake_case' para ids, 'kebab-case' para css, 'camelCase' para funções e variáveis.
Eduardo Paz

10

Não existe uma convenção de nomenclatura acordada para HTML e CSS. Mas você pode estruturar sua nomenclatura em torno do design de objetos. Mais especificamente, o que chamo de Propriedade e Relacionamento.

Propriedade

Palavras-chave que descrevem o objeto podem ser separadas por hífens.

carro-novo-virou-direito

As palavras-chave que descrevem o objeto também podem se enquadrar em quatro categorias (que devem ser ordenadas da esquerda para a direita): Objeto, Descritor de Objetos, Ação e Descritor de Ações.

car - um substantivo e um objeto
novo - um adjetivo e um descritor de objeto que descreve o objeto com mais detalhes
transformados - um verbo e uma ação que pertence ao objeto à
direita - um adjetivo e um descritor de ação que descreve a ação em mais detalhes

Nota: os verbos (ações) devem estar no passado (virados, executados, executados etc.).

Relação

Os objetos também podem ter relacionamentos como pai e filho. O Action e Action-Descriptor pertencem ao objeto pai, eles não pertencem ao objeto filho. Para relacionamentos entre objetos, você pode usar um sublinhado.

carro-novo-virou-direita-roda-esquerda-virou-esquerda

  • carro-novo-virou-à-direita (segue a regra de propriedade)
  • roda-esquerda-esquerda-esquerda (segue a regra de propriedade)
  • carro-novo-virou-direita-roda-esquerda-virou-esquerda (segue a regra de relacionamento)

Notas finais:

  • Como o CSS não diferencia maiúsculas de minúsculas, é melhor escrever todos os nomes em letras minúsculas (ou maiúsculas); evite as caixas de camelo ou pascal, pois podem levar a nomes ambíguos.
  • Saiba quando usar uma classe e quando usar um ID. Não se trata apenas de um ID sendo usado uma vez na página da web. Na maioria das vezes, você deseja usar uma classe e não um ID. Componentes da Web como (botões, formulários, painéis, etc.) devem sempre usar uma classe. Os IDs podem facilmente levar a conflitos de nomes e devem ser usados ​​com moderação para espaçar os nomes da sua marcação. Os conceitos acima de propriedade e relacionamento se aplicam à nomeação de classes e IDs e ajudarão a evitar conflitos de nomeação.
  • Se você não gostar da minha convenção de nomenclatura CSS, também existem várias outras: convenção de nomenclatura estrutural, convenção de nomeação para apresentações, convenção de nomeação semântica, convenção de nomeação BEM, convenção de nomeação OCSS, etc.

4

Outra razão pela qual muitos preferem hífens nos nomes de ID e classe CSS é a funcionalidade.

O uso de atalhos de teclado como option+ left/ right(ou ctrl+ left/ rightno Windows) para percorrer o código palavra por palavra interrompe o cursor a cada traço, permitindo que você percorra com precisão o ID ou o nome da classe usando atalhos de teclado. Os sublinhados e o camelCase não são detectados e o cursor passa sobre eles como se fosse uma única palavra.


Apenas para que os outros não se confunda: Para o Windows é CTRL + ESQUERDA / DIREITA
Gordon Mohrin

Essa é realmente a minha maior razão para usar sublinhados ou camelCase em vez de traços sempre que possível. the-red-boxé impossível selecionar com um simples clique duplo ou duas teclas pressionadas. Também cmd / ctrl + D para vsCode. Em vez disso, você deve executar várias vezes ou arrastar e selecionar com o mouse. Mas the_red_boxsuporta todos os três atalhos de seleção fácil.
RoboticRenaissance

1

Recentemente, comecei a aprender XML. A versão sublinhada me ajuda a separar tudo relacionado a XML (DOM, XSD etc.) de linguagens de programação como Java, JavaScript (case camel). E eu concordo com você que o uso de identificadores permitidos nas linguagens de programação parece melhor.

Editar: Pode não estar relacionado, mas aqui está um link para regras e recomendações sobre como nomear elementos XML que sigo ao nomear identificações (seções "Regras de nomeação de XML" e "Melhores práticas de nomeação").

http://www.w3schools.com/xml/xml_elements.asp


1

Eu acho que depende da plataforma. Ao desenvolver no .Net MVC, uso minúsculas e hífens no estilo de auto-inicialização para nomes de classes, mas para IDs utilizo PascalCase.

O motivo disso é que minhas visualizações são apoiadas por modelos de visualização fortemente tipados. As propriedades dos modelos C # são maiúsculas e minúsculas. Para fins de ligação do modelo com o MVC, faz sentido que os nomes dos elementos HTML que se ligam ao modelo sejam consistentes com as propriedades do modelo de visualização que são maiúsculas de minúsculas. Para simplificar, meus IDs usam a mesma convenção de nomenclatura que os nomes dos elementos, exceto botões de opção e caixas de seleção que exigem IDs exclusivos para cada elemento no grupo de entrada nomeado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.