¿Es una mala práctica comentar líneas únicas de CSS con //?

Recientemente comencé a usar // para “comentar” líneas únicas de código CSS. Entiendo que en realidad no estoy comentando la línea; Solo lo estoy rompiendo (debería usar /* ... */ ), pero tiene el mismo efecto. La línea es terminada por el ; y el siguiente código funciona bien.

Podría eliminarlo, pero a menudo prefiero no hacerlo en caso de que desee volverlo a instalar más tarde o ver lo que he estado usando si vuelvo a él.

Ejemplo:

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

¿Puedo salirse con la tuya o es probable que me cause problemas?

Lo primero y más importante: el código comentado es un olor codificado y debe evitarse. Supongo que está utilizando un VCS como Git , que maneja el código histórico para usted.

Pero si realmente quieres trabajar de esta manera: no sabes cómo futuros y / o navegadores exóticos interpretarán hacks no oficiales como // , así que mejor te quedas con la notación adecuada:

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

Veo que hay / hay mucha gente quejándose de esto y dado que esta es una pregunta anterior, probablemente haya mucha gente que la lea preguntándose si todavía es cierta, o si realmente existe un estándar en primer lugar. Permíteme limpiar el air. Los siguientes son los motivos principales de la estricta política de comentarios de CSS:

# 1 No es estándar

Estandarizado al menos desde CSS 2.1, los comentarios SÓLO deben incluirse en /* y */ . Aunque algunos navegadores toleran // , se supone que no deben hacerlo, y están a solo una pulgada de que alguien diga “oh sí, eso no es estándar” o “¡hey! Eso no es estándar, ¡arréglenlo!”; y luego adivina qué, tu código CSS, que estaba funcionando, ahora no funciona para miles de personas (y puede que ya no haya funcionado para cientos de otros). Agregaré que están permitidos pero solo (y me refiero SOLAMENTE) cuando aparecen en un documento HTML, no en un archivo fuente .css. Si su navegador es tan antiguo que no puede omitir las tags

, probablemente haya llegado el momento de un nuevo navegador hace 10 años. Incluso Lynx y otros navegadores de texto saben que no deben leerlos, por lo que comentarlos solo es útil en situaciones muy aisladas en las que el hardware y el software no tienen salida al mar en su estado de trabajo actual.

# 2 No es (muy) compatible con plataformas cruzadas

El comentario de una sola línea, que comienza en cualquier lugar de una línea con // , termina con 'nueva línea' que no es / es un carácter (es) estandarizado multiplataforma. Peor aún, algunos pueden tener un carácter para una línea nueva, o 2 ... y cuando estas plataformas se mezclan, se puede perder una nueva línea, y ahí va su terminador ... y ahora se está comentando todo o parte de su código que se suponía que no era así, no tienes que ser un genio para saber cuáles podrían ser las consecuencias de esto, especialmente si controlas las características de tu sitio únicamente a través de CSS, lo que muchos hacen.

# 3 El estándar ES amigable y uniforme para todos

Los delimitadores /* y */ SIEMPRE serán los mismos caracteres en CADA computadora independientemente de la architecture, el sistema operativo, etc.

# 4 Newlines son espacios en blanco

La última razón (sí, hay una más), los caracteres de nueva línea se consideran (en CSS y en muchos otros idiomas) como espacios en blanco, y */ no es un espacio en blanco, ¿o sí? Y si lo piensas en este momento, debería ser bastante claro que NO deberías estar usando un espacio en blanco para terminar un comentario, especialmente dado que el espacio en blanco es y puede ser eliminado por muchos analizadores de HTML / CSS, o formateado sin que siquiera lo sepas.

# 5 CSS! = C / C ++

Ahora, si está a punto de abandonar su asiento y gritarme acerca de "Oye, pero C ++ ...", recuerde que los comstackdores y los IDE tienen montones de detección y detección de nueva línea incorporada en ellos para poder tomarlos. La mayoría de los comstackdores no reformatean el código, a menos que se lo solicite, y muchos IDEs generalmente le preguntan qué tipo de líneas nuevas utiliza su documento si no puede adivinar por sí mismo. Si hiciéramos esto con páginas CSS para el usuario final cada vez que se cargara uno, imagínese la pesadilla que estaría tratando de evitar. Además, el código C / C ++ no se analiza en tiempo de ejecución y se comstack, por lo que la mayoría de las veces, el usuario nunca obtiene el documento en cuestión en primer lugar. Los archivos fuente no están siendo constantemente vistos por todo el mundo en cientos de plataformas y muchos sistemas operativos, y un millón de navegadores diferentes. Los comentarios se eliminan antes de que lleguen al usuario final. La fuente de CSS llega directamente al navegador del usuario y tiene que ser muy flexible sin saber qué hay al otro lado, por lo que la advertencia es que debe estar lista para todo lo que el usuario final tenga o no, ¡nada que el desarrollador tenga o tenga!

# 6 Es inconveniente

No, es muy molesto tener que escribir ese extra */ , pero la culpa la tienen principalmente los desarrolladores de software de edición de CSS que no ofrecen autocompletado. Si utiliza un editor especializado que pueda hacer eso, preferiblemente de manera predeterminada, entonces encontrará que es tan fácil como usar // . Adquiera el hábito de escribir /**/ y luego retroceda 2, le ayudará a no olvidarlo y lo hará un poco más fácil. Mejor aún, puede configurar una tecla de acceso rápido para que solo los coloque. Windows y Linux tienen potentes herramientas para permitir esto (KDE es muy bueno para eso).


Espero que esto ayude a todos a comprender el "por qué" detrás del "cómo", y recuerde que solo porque algo funciona para usted, no significa que sea el estándar, y para resumir:

SÍ, ES MALA PRÁCTICA usarlo, solo diga NO a la doble barra !!! Si necesita una ayuda visual para recordar este hecho importante, simplemente grabe esta imagen en su mente (gracias a aquellos de ustedes que no tienen nada mejor que hacer que hacer fotos como esta):

Sin doble barra


PD: si realmente quieres que te quejes con los que hacen / rompen los estándares de CSS (W3C, codo), alguien comienza una discusión sobre cuán innecesariamente larga y equivocada es la palabra clave "! Important". Pero eso no es parte de esta pregunta, así que no entraré en ello.

Referencias

  • W3C : borrador de trabajo de CSS 2.1: caracteres de comentario.
  • W3C : módulo de syntax CSS nivel 3: diagtwigs de trenes de interpretaciones de analizador a personaje.
  • Stack Overflow : varios artículos de Stack Overflow con prácticamente el mismo tema que este.
  • w3schools : estándar de syntax CSS 3 (que a su vez hace referencia al W3C).
  • sitepoint : anotación de syntax CSS en "no usar doble barra".
  • mozilla | mdn : el procesamiento relajado de CSS 3 permite una doble barra en los archivos de entrada.

Recientemente leí este artículo que arroja mucha luz sobre la práctica de comentarios de línea única en CSS.

CSS le permite usar // después de una moda. No se trata de un comentario de línea, sino de un siguiente comentario constructivo . Es decir, siempre que use // , la siguiente construcción de CSS, ya sea statement o bloque, será “comentada”.

Por lo tanto, en su fragmento de código list-style-type:none es el siguiente constructo CSS y se comenta.

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

Del mismo modo, en el siguiente fragmento de código

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

// comentará la primera statement de @keyframes .

Si intenta utilizar // solo para escribir comentarios en su hoja de estilo, debe tener cuidado: el texto sin formato no es una construcción de CSS, por lo que se verá más allá y comentará el siguiente constructo en su página. Entonces en el siguiente fragmento

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

Esto comentará el bloque .foo .

Puede obtener más información a través del artículo vinculado mencionado al comienzo.

De acuerdo con el Borrador de Trabajo , no hay nada como un comentario de una sola línea.

Sí, creo que usar comentarios de una sola línea en su estado actual es una mala práctica.

Para empezar, si trabaja en un entorno de equipo, entonces la capacidad de mantenimiento / legibilidad del código es de sum importancia, e incluso si trabaja solo, escribir un código que se pueda mantener es una buena práctica, de lo contrario, se generaría demencia.

Cuando comiences a utilizar comentarios de una sola línea, tanto el mantenimiento como la legibilidad se ven impedidos, los marcadores de syntax dentro de los editores no resaltarán tu comentario, y será difícil distinguir los comentarios de las reglas.

Comparación de comentarios de línea única y múltiple

Además, los comentarios de línea única y múltiple no son inclusivamente intercambiables, por ejemplo, no puede usar comentarios de texto sin usar un hack, sino que solo puede comentar construcciones //.foo {...} o reglas .foo {//height:10px} .

Instancia inintercambiable:

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

Ahora intercambiable (debido a un hack de constructor vacío):

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

Mientras usa el constructor {}; como funcionará un postfijo, IMO vence el propósito de usarlo, porque usará más caracteres; un comentario multilínea utiliza cuatro caracteres, /**/ , mientras que un comentario de una sola línea con el truco utiliza cinco caracteres, //{};

La última advertencia de los comentarios de una sola línea que aún no se ha mencionado, es que las herramientas de desarrollo de Chrome ocultan las reglas comentadas, en lugar de permitirle alternarlas.

Herramientas de desarrollador de Chrome (comentario de varias líneas):

Ingrese la descripción de la imagen aquí

Herramientas de desarrollador de Chrome (comentario de una sola línea):

Ingrese la descripción de la imagen aquí

Un buen caso de uso, IMO, para comentarios de línea única sería cuando necesite comentar un constructor completo, que es realmente largo (el ejemplo no será).

Comentando todo un constructor

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

Para terminar, si intenta depurar algo durante el desarrollo, no veo el inconveniente de comentar a un constructor con comentarios de una sola línea para descartar un error. Si estás depurando, será temporal. Dicho esto, no veo ningún caso de uso para el texto sin formato, así que definitivamente no recomendaría su uso allí.

Recomiendo no comentar CSS de esta manera cuando no sea necesario. Elimine las cosas que no necesita y comprométalas con su repository SVN o GIT. Deje que haga su trabajo y haga un seguimiento de la historia por usted. Los comentarios acumulados como este se convierten en errores que hacen que su código sea más difícil de leer y entender.

Uso // para ‘comentar’ líneas en archivos .css todo el tiempo. Porque está vinculado a un atajo en Vim , y siempre me olvido de lo que estoy editando. En JavaScript, es muy útil comentar bloques de código, probar el código y ‘comentar’ el bloque de código nuevamente (atajos, sí).

Pero cuando ordeno mi archivo .css, uso las siguientes construcciones para mover las declaraciones más fácilmente dentro y fuera del 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; } 

En .pin puedo eliminar una línea y agregarla al área comentada y viceversa. En .shadow , redeclaro la misma propiedad con un valor diferente.

Es un dolor.

!importante

Como han dicho otros, usar una doble barra no es compatible con los estándares, pero si realmente quieres usarla Y quieres cumplir con los estándares Y tienes instalado gcc, puedes ejecutar tu CSS a través de cpp -P para quitar toda barra doble y / * … * / comentarios del CSS. Como beneficio adicional, puede usar macros, inclusiones y condicionales, y los comentarios no se descargan por el navegador (aumento de rendimiento menor).

El único problema importante es el uso de tags de identificación independientes (es decir, #para { ... } ) donde cpp barfs. La solución es el doble de # (a ##) y pasa la salida a través de sed, así:

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

Estoy seguro de que hay mejores preprocesadores orientados a CSS, pero esto funcionó para mí.

Comentario en HTML:

   

Comentario en JavaScript:

Comentario de una sola línea:

Dos barras, “//”, en frente del código:

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

Comentario de varias líneas:

  

Código de comentario en CSS:

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

Más detalles

Solo para agregar más información y confirmar la regla de “solo uso / * comentarios”. Un cliente que tiene acceso a la carpeta del sitio web simplemente elige por sí mismo comentar una sola línea usando esto:

 //* comment here *// 

En realidad, Chrome y Safari ignorarán CUALQUIER COSA que siga esta línea; Yo lo llamaría un “asesino de CSS”.

Para los comentarios CSS en línea , uso:

 .myDiv { @width:750px; } 

o cualquier personaje que quieras (es decir, *@!ZZ ) Entonces, la propiedad se vuelve desconocida y no es legible por css.