Question: quelles sont les considérations pratiques pour la syntaxe class
et les id
valeurs?
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:
UpperCamelCase
, principalement comme habitude croisée du codage côté serveurlowerCamelCase
, pour la cohérence avec les conventions de dénomination JavaScriptcss-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)with_under_scores
, que je n'ai personnellement pas vu beaucoup utiliséalllowercase
, simple à retenir mais peut être difficile à lire pour les noms plus longsUPPERCASEFTW
, 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?
Réponses:
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
lowerCamelCase
convention, 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.
la source
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.
la source
<span id="Browser_support" class="mw-headline">Browser support</span>
:: OC'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 (doncbutton important default
plutôt quebutton-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
nowordseparatorswhatsoever
convention 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
,#valUsername
pour l'étiquette de nom d' utilisateur, entrée et validateur.la source
Je crois fermement que ce qui importe le plus, c'est la cohérence.
Il y a deux façons de regarder ceci:
Un bon argument peut être fait pour
alllowercase
oucss-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é. .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'
UpperCamelCase
utilisiez 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.
la source
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.
la source
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.
la source