Considerações práticas para convenções de nomenclatura HTML / CSS (sintaxe) [fechado]


28

Pergunta: quais são as considerações práticas para a sintaxe classe os idvalores?

Observe que não estou perguntando sobre a semântica , ou seja, as palavras reais que estão sendo usadas, como por exemplo, descritas neste post do blog . Já existem muitos recursos nesse lado das convenções de nomenclatura, na verdade obscurecendo minha pesquisa por informações práticas sobre os vários bits sintáticos : invólucro, uso de interpunções (especificamente o -traço), caracteres específicos a serem usados ​​ou evitados etc.

Para resumir as razões pelas quais estou fazendo esta pergunta:

  • As restrições de nomenclatura em id e classe não levam naturalmente a nenhuma convenção
  • A abundância de recursos no lado semântico das convenções de nomenclatura obscurece as pesquisas sobre considerações sintáticas
  • Não consegui encontrar nenhuma fonte autorizada neste
  • Ainda não havia nenhuma pergunta sobre os Programadores de SE sobre este tópico :)

Algumas das convenções que considerei usar:

  1. UpperCamelCase, principalmente como um hábito cruzado da codificação no servidor
  2. lowerCamelCase, para consistência com as convenções de nomenclatura JavaScript
  3. css-style-classes, que é consistente com a nomeação de propriedades css (mas pode ser irritante quando Ctrl + Shift + ArrowKey seleciona o texto)
  4. with_under_scores, que eu pessoalmente não vi muito usado
  5. alllowercase, simples de lembrar, mas pode ser difícil de ler para nomes mais longos
  6. UPPERCASEFTW, como uma ótima maneira de irritar seus colegas programadores (talvez combinados com a opção 4 para facilitar a leitura)

E provavelmente deixei de fora algumas opções ou combinações importantes também. Então: que considerações existem para convenções de nomenclatura e a que convenção elas levam?


CamelCaseEverythingInCode
Ryathal 28/03

11
BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)
Jeroen

Normalmente eu uso classes minúsculas e o CamelCase todo o resto. Nenhuma razão em particular
Antarr Byrd 28/03

"classes de estilo css, que é consistente com a nomeação de propriedades css (mas pode ser irritante quando a seleção de texto Ctrl + Shift + ArrowKey)" - é apenas um problema se você usar um editor de texto
subótimo

@Ryathal que é PascalCase (ou UpperCamelCase), camelCase (ou lowerCamelCase) se parece com este exemplo.
precisa saber é o seguinte

Respostas:


18

Recompensa ou não, até certo ponto, a escolha sempre será uma "questão de preferência" - afinal, como você se sentiria se o W3C recomendasse (ou até impusesse) uma certa convenção que não considerava correta?

Dito isto, porém, eu pessoalmente prefiro a lowerCamelCaseconvenção e darei as razões e considerações práticas que já usei para decidir - farei isso por um processo de eliminação, usando a numeração da sua pergunta:

(5.) não é muito fácil de ler porque você sabe que as palavras começam e

(6.) ACIMA DE MAIS, NÃO PODE GANHAR ALGUM ALGUMA COISA.

(4.) historical_incompatibility_plus_see: documentação do Mozilla Dev .

(3.) um pouco mais complicado de explicar ... como você menciona, a selecionabilidade nos editores de texto é um problema (como os sublinhados, dependendo do editor), mas para mim também é o fato de que isso me lembra a sintaxe reservada para palavras-chave específicas do fornecedor , mesmo que elas comecem com um hífen e também com palavras separadas por elas.

Portanto, isso deixa seu (1.) e (2.), UpperCamelCase e lowerCamelCase, respectivamente. Apesar do vínculo mental com as classes Java (que são, por uma convenção mais claramente definida, UpperCamelCase), os nomes das classes CSS parecem, para mim, melhores começar com uma letra minúscula. Talvez seja por causa dos nomes dos elementos e atributos XHTML , mas acho que você também pode argumentar que as classes CSS usam UpperCamelCase ajudariam a diferenciá-las. Se você precisar de outro motivo, lowerCamelCase é o que o W3C usa em exemplos para bons nomes de classe (embora a própria URL, irritantemente, discorde de mim).

Aconselho contra (4.), (5.) e (6.) pelas razões expostas acima, mas suponho que argumentos possam ser apresentados para qualquer um dos outros três.

Entretanto, você (ou qualquer outra pessoa) concorda ou não comigo sobre esse assunto. O fato de você não ter uma resposta definitiva citando fontes autorizadas até agora pode ser entendido como uma dica de que não existe um padrão definido para esse problema (caso contrário, todos nós o estaríamos usando). Não tenho certeza se isso é necessariamente uma coisa ruim.


Obrigado! Você menciona (como a maioria das outras respostas) que é uma questão de preferência, mas também a complementa com alguns conselhos práticos e alguns bons links sobre as considerações mais importantes (como a one_on_icompatability). Embora eu ainda considere seguir a sugestão na resposta do @tdammers (nomear com traços), a resposta dada aqui é a que realmente responde à pergunta que eu fiz. Assim: recompensa + admitida, além de muito obrigado :)
Jeroen

Muito obrigado de volta - desde que você permaneça consistente, acho que qualquer um desses três está bem. Não há muito entre eles, e se você olhar para locais em toda a rede, eu tenho certeza que você vai encontrar uma abundância de exemplos de cada ;-)
Amos M. Carpenter

+1 Porém, eu tenho certeza que é necessariamente uma coisa ruim. Embora eu seja a favor dos esforços dos padrões da comunidade em nome, formatação e convenções gerais de estilo , a falta de uniformidade pode tornar a herança do projeto um pesadelo ( para não dizer que esse pesadelo seria aliviado pelos padrões, eles provavelmente não seriam seguido ) O fato de que CSS, fraco e declarativa, é tão misturado com o cliente e aplicação do lado do servidor de lógica até mesmo como anzóis simples, ele anseia pela estrutura unificada ( por ele anseia, quero dizer que anseiam )
Dan Lugg

Definitivamente, concordo que os sublinhados devem ser evitados (exceto talvez para nomes de identificação, se o código do servidor usar sublinhados). Os hífens não podem ser usados ​​como um separador nas linguagens de programação, porque o hífen também é o operador menos. Mas em qualquer outro contexto em que você possa usar sublinhados, acho que os hífens são uma opção mais natural - mais fácil de digitar e para URLs, mais visível quando um URL é sublinhado.
precisa

7

As palavras nos nomes das classes CSS devem ser separadas por traços ( class-name), pois é assim que as palavras nas propriedades CSS e nas pseudo-classes são separadas e sua sintaxe é definida pelas especificações CSS .

As palavras nos nomes de ID também devem ser separadas por hífens, para corresponder ao estilo sintático dos nomes das classes e porque os nomes de ID são frequentemente usados ​​em URLs e o traço é o separador de palavras original e mais comum em URLs.


Ah +1, eu gosto da menção de IDs em URLs. Embora o engraçado seja que, para dar uma olhada nisso, fui verificar como a Wikipedia faz isso. Por exemplo, a seção de suporte ao Browswer do artigo CSS da Wikipedia forneceu <span id="Browser_support" class="mw-headline">Browser support</span>:: O
Jeroen

3

É principalmente uma questão de preferência; não existe um padrão estabelecido, muito menos uma fonte autorizada, sobre o assunto. Use o que você se sentir mais confortável; apenas seja consistente.

Pessoalmente, eu uso css-style-with-dashes, mas tento evitar nomes de classes com várias palavras e usar várias classes sempre que possível ( button important defaulte não button-important-default). Pela minha experiência, essa também parece ser a escolha mais popular entre sites e estruturas de alta qualidade.

Letras minúsculas com traços também são mais fáceis de digitar do que as outras opções (excluindo a nowordseparatorswhatsoeverconvenção de difícil leitura ), pelo menos nos teclados dos EUA, porque não requer o uso da tecla Shift.

Para os IDs, existe a consideração prática adicional de que, se você quiser referenciar elementos por seu ID diretamente em javascript (por exemplo document.forms[0].btn_ok), traços não funcionarão tão bem - mas, se você estiver usando jQuery, provavelmente irá use-as de $()qualquer maneira, para que você possa ter $('#btn-ok'), o que torna esse ponto discutível.

Para o registro, outra convenção me deparo regularmente usa verrugas húngaras em ID de indicar o tipo de elemento, especialmente para controles de formulário - então você teria #lblUsername, #tbUsername, #valUsernamepara o rótulo nome de usuário, entrada e validador.


Obrigado pela resposta! Vou fazer uma recompensa, esperando que alguém tenha uma resposta que torne isso menos uma "questão de preferência". Se nenhum aparecer, certamente aceitarei sua resposta.
Jeroen

2

Eu acredito firmemente que o que mais importa é consistência.

Existem duas maneiras de analisar isso:

  1. Um bom argumento pode ser feito a favor alllowercaseou css-style-clauses(provavelmente a melhor escolha), porque eles serão os mais consistentes com o código em que serão inseridos. Isso proporcionará um fluxo mais natural ao código geral e nada será estridente ou fora do lugar .

  2. Um argumento igualmente bom pode ser feito para um estilo distinto dos nomes de tags HTML ou cláusulas CSS, se diferenciar IDs e classes de uma maneira que ajude a legibilidade. Por exemplo, se você usasse UpperCamelCaseIDs e classes, e não o utilizasse para qualquer outra construção ou finalidade, saberia que havia encontrado um toda vez que visse um token nesse formato. Uma restrição que isso pode impor é que seria mais eficaz se cada ID ou classe tivesse um nome com mais de 2 palavras, mas isso é razoável em muitos casos.

Ao escrever esta resposta, descobri que estou muito mais inclinado para a segunda opção, mas deixarei as duas porque acho que ambas as hipóteses têm mérito.


-1

É tudo uma questão de preferência, realmente, ou uma questão de preguiça. O CamelCasing é mais fácil de digitar, mas eu prefiro usar a notação de sublinhado, pois acho pessoalmente mais fácil ler e depurar do que o CamelCase. Não existe uma convenção de codificação a ser cumprida; nunca trabalhei em um local que tivesse as mesmas diretrizes de codificação do local anterior.

A maioria das empresas possui diretrizes em que geralmente é necessário respeitar qualquer forma de manter o código limpo e fácil para todos trabalharem. Se você é freelancer, pode se esforçar ao máximo, pois é a única pessoa que trabalha no código. Na minha opinião, existem apenas duas convenções de codificação: CamelCase ou Underscore notation. Meu conselho é escolher um e depois ficar com ele.


-3

Você parece alheio a um fato simples: a maioria das CSS não é feita por programadores .

É feito por designers gráficos.

Eles não se importam com nossas guerras de edição e não se importam com o que fazemos com a tecla Shift.
Eles provavelmente nem sabem onde está essa _chave sofisticada . (ou qual é o nome dele)

Eles não se preocupam com a estética do código , eles se preocupam com a estética estética .

(E eles podem ter um ponto lá)

Eles não leem as especificações , recebem o tutorial.
E, em seguida, verifique novamente as referências no w3schools.

Alguns deles provavelmente acreditam que não podem usar nomes de classe em maiúsculas por motivos.
Eles estão cheios de equívocos estranhos, principalmente irrelevantes.


3
Eu acho que isso depende de onde você trabalha, eu trabalhei com designers que são bastante militantes em relação aos padrões; Pelos sons de coisas que você está acostumado a trabalhar com desenvolvedores front-end inexperientes ou designers de impressão que se disfarçam de web designers. Além disso, faço uma quantidade razoável de CSS em meus projetos, assim como alguns dos meus colegas de trabalho, acho que a divisão de design / programação realmente depende da dinâmica da empresa.
Ed James
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.