Est-ce une mauvaise pratique de commenter des lignes simples de CSS avec //?
J'ai récemment commencé à utiliser // pour "commenter" une seule ligne de code CSS. Je comprends que je ne commente pas réellement la ligne; Je suis en train de le casser (je devrais utiliser /* ... */), mais cela a le même effet. La ligne est ensuite 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 remettre plus tard ou voir ce que j’utilisais si jy revenais.
Exemple:
li{
float:left;
//list-style-type:none;
text-indent:0px;
}
Est-ce que je peux m'en tirer ou est-ce que cela peut me causer des problèmes?
D'abord et avant tout: le code commenté est un 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 futurs navigateurs et/ou exotiques interpréteront des hacks non officiels comme //, il vaut donc mieux s'en tenir à la notation appropriée:
li {
float:left;
text-indent:0px;
/* list-style-type:none; */
}
Je constate que beaucoup de personnes se sont plaintes à ce sujet et qu’il s’agit d’une question plus ancienne, beaucoup de personnes le lisent en se demandant si cela est toujours vrai ou s’il existe au départ une norme. Permettez-moi de nettoyer l'air. Les principales raisons de la stratégie de commentaire CSS stricte sont les suivantes:
# 1 Ce n'est pas standard
Normalement au moins depuis CSS 2.1, les commentaires doivent UNIQUEMENT être placés dans /* et */. Bien que certains navigateurs tolèrent //, ils ne sont pas censés le faire et ne se trouvent qu’à un pouce de quelqu'un disant "oh ouais, c’est non standard" ou "hé! C’est non standard, corrigez-le!"; et ensuite devinez quoi, votre code CSS, qui fonctionnait, ne fonctionne plus pour des milliers de personnes (et peut-être déjà ne fonctionne pas pour des centaines d'autres). J'ajouterai que <!-- et --> 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 ancien qu'il ne peut pas ignorer les balises <style>, il est probablement temps d'installer un nouveau navigateur il y a 10 ans. Même Lynx et les autres navigateurs texte ne savent pas les lire. Il est donc utile de les commenter uniquement dans les situations très isolées où le matériel et les logiciels sont enclavés dans leur état de fonctionnement actuel.
# 2 Ce n'est pas (très) convivial multi-plateforme
Le commentaire sur une seule ligne, qui commence n'importe où sur une ligne avec //, est terminé par 'newline' qui n'est/ne est pas un caractère normalisé multiplateforme. 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é Ce n’était pas censé être, vous n’avez pas besoin d’être un génie pour savoir quelles en seraient les conséquences, surtout si vous contrôlez les fonctionnalités de votre site uniquement via CSS, ce que beaucoup font.
# 3 La norme IS Amical et uniforme à tous
Les délimiteurs /* et */ vont TOUJOURS être les mêmes caractères sur CHAQUE ordinateur, quels que soient l'architecture, le système d'exploitation, etc.
# 4 Newlines sont des espaces blancs
La dernière raison (oui, il y en a un de plus), les caractères de nouvelle ligne sont considérés (en CSS et dans beaucoup d'autres langues) comme des espaces, et */ n'est pas des espaces, n'est-ce pas? Et si vous y réfléchissez à ce stade, il devrait être assez clair que vous ne devriez PAS utiliser un espace pour mettre fin à un commentaire, d'autant plus que cet espace est et peut être supprimé par de nombreux analyseurs HTML/CSS, ou reformaté sans que vous le sachiez.
# 5 CSS! = C/C++
Maintenant, si vous êtes sur le point de quitter votre siège et de crier après moi: "Hé, mais C++ ...", rappelez-vous que les compilateurs et les IDE intègrent des tonnes de contrôles et de détections de nouvelle ligne afin qu'ils puissent le prendre. La plupart des compilateurs ne reformulent pas votre code à moins d'y être invité, et de nombreux IDE vous demanderont généralement quel type de nouvelle ligne votre document utilise s'il ne peut le deviner seul. Si nous faisions cela avec les pages CSS pour l'utilisateur final à chaque fois qu'une page était chargée, imaginez le cauchemar qu'elle essaierait de contourner. De plus, le code C/C++ n'est pas analysé au moment de l'exécution et est compilé. Par conséquent, la plupart du temps, l'utilisateur n'obtient jamais le document en question. Les fichiers source ne sont pas constamment visionnés par le monde entier sur des centaines de plates-formes et de nombreux systèmes d'exploitation, ainsi que par un million de navigateurs différents. Les commentaires sont supprimés avant même qu'ils ne parviennent à l'utilisateur final. La source CSS vient directement sur le navigateur de l'utilisateur et doit être très résistante, ne sachant pas ce qui se passe de l'autre côté. Il faut donc être prêt pour tout ce que l'utilisateur final a ou a à faire, pas ce que le développeur a fait ou a!
# 6 c'est gênant
Non, il est très pénible de devoir taper ce code */ supplémentaire, mais c'est principalement aux développeurs de logiciels d'édition CSS qui n'offrent pas la complétude automatique. Si vous utilisez un éditeur spécialisé capable de le faire, de préférence prêt à l'emploi, vous constaterez qu'il 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 vous facilitera la tâche. 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 aide tout le monde à comprendre le "pourquoi" derrière le "comment", et je me souviens simplement que quelque chose fonctionne pour vous, cela ne signifie pas que c'est la norme, et pour résumer:
OUI, IL IS MAUVAISE PRATIQUE à 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, il suffit de graver cette image dans votre esprit (merci à ceux d’entre vous qui n’ont rien de mieux à faire que de faire des photos comme celle-ci):
PS: Si vous voulez vraiment vous plaindre de ceux qui élaborent/enfreignent les normes CSS (W3C, elbow), quelqu'un entame une discussion sur le caractère inutilement long et faux du mot clé "! Important"! Mais cela ne fait pas partie de cette question, je ne vais donc pas en parler.
Références
- W3C : Brouillon de travail CSS 2.1: caractères de commentaire.
- W3C : Module de syntaxe CSS de niveau 3: diagrammes de voies ferrées comportant des interprétations d'analyseurs de caractères.
- Débordement de pile : Divers articles sur le débordement de pile ayant pratiquement le même sujet que celui-ci.
- w3schools : Norme de syntaxe CSS 3 (qui à son tour fait référence à W3C).
- sitepoint : Annotation de la syntaxe CSS sur "ne pas utiliser de double barre oblique".
- mozilla | mdn : Le traitement assoupli de CSS 3 permet une double barre oblique dans les fichiers d'entrée.
J'ai récemment lu cet article qui met en lumière la pratique de commentaire d'une seule ligne en CSS.
CSS vous permet d'utiliser // après une mode. Ce n'est pas tout à fait un commentaire de ligne, mais un prochain commentaire de construction. Autrement dit, chaque fois que vous utilisez //, la prochaine construction CSS - déclaration ou bloc - sera "commentée".
Donc, dans votre extrait de code, list-style-type:none est la prochaine construction CSS 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 // uniquement pour écrire des commentaires dans votre feuille de style, vous devez faire attention: le texte brut n'est pas une construction CSS. Par conséquent, il va au-delà de cela et commente la construction suivante de votre page. Donc, dans l'extrait ci-dessous
// Do some stuff.
.foo { animation: bar 1s infinite; }
Cela mettra en commentaire le bloc .foo.
Vous pouvez obtenir plus d'informations via l'article lié mentionné au début.
Selon le Working Draft , rien de tel qu'un commentaire d'une seule ligne.
Oui, je pense que l'utilisation de commentaires sur une seule ligne dans leur état actuel est une mauvaise pratique.
Pour commencer, si vous travaillez au sein d’une équipe, la maintenabilité/lisibilité du code revêt une importance primordiale. Même si vous travaillez seul, écrire du code maintenable est toujours une bonne pratique. Dans le cas contraire, la folie s’ensuivra.
Lorsque vous commencez à utiliser des commentaires sur une seule ligne, la facilité de maintenance et la lisibilité sont gênées, les surligneurs de syntaxe des éditeurs ne mettent pas en évidence votre commentaire et il deviendra difficile de distinguer les commentaires des règles.
En outre, les commentaires sur une ou plusieurs lignes ne sont pas interchangeables, par exemple, vous ne pouvez pas utiliser de commentaires en texte brut sans utiliser de hack, mais vous pouvez uniquement commenter les constructions //.foo {...} ou les règles .foo {//height:10px}.
Instance non interchangeable:
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 (à cause du constructeur vide hack _):
ul.images {
padding: 0;
//static height value{};
height: 270px;
margin: 0 auto;
}
ul.images {
padding: 0;
/*static height value*/
height: 270px;
margin: 0 auto;
}
Bien que l’utilisation du constructeur {}; comme postfixe fonctionne, cela ne change pas le but de l’utiliser, car vous utiliserez plus caractères; un commentaire sur plusieurs lignes utilise quatre caractères, /**/, tandis qu'un commentaire sur une seule ligne avec hack utilise cinq caractères, //{};
La dernière mise en garde concernant les commentaires sur une ligne qui n'a pas encore été mentionnée est que Chrome les outils de développement masqueront les règles de commentaire, plutôt que de vous permettre de les basculer.
Outils de développement Chrome (commentaire sur plusieurs lignes):
Outils de développement Chrome (commentaire sur une seule ligne):
Un bon cas d'utilisation, IMO, pour les commentaires d'une seule ligne serait lorsque 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 conclusion, si vous essayez de déboguer quelque chose pendant le développement, je ne vois pas le mal à commenter un constructeur avec des commentaires sur une seule ligne pour éliminer un bogue. Si vous êtes en train de déboguer, ce sera temporaire. Cela dit, je ne vois aucun cas d'utilisation de texte brut, donc je ne recommanderais certainement pas de les utiliser ici.
Je recommanderais de ne pas commenter les CSS de cette manière quand ce n'est pas nécessaire. Supprimez les éléments dont vous n’avez pas besoin et envoyez-les dans 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 cruels, rendant votre code plus difficile à lire et à comprendre.
J'utilise // pour "commenter" les lignes des fichiers .css tout le temps. Parce que c'est lié à un raccourci dans Vim , et j'oublie toujours ce que je suis en train d'éditer. En JavaScript, il est très pratique de commenter des blocs de code, de tester le code et de "commenter" le bloc de code à nouveau (raccourcis, oui).
Mais lorsque je nettoie mon fichier .css, j'utilise les constructions suivantes pour déplacer plus facilement les déclarations dans et hors de leur portée:
.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'ajouter à la zone commentée, et inversement. Dans .shadow, je viens de redéclarer la même propriété avec une valeur différente.
C'est pénible.
Comme d’autres l’ont dit, utiliser une double barre oblique n’est pas conforme aux normes, mais si vous vraiment voulez l’utiliser ET voulez être conforme aux normes ET que gcc soit installé, vous pouvez exécuter votre code CSS via cpp -P barre oblique et/* ... */commentaires du CSS. En prime, vous pouvez utiliser des macros, des inclusions et des conditions, et les commentaires ne sont pas téléchargés par le navigateur (amélioration de la performance mineure).
Le seul problème majeur est l’utilisation de balises id autonomes (c.-à-d. #para { ... }) où cpp barfs. Solution il y a le double du # (à ##) et passe la sortie à travers 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.
Pour commentaires CSS en ligne , j'utilise:
.myDiv {
@width:750px;
}
ou n'importe quel caractère que vous voulez (c'est-à-dire *@!ZZ) Ainsi, la propriété devient inconnue et n'est pas lisible par css.
Commentaire en HTML:
<!--........................-->
<!-- <input type="text" name="lastname">-->
Commentaire en JavaScript:
Commentaire sur une seule ligne:
Deux barres obliques "//" devant le code:
//document.write("Try this");
Commentaire multiligne:
<script type="text/javascript">
<!--
/* document.write("try this!");
document.write("try this"); */
//-->
</script>
Code de commentaire en CSS:
/*
.tblemp {
color:red; }
*/
Juste pour ajouter des informations supplémentaires et confirmer la règle "utiliser uniquement/* commentaires". Un client ayant accès au dossier du site Web choisit simplement de commenter une seule ligne en utilisant ceci:
//* comment here *//
En fait Chrome et Safari ignorera TOUT ce qui suit cette ligne; Je l'appellerais un "tueur de CSS".