用//注释掉单行CSS是不是很糟糕的做法?

我最近开始使用//来“注释”出单行的CSS代码。 我知道我实际上并没有对此作出评论, 我只是打破它(我应该使用/* ... */ ),但它具有相同的效果。 该行然后被终止; 和下面的代码工作正常。

我可以删除它,但是我经常不想在以后再使用它,或者如果我回来看看我一直在使用什么。

例:

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

我可以逃避这个,还是可能导致我的问题?

首要的是:注释掉的代码是一种代码味道 ,应该避免。 我假设你正在使用像Git这样的VCS,它为你处理历史代码。

但如果你真的想这样工作:你不知道未来和/或异国情调的浏览器将如何解释非官方的黑客攻击,所以你最好坚持使用适当的符号:

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

我看到有很多人抱怨这个,因为这是一个老问题,可能有很多人在阅读它,想知道它是否仍然是真实的,或者实际上是否有一个标准。 让我清空空气。 以下是严格的CSS评论政策的核心原因:

#1这不是标准的

至less从css 2.1开始规范化,注释只能包含在/**/ 。 虽然有些浏览器容忍// ,但是他们不应该这么做,而且只有一个人说:“哦,是非标准的”或者“嘿!这是非标准的,修复它! 然后猜猜你的css代码,哪个工作,现在不适合成千上万的人使用(可能已经有数百人不能工作了)。 我将添加<!---->是允许的,但只有(而且我的意思是只)当它们出现在HTML文档中,而不是在.css源文件中。 如果您的浏览器太旧,以至于无法跳过<style>标签,那么10年前它可能就是新浏览器的时候了。 即使l and和其他文本浏览器也不知道读取它们,所以只有在硬件和软件处于当前工作状态的情况下,才能对其进行评论。

#2它不是(非常)跨平台友好的

单行注释,从//开始的任何位置开始,由'换行符'结束,它不是一个跨平台的标准化字符。 更糟糕的是,有些人可能有一个字符换行,或者2 …当这些平台混合在一起,一个换行符可能会丢失,并有终止符…你的一些或全部代码现在被注释掉不应该是,你不必成为一个天才,知道可能会有什么后果,特别是如果你只是通过许多CSS的CSS来控制你的网站的function。

标准对所有人友好而统一

无论架构,操作系统如何, /**/分隔符总是在每台计算机上都是相同的字符。

#4换行是空白

最后一个原因(是的,还有一个),换行符被认为是(在CSS和许多其他语言)是空格, */不是空白吗? 如果你在这一点上考虑一下,应该很清楚你不应该使用空格来终止注释,特别是因为空格是被许多HTML / CSSparsing器剥离的,或者甚至在你不知道它的情况下重新格式化。

#5 CSS!= C / C ++

现在,如果你要飞出座位,对我说“嘿,但C ++ ….”,请记住,这些编译器和IDE有大量的换行检查和检测内置在它们,所以他们可以把它。 大多数编译器不会重新格式化您的代码,除非被问及,否则许多IDE通常会问您,如果文档不能自行猜测,您的文档使用的是哪种新行。 如果我们每次加载最终用户的CSS页面时都这样做,想象一下它将试图解决的噩梦。 而且,C / C ++代码在运行时不会被parsing,而是经过编译,所以很多时候,用户从来不会首先获得有问题的文档。 全世界的数百个平台和许多操作系统以及数百万种不同的浏览器都不会经常查看源文件。 评论在他们到​​达最终用户之前被剥离。 CSS源码直接来自用户的浏览器,并且必须非常灵活,而不必知道对方是什么,所以需要注意的是,它必须为最终用户所拥有或所做的任何事情做好准备,而不是开发人员所做的任何事情!

#6这是不方便的

不,这是非常烦人的,不得不input这个额外的*/ ,但这主要是由于CSS编辑软件的开发人员不提供自动完成。 如果你使用专门的编辑器,可以做到这一点,最好是开箱即用,那么你会发现它就像使用//一样简单。 习惯于input/**/然后退格键2,它会帮助你不忘记,并使其更容易一些。 更好的是,你可以设置一个热键来为你放下这些。 Windows和Linux都有强大的工具来允许这个(KDE非常好)。


我希望这可以帮助大家理解“怎么”背后的“为什么”,记住只是因为某些东西适合你,并不意味着它是标准的,总而言之:

是的,它使用它是不好的做法,只是不说双斜杠! 如果你需要一个视觉辅助来提醒你这个重要的事实,那就把这个图像烧到你的脑海里(感谢那些没有更好的事情做的人,而是像这样做):

没有双斜线


PS:如果你真的想抱怨一些制作/破解CSS标准(W3C,肘部)的人,那么就开始讨论“!important”这个关键字是多么长和错的问题! 但这不是这个问题的一部分,所以我不会去讨论这个问题。

参考

  • W3CCSS 2.1工作草案:评论字符。
  • W3CCSS语法模块级别3:parsing器到字符解释的铁路图。
  • 所以与这个几乎相同的主题的各种SO文章。
  • w3schoolsCSS 3语法标准(依次引用w3c)。
  • sitepoint“不使用双斜线”的CSS语法注释。
  • mozilla | mdn放松css3处理允许在input文件中双斜杠。

我最近读了这篇文章 ,对CSS中的单行注释练习提供了很多帮助。

CSS允许你在时尚之后使用// 这不是一个线条评论,而是下一个构build评论 。 也就是说,无论何时使用// ,下一个CSS构造(声明或块)都将被“注释掉”。

所以在你的代码片段list-style-type:none是下一个CSS构造,它被注释掉。

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

同样,在下面的代码片段

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

//将注释掉第一个@keyframes声明。

如果你尝试使用/ /只是写你的样式表注释,你必须小心 – 原始文本不是一个CSS构造,所以它会看看过去,并注释掉你的页面中的下一个构造。 所以在下面的片段

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

这将注释掉.foo块。

您可以通过一开始提到的链接文章获得更多信息。

根据工作草案 ,没有什么比单行的评论。

是的,我认为在目前的状态下使用单行注释是不好的做法。

对于初学者来说,如果你在团队环境中工作,那么代码的可维护性/可读性是非常重要的,即使你单独工作,编写可维护的代码仍然是一个好习惯,否则精神病将随之而来。

当您开始使用单行注释时,可维护性和可读性都受到阻碍,编辑器中的语法轮廓颜色亮点不会突出显示您的评论,并且很难区分评论和规则。

比较单行和多行的评论

此外,单行和多行的注释并不是可以互换的,比如你不能使用原文注释而不使用破解,而只能注释掉结构//.foo {...}或者规则.foo {//height:10px}

不可互换的实例:

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

现在可以互换(由于空的构造函数黑客 ):

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

使用构造函数{}; 作为一个后缀将工作,这是国际海事组织击败使用它的目的,因为你会使用更多的字符; 多行注释使用四个字符/**/ ,而带有黑客的单行注释使用五个字符, //{};

最后一个尚未提及的单行注释的警告是, Chrome开发人员工具将隐藏注释掉的规则,而不是允许您切换它们。

Chrome开发者工具(多行注释):

在这里输入图像说明

Chrome开发者工具(单行注释):

在这里输入图像说明

对于单行注释来说,一个很好的用例IMO就是当你需要注释掉一个很长的构造函数的时候(这个例子不会)。

注释掉整个构造函数

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

最后,如果您在开发过程中尝试debugging某些东西,我不认为使用单行注释来注释构造函数会带来一些坏处。 如果你正在debugging,那么这将是暂时的。 这就是说,我没有看到任何用于原始文本的用例,所以我绝对不会主张在那里使用它们。

当不需要的时候,我会build议不要这样评论CSS。 删除不需要的东西,并将其提交到SVN或GIT存储库。 让它做好工作,跟踪历史。 像这样的累积评论变得粗俗,使你的代码难以阅读和理解。

我使用//在.css文件中始终“注释”行。 因为它在Vim中绑定了一个快捷键,我总是忘记了我正在编辑的东西。 在JavaScript中,注释掉代码块,testing代码,并再次“注释”代码块(快捷方式,是的)非常方便。

但是,当我整理我的.css文件,我使用以下结构更容易移动声明进出范围:

 .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; } 

.pin我可以删除一行并将其添加到注释区域,反之亦然。 在.shadow我只是用不同的值重新声明同一个属性。

这是一个痛苦。

!重要

正如其他人所说,使用双斜杠不符合标准,但如果你真的想使用它,并希望符合标准,你已经安装了海湾合作委员会,你可以运行你的CSS通过cpp -P所有双斜线和/ * … * /来自CSS的评论。 作为奖励,您可以使用macros,包含和条件,并且评论不会​​被浏览器下载(次要的性能提升)。

唯一的主要问题是使用独立的id标签(即#para { ... } )其中cpp barfs。 解决scheme有两个#(到##)并通过sed传递输出,如下所示:

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

我相信有更好的面向CSS的预处理器,但是这对我有用。

在HTML中评论:

 <!--........................--> <!-- <input type="text" name="lastname">--> 

JavaScript中的评论:

单行评论:

代码前面有两个“//”,

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

多行评论:

 <script type="text/javascript"> <!-- /* document.write("try this!"); document.write("try this"); */ //--> </script> 

在CSS中注释代码:

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

更多细节

只是添加一些进一步的信息,并确认“只使用/ *评论”规则。 有权访问网站文件夹的客户只需自行select使用以下内容注释一行:

 //* comment here *// 

实际上, Chrome和Safari会忽略这一行后面的任何内容; 我会称之为“CSS杀手”。

对于内联CSS评论 ,我使用:

 .myDiv { @width:750px; } 

或任何你想要的字符(即*@!ZZ )所以,财产变得未知和不可读的CSS。