Est-ce une mauvaise pratique de commenter des lignes simples de CSS avec //?

J’ai récemment commencé à utiliser // pour “commenter” des lignes simples de code CSS. Je comprends que je ne commente pas réellement la ligne; Je ne fais que le casser (je devrais utiliser /* ... */ ), mais cela a le même effet. La ligne est alors terminée par le ; et le code suivant fonctionne correctement.

Je pourrais le supprimer, mais souvent je préfère ne pas le faire au cas où je voudrais le réinsérer plus tard ou voir ce que j’avais utilisé si j’y reviens.

Exemple:

 li{ float:left; //list-style-type:none; text-indent:0px; } 

Puis-je m’en sortir ou est-ce que cela risque de me causer des problèmes?

Avant tout: le code commenté est une odeur de code et doit être évité. Je suppose que vous utilisez un VCS comme Git , qui gère le code historique pour vous.

Mais si vous voulez vraiment travailler de cette façon: vous ne savez pas comment les navigateurs futurs et / ou exotiques interpréteront les hacks non-officiels comme // , vous devriez donc vous en tenir à la notation appropriée:

 li { float:left; text-indent:0px; /* list-style-type:none; */ } 

Je vois qu’il y a beaucoup de gens qui se plaignent de cela et comme il s’agit d’une question plus ancienne, il y a probablement beaucoup de gens qui se demandent si c’est toujours vrai ou s’il y a en fait une norme. Permettez-moi de vider l’air. Les principales raisons de la politique de commentaires CSS ssortingcte sont les suivantes:

# 1 Ce n’est pas standard

Standardisés au moins depuis CSS 2.1, les commentaires doivent être UNIQUEMENT encapsulés dans /* et */ . Alors que certains navigateurs tolèrent // , ils ne sont pas censés le faire, et ne sont qu’à un pouce de quelqu’un qui dit “oh oui c’est non standard” ou “hé! C’est non-standard, répare!”; puis devinez quoi, votre code CSS, qui fonctionnait, ne convient plus à des milliers de personnes (et peut-être ne fonctionnait pas déjà pour des centaines d’autres). J’appendai que sont autorisés mais seulement (et je veux dire UNIQUEMENT) lorsqu’ils apparaissent dans un document HTML, pas dans un fichier source .css. Si votre navigateur est si vieux qu’il ne peut pas ignorer les balises

, il est probablement temps pour un nouveau navigateur il y a 10 ans. Même les navigateurs Lynx et les autres navigateurs ne savent pas les lire, donc les commenter n'est utile que dans des situations très isolées où le matériel et les logiciels sont enclavés dans leur état de fonctionnement actuel.

# 2 Il n'est pas (très) multi-plateforme convivial

Le commentaire sur une seule ligne, qui commence n'importe où sur une ligne avec // , se termine par «newline», qui n'est pas un caractère standardisé multi-plateforme. Pire, certains pourraient avoir un caractère pour une nouvelle ligne, ou 2 ... et lorsque ces plates-formes se mélangent, une nouvelle ligne pourrait être perdue, et votre terminateur disparaît ... et tout ou partie de votre code est maintenant commenté n'était pas censé être, vous n'avez pas besoin d'être un génie pour savoir quelles pourraient en être les conséquences, surtout si vous contrôlez les fonctionnalités de votre site uniquement via CSS, ce que beaucoup font.

# 3 La norme est conviviale et uniforme pour tous

Les délimiteurs /* et */ seront TOUJOURS les mêmes caractères sur chaque ordinateur, indépendamment de l'architecture, du système d'exploitation, etc.

# 4 Les nouvelles lignes sont des espaces blancs

La dernière raison (oui, il y en a une de plus), les caractères de nouvelle ligne sont considérés (en CSS et dans de nombreux autres langages) comme des espaces, et */ n'est pas un espace blanc? Et si vous y réfléchissez à ce stade, il devrait être clair que vous ne devriez PAS utiliser un espace pour terminer un commentaire, car les espaces sont et peuvent être supprimés par de nombreux parsingurs HTML / CSS, ou reformatés sans que vous le sachiez.

# 5 CSS! = C / C ++

Maintenant, si vous êtes sur le sharepoint quitter votre siège et de me crier dessus "Hey, mais C ++ ...", rappelez-vous que ces compilateurs et IDE ont des tonnes de vérification et de détection de nouvelles lignes intégrées. La plupart des compilateurs ne reformatent pas votre code à moins d'y être invité, et de nombreux IDE vous demanderont généralement quel type de nouvelles lignes votre document utilise s'il ne peut pas le deviner. Si nous faisions cela avec des pages CSS pour l'utilisateur final à chaque chargement, imaginez le cauchemar qu'il essaierait de contourner. De plus, le code C / C ++ n'est pas analysé au moment de l'exécution et est compilé, donc la plupart du temps, l'utilisateur ne reçoit jamais le document en question. Les fichiers sources ne sont pas constamment consultés par le monde entier sur des centaines de plates-formes et de nombreux systèmes d'exploitation, ainsi que sur un million de navigateurs différents. Les commentaires sont supprimés avant même d'arriver à l'utilisateur final. La source CSS vient directement dans le navigateur de l'utilisateur et doit être très résistante, ne sachant pas ce qui se trouve de l'autre côté. La mise en garde est qu'elle doit être prête à tout ce que l'utilisateur final a ou ne fait pas!

# 6 C'est gênant

Non, c'est très ennuyeux de devoir taper ce fichier supplémentaire */ , mais la faute en incombe principalement aux développeurs de logiciels d'édition CSS qui n'offrent pas de complétion automatique. Si vous utilisez un éditeur spécialisé capable de le faire, de préférence prêt à l'emploi, vous constaterez que c'est aussi simple que d'utiliser // . Prenez l'habitude de taper /**/ puis de revenir en arrière 2, cela vous aidera à ne pas oublier et à le rendre un peu plus facile. Mieux encore, vous pouvez configurer une touche de raccourci pour simplement les définir pour vous. Windows et Linux ont tous deux des outils puissants pour permettre cela (KDE est très bon pour cela).


J'espère que cela aidera tout le monde à comprendre le «pourquoi» derrière le «comment», et souvenez-vous simplement que quelque chose fonctionne pour vous, cela ne signifie pas que c'est la norme et que vous devez résumer:

OUI, C'EST MAUVAIS LA PRATIQUE de l'utiliser, il suffit de dire NON à la double barre oblique !!! Si vous avez besoin d'une aide visuelle pour vous rappeler ce fait important, gravez simplement cette image dans votre esprit (grâce à ceux d'entre vous qui n'ont rien de mieux à faire que de faire des photos comme celle-ci):

Pas de double slash


PS: Si vous voulez vraiment que quelque chose se plaint à ceux qui font / défont les normes CSS (W3C, elbow), quelqu'un commence à discuter de la longueur et de l'inutilité du mot-clé "! Important"! Mais cela ne fait pas partie de cette question donc je ne vais pas y aller.

Les références

  • W3C : brouillon de travail CSS 2.1: caractères de commentaire.
  • W3C : Module de syntaxe CSS niveau 3: diagrammes de chemin de fer des interprétations de parseur à caractère.
  • Stack Overflow : Divers articles Stack Overflow avec pratiquement le même sujet que celui-ci.
  • w3schools : norme de syntaxe CSS 3 (qui à son tour fait référence au W3C).
  • sitepoint : Annotation de la syntaxe CSS sur "ne pas utiliser de double barre oblique".
  • mozilla | mdn : le traitement CSS 3 détendu permet une double barre oblique dans les fichiers d'entrée.

J’ai récemment lu cet article qui met beaucoup de lumière sur la pratique des commentaires sur une seule ligne en CSS.

CSS vous permet d’utiliser // après un certain temps. Ce n’est pas tout à fait un commentaire de ligne, mais un commentaire de construction suivant . Autrement dit, chaque fois que vous utilisez // , la construction CSS suivante – soit une déclaration, soit un bloc – sera “commentée”.

Donc, dans votre extrait de code, list-style-type:none est la construction CSS suivante et elle est commentée.

 li { float:left; //list-style-type:none; text-indent:0px; } 

De même, dans l’extrait de code ci-dessous

 //@keyframes foo { from, to { width: 500px; } 50% { width: 400px; } } @keyframes bar { from, to { height: 500px; } 50% { height: 400px; } } 

le // commentera la première déclaration @keyframes .

Si vous essayez d’utiliser // juste pour écrire des commentaires dans votre feuille de style, vous devez faire attention – le texte brut n’est pas une construction CSS, donc ça passera au-delà et commentera la construction suivante dans votre page. Donc, dans l’extrait ci-dessous

 // Do some stuff. .foo { animation: bar 1s infinite; } 

Cela va commenter le bloc .foo .

Vous pouvez obtenir plus d’informations via l’article lié mentionné au début.

Selon le document de travail , rien ne vaut un commentaire sur une seule ligne.

Oui, je pense que l’utilisation de commentaires sur une seule ligne dans leur état actuel est une mauvaise pratique.

Pour les débutants, si vous travaillez dans un environnement d’équipe, la maintenabilité / lisibilité du code est primordiale, et même si vous travaillez seul, l’écriture de code maintenable est toujours une bonne pratique, sinon la folie s’ensuivra.

Lorsque vous commencez à utiliser des commentaires sur une seule ligne, la maintenabilité et la lisibilité sont entravées, les surligneurs de syntaxe dans les éditeurs ne mettent pas en évidence votre commentaire et il devient difficile de distinguer les commentaires des règles.

Comparaison de commentaires simples et multi-lignes

De plus, les commentaires sur une ou plusieurs lignes ne sont pas interchangeables, par exemple, vous ne pouvez pas utiliser les commentaires en texte brut sans utiliser un hack, mais vous pouvez uniquement commenter les constructions //.foo {...} ou les règles .foo {//height:10px} .

Instance immuable:

 ul.images { padding: 0; //static height value height: 270px; margin: 0 auto; } ul.images { padding: 0; /*static height value height: 270px;*/ margin: 0 auto; } 

Maintenant interchangeable (en raison d’un hack de constructeur vide):

 ul.images { padding: 0; //static height value{}; height: 270px; margin: 0 auto; } ul.images { padding: 0; /*static height value*/ height: 270px; margin: 0 auto; } 

En utilisant le constructeur {}; comme un postfix fonctionnera, il est impossible pour IMO de l’utiliser, car vous utiliserez plus de caractères; un commentaire sur plusieurs lignes utilise quatre caractères, /**/ , tandis qu’un commentaire sur une seule ligne avec le hack utilise cinq caractères, //{};

La dernière mise en garde concernant les commentaires sur une seule ligne, qui n’a pas encore été mentionnée, est que les outils de développement Chrome masqueront les règles commentées au lieu de vous permettre de les modifier.

Outils de développement Chrome (commentaire multi-ligne):

Entrez la description de l'image ici

Outils de développement Chrome (commentaire sur une seule ligne):

Entrez la description de l'image ici

Un bon exemple, IMO, pour les commentaires sur une seule ligne serait quand vous devez commenter un constructeur entier, ce qui est vraiment long (l’exemple ne le sera pas).

Commenter un constructeur entier

 //ul.images { padding: 0; height: 270px; margin: 0 auto; } /*ul.images { padding: 0; height: 270px; margin: 0 auto; }*/ 

En terminant, si vous essayez de déboguer quelque chose pendant le développement, je ne vois pas de mal à commenter un constructeur avec des commentaires sur une seule ligne pour éliminer un bogue. Si vous déboguez, ce sera temporaire. Cela dit, je ne vois aucun cas d’utilisation pour le texte brut, donc je ne recommanderais certainement pas de les utiliser ici.

Je recommanderais de ne pas commenter CSS comme ça quand ce n’est pas nécessaire. Supprimez les éléments inutiles et validez-les sur votre référentiel SVN ou GIT. Laissez-le faire son travail et gardez une trace de l’histoire pour vous. Les commentaires accumulés comme celui-ci deviennent vains, ce qui rend votre code plus difficile à lire et à comprendre.

J’utilise // pour «commenter» les lignes dans les fichiers .css tout le temps. Parce que c’est lié à un raccourci dans Vim , et j’oublie toujours ce que je modifie. En JavaScript, il est très pratique de commenter des blocs de code, de tester le code et de «commenter» dans le bloc de code (raccourcis, oui).

Mais lorsque je range mon fichier .css, j’utilise les constructions suivantes pour déplacer plus facilement les déclarations dans et hors de la scope:

 .pin { /* position: absolute; background: url(buttons-3x3.png); background-color: red; */ height:50px; width:150px; position: relative; } .shadow { margin-top: 25px; margin-left: 25px; margin-left: 60px; width:50px; height:50px; background: url(playground.png) -400px -100px; position: relative; position: absolute; } 

Dans .pin je peux supprimer une ligne et l’append à la zone commentée et inversement. Dans .shadow je ne fais que redéclarer la même propriété avec une valeur différente.

C’est une douleur.

!important

Comme d’autres l’ont dit, utiliser une double barre oblique n’est pas conforme aux normes, mais si vous voulez vraiment l’ utiliser ET que vous voulez être conforme aux normes ET que gcc est installé, vous pouvez exécuter votre CSS via cpp -P pour supprimer toute double barre oblique et / * … * / commentaires du CSS. En bonus, vous pouvez utiliser des macros, des inclusions et des conditionnels, et les commentaires ne sont pas téléchargés par le navigateur (amélioration mineure des performances).

Le seul problème majeur consiste à utiliser des tags d’ID autonomes (par exemple, #para { ... } ) où cpp barfs. La solution consiste à doubler le # (à ##) et à passer la sortie via sed, comme ceci:

 cpp -P site.cssin | sed -e 's/^##/#/' >site.css 

Je suis sûr qu’il existe de meilleurs préprocesseurs orientés CSS, mais cela a fonctionné pour moi.

Commentaire en HTML:

   

Commentaire en JavaScript:

Commentaire sur une seule ligne:

Deux barres obliques, “//”, devant le code:

 //document.write("Try this"); 

Commentaire multiligne:

  

Code de commentaire en CSS:

 /* .tblemp { color:red; } */ 

Plus de détails

Juste pour append des informations supplémentaires et confirmer la règle “only use / * comments”. Un client qui a access au dossier du site Web choisit lui-même de commenter une seule ligne en utilisant ceci:

 //* comment here *// 

En fait, Chrome et Safari ignorent tout ce qui suit cette ligne; Je l’appellerais un “tueur CSS”.

Pour les commentaires CSS intégrés , j’utilise:

 .myDiv { @width:750px; } 

ou n’importe quel caractère que vous voulez (c.-à-d. *@!ZZ ) Donc, la propriété devient inconnue et non lisible par css.