Considérations pratiques pour les conventions de dénomination HTML / CSS (syntaxe) [fermé]


28

Question: quelles sont les considérations pratiques pour la syntaxe classet les idvaleurs?

Notez que je ne pose pas de questions sur la sémantique , c'est-à-dire les mots réels qui sont utilisés, comme par exemple décrit dans ce blog . Il existe déjà de nombreuses ressources de ce côté des conventions de nommage, obscurcissant en fait ma recherche d'informations pratiques sur les différents bits syntaxiques : casse, utilisation de l'interponction (en particulier le -tiret), caractères spécifiques à utiliser ou à éviter, etc.

Pour résumer les raisons pour lesquelles je pose cette question:

  • Les restrictions de nommage sur id et classe ne conduisent naturellement à aucune convention
  • L'abondance de ressources du côté sémantique des conventions de dénomination obscurcit les recherches sur les considérations syntaxiques
  • Je n'ai trouvé aucune source autorisée sur ce
  • Il n'y avait pas encore de question sur les programmeurs SE sur ce sujet :)

Certaines des conventions que j'ai envisagées d'utiliser:

  1. UpperCamelCase, principalement comme habitude croisée du codage côté serveur
  2. lowerCamelCase, pour la cohérence avec les conventions de dénomination JavaScript
  3. css-style-classes, ce qui est cohérent avec la dénomination des propriétés css (mais peut être gênant lorsque Ctrl + Shift + ArrowKey sélectionne du texte)
  4. with_under_scores, que je n'ai personnellement pas vu beaucoup utilisé
  5. alllowercase, simple à retenir mais peut être difficile à lire pour les noms plus longs
  6. UPPERCASEFTW, comme un excellent moyen d'agacer vos collègues programmeurs (peut-être combiné avec l'option 4 pour la lisibilité)

Et j'ai probablement laissé de côté certaines options ou combinaisons importantes. Alors: quelles considérations y a-t-il pour les conventions de dénomination et à quelle convention mènent-elles?


CamelCaseEverythingInCode
Ryathal

11
BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)
Jeroen

Je classe généralement les minuscules et CamelCase tout le reste. Pas de raison particulière
Antarr Byrd

"css-style-classes, ce qui est cohérent avec la dénomination des propriétés css (mais peut être ennuyeux lorsque Ctrl + Shift + ArrowKey sélection du texte)" - n'est un problème que si vous utilisez un éditeur de texte sous-optimal ;-)
tdammers

@Ryathal qui est PascalCase (ou UpperCamelCase), camelCase (ou lowerCamelCase) ressemble à ceciExample.
Danny Varod du

Réponses:


18

Bounty ou non, dans une certaine mesure, le choix sera toujours une "question de préférence" - après tout, comment vous sentiriez-vous si le W3C recommandait (ou même imposait) une certaine convention que vous ne jugiez pas correcte?

Cela dit, cependant, je préfère personnellement la lowerCamelCaseconvention, et je donnerai les raisons et les considérations pratiques que j'ai utilisées pour me décider - je le ferai par un processus d'élimination, en utilisant la numérotation de votre question:

(5.) n'est pas facilement lisible parce que vous ne savez pas où commencer.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTTING.

(4.) historic_incompatibility_plus_see: Documentation Mozilla Dev .

(3.) un peu plus compliqué à expliquer ... comme vous le mentionnez, la sélectionnabilité dans les éditeurs de texte est un problème (comme avec les traits de soulignement, selon l'éditeur), mais pour moi, c'est aussi le fait que cela me rappelle la syntaxe réservée aux mots clés spécifiques au fournisseur , même si ceux-ci commencent par un tiret ainsi que par des mots séparés par eux.

Donc, cela laisse votre (1.) et (2.), UpperCamelCase et lowerCamelCase, respectivement. Malgré le lien mental avec les classes Java (qui sont, par une convention plus clairement définie, UpperCamelCase), les noms de classe CSS semblent, à mon avis, mieux vaut commencer par une lettre minuscule. C'est peut-être à cause des noms d'éléments et d'attributs XHTML , mais je suppose que vous pourriez également faire valoir que le fait d'avoir des classes CSS utilisant UpperCamelCase aiderait à les différencier. Si vous avez besoin d'une autre raison, lowerCamelCase est ce que le W3C utilise dans les exemples de bons noms de classe (bien que l'URL elle-même, de manière ennuyeuse, soit en désaccord avec moi).

Je déconseille (4.), (5.) et (6.), pour les raisons indiquées ci-dessus, mais je suppose que des arguments pourraient être avancés pour l'un ou l'autre des trois autres.

Que vous (ou quelqu'un d'autre d'ailleurs) soyez d'accord avec moi sur cette question dépend de vous. Le fait que vous n'ayez pas de réponse définitive citant des sources faisant autorité à ce jour peut être considéré comme un indice qu'il n'existe pas de norme définitive sur cette question (sinon nous l'utiliserions tous). Je ne suis pas sûr que ce soit nécessairement une mauvaise chose.


Merci! Vous mentionnez (comme la plupart des autres réponses) que c'est une question de préférence, mais le complétez également par quelques conseils pratiques et quelques bons liens sur les considérations les plus importantes (telles que la one_on_icompatability). Même si j'envisage toujours de suivre la suggestion de la réponse de @tdammers (nommer avec des tirets), la réponse donnée ici est celle qui répond réellement à la question que j'ai posée. Donc: prime + acceptée, et merci beaucoup :)
Jeroen

Merci beaucoup en retour - tant que vous restez cohérent, je pense que n'importe lequel de ces trois est bien. Il n'y a pas grand-chose entre eux, et si vous regardez les sites à travers le net, je suis sûr que vous trouverez de nombreux exemples de chacun ;-)
Amos M. Carpenter

+1 Cependant, je suis sûr que c'est nécessairement une mauvaise chose. Bien que je sois tout à fait favorable aux efforts de normalisation de la communauté sur les conventions de dénomination, de formatage et de style général , le manque d'uniformité peut faire de l'héritage de projet un cauchemar ( pour ne pas dire qu'un tel cauchemar serait atténué par les normes, ils ne seraient probablement pas suivi ) Le fait que CSS, faible et déclarative, est imbriqueraient avec le client et la logique application côté serveur , même que des crochets simples, il aspire à la structure unifiée ( par elle languit, je veux dire que je languir )
Dan Lugg

Je suis tout à fait d'accord pour éviter les soulignés (sauf peut-être pour les noms d'ID si votre code côté serveur utilise des soulignés). Les tirets ne peuvent pas être utilisés comme séparateurs dans les langages de programmation car le trait d'union est également l'opérateur moins. Mais dans tout autre contexte où vous pourriez utiliser des traits de soulignement, je pense que les tirets sont un choix plus naturel - plus faciles à saisir et pour les URL, plus visibles lorsqu'une URL est soulignée.
Matt Browne

7

Les mots dans les noms de classe CSS doivent être séparés par des tirets ( class-name), car c'est ainsi que les mots dans les propriétés CSS et les pseudo-classes sont séparés et leur syntaxe est définie par les spécifications CSS .

Les mots dans les noms d'ID doivent également être séparés par des tirets, pour correspondre au style syntaxique des noms de classe et parce que les noms d'ID sont souvent utilisés dans les URL et le tiret est le séparateur de mots original et le plus courant dans les URL.


Ah +1, j'aime la mention des identifiants dans les URL. Bien que le plus drôle soit, pour faire quelques recherches, je suis allé vérifier comment Wikipedia le fait. Par exemple, la section de support Browswer de l'article CSS Wikipedia a donné <span id="Browser_support" class="mw-headline">Browser support</span>:: O
Jeroen

3

C'est surtout une question de préférence; il n'existe aucune norme établie, et encore moins une source faisant autorité, en la matière. Utilisez ce qui vous convient le mieux; soyez juste cohérent.

Personnellement, j'utilise css-style-with-dashes, mais j'essaie d'éviter les noms de classe multi-mots et d'utiliser plusieurs classes autant que possible (donc button important defaultplutôt que button-important-default). D'après mon expérience, cela semble également être le choix le plus populaire parmi les sites Web et les cadres de haute qualité.

Les minuscules avec des tirets sont également plus faciles à taper que les autres options (à l'exception de la nowordseparatorswhatsoeverconvention difficile à lire ), au moins sur les claviers américains, car cela ne nécessite pas l'utilisation de la touche Maj.

Pour les identifiants, il y a la considération pratique supplémentaire que si vous voulez référencer les éléments par leur ID directement en javascript (par exemple document.forms[0].btn_ok), les tirets ne fonctionneront pas si bien - mais alors, si vous utilisez jQuery, vous allez probablement utilisez-les de $()toute façon, alors vous pouvez simplement en avoir $('#btn-ok'), ce qui rend ce point principalement théorique.

Pour mémoire, une autre convention que je tombe sur utilise régulièrement les verrues hongrois dans ID de pour indiquer le type d'élément, en particulier pour les contrôles de formulaire - de sorte que vous auriez #lblUsername, #tbUsername, #valUsernamepour l'étiquette de nom d' utilisateur, entrée et validateur.


Merci d'avoir répondu! Je vais mettre en place une prime, en espérant que quelqu'un ait une réponse qui en fasse moins une "question de préférence". Si aucun ne se présente, je serai sûr d'accepter votre réponse.
Jeroen

2

Je crois fermement que ce qui importe le plus, c'est la cohérence.

Il y a deux façons de regarder ceci:

  1. Un bon argument peut être fait pour alllowercaseou css-style-clauses(probablement le meilleur choix) car ils seront les plus cohérents avec le code dans lequel ils seront. Cela donnera un flux plus naturel au code dans son ensemble et rien ne sera discordant ou déplacé. .

  2. Un argument tout aussi valable peut être avancé pour un style distinct des noms de balises HTML ou des clauses CSS, s'il différencie les ID et les classes de manière à faciliter la lisibilité. Par exemple, si vous l' UpperCamelCaseutilisiez pour des ID et des classes, et que vous ne l'utilisiez pour aucune autre construction ou fin, vous sauriez que vous en avez rencontré une à chaque fois que vous avez vu un jeton dans ce format. Une restriction que cela pourrait imposer est qu'il serait plus efficace si chaque ID ou classe était un nom de 2+ mots, mais c'est raisonnable dans de nombreux cas.

En écrivant cette réponse, j'ai découvert que je suis beaucoup plus enclin au deuxième choix, mais je vais laisser les deux parce que je pense que les deux cas ont du mérite.


-1

C'est vraiment une question de préférence ou de paresse. CamelCasing est plus facile à taper, mais je préfère utiliser la notation de soulignement car je trouve personnellement plus facile à lire et à déboguer que CamelCase. Il n'y a pas de convention de codage définie à respecter, je n'ai jamais travaillé dans un endroit qui avait les mêmes directives de codage que l'endroit précédent.

La plupart des entreprises ont des directives que vous devez généralement respecter pour garder le code propre et plus facile à travailler pour tout le monde. Si vous êtes pigiste, vous pouvez tout faire car vous êtes la seule personne à travailler sur le code. À mon avis, il n'y a que 2 conventions de codage à suivre: la notation CamelCase ou Underscore. Mon conseil est d'en choisir un, puis de le respecter.


-3

Vous semblez inconscient d'un simple fait: la plupart des CSS ne sont pas effectués par des programmeurs .

C'est fait par des graphistes.

Ils ne se soucient pas de nos guerres d'édition et ne se soucient pas moins de ce que nous faisons avec la touche Maj.
Ils ne savent même probablement pas où se trouve cette _clé fantaisie . (ou quel est son nom)

Ils ne se soucient pas de l' esthétique du code , ils se soucient de l' esthétique esthétique .

(Et ils peuvent avoir un point là-bas)

Ils ne lisent pas les spécifications , ils reçoivent le tutoriel.
Et puis revérifiez les références sur w3schools.

Certains d'entre eux croient probablement qu'ils ne peuvent pas utiliser de noms de classe en majuscules pour des raisons.
Ils sont pleins d'idées fausses étranges, pour la plupart non pertinentes.


3
Je suppose que cela dépend où vous travaillez, j'ai travaillé avec des designers assez militants sur les normes; Au son des choses, vous êtes habitué à travailler avec des développeurs frontaux inexpérimentés ou des concepteurs d'impression déguisés en concepteurs de sites Web. De plus, je fais une quantité raisonnable de CSS sur mes projets, comme le font un bon nombre de mes pairs au travail, je pense que la séparation conception / programmation dépend vraiment de la dynamique de l'entreprise.
Ed James
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.