【问题标题】:Is it bad practice to comment out single lines of CSS with //?用 // 注释掉单行 CSS 是不好的做法吗?
【发布时间】:2012-08-31 04:52:27
【问题描述】:

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

我可以删除它,但我通常不想这样做,以防以后想把它放回去,或者如果我回来看看我一直在使用什么。

例子:

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

我可以逃脱惩罚吗?或者它可能会给我带来麻烦?

【问题讨论】:

  • 相关:stackoverflow.com/questions/11218808/…。不要在 CSS 中使用 // cmets。
  • 是的,非常糟糕......虽然我仍然使用它来表示“我会评论一下,看看会发生什么”。
  • 有人请告诉开发人员简单性更好,必须移动光标并敲击六次键盘才能快速发表评论是荒谬的。 * 需要两个。

标签: css syntax comments


【解决方案1】:

我看到有/很多人抱怨这个问题,因为这是一个较老的问题,可能有很多人在阅读它时想知道它是否仍然正确,或者最初是否有标准地方。请允许我清除空气。以下是严格的 CSS 评论政策的核心原因:

#1 不标准

至少从 CSS 2.1 开始标准化,cmets 只能封装在 /**/ 中。虽然有些浏览器可以容忍//,但它们不应该这样做,并且距离有人说“哦,是的,那是非标准的”或“嘿!那是非标准的,修复它!”只有一英寸;然后猜猜看,你的 CSS 代码,它可以工作,现在不能为成千上万的人工作(并且可能已经不能为数百人工作)。我要补充一点,<!----> 是允许的,但只有(我的意思是仅)它们出现在 HTML 文档中,而不是出现在 .css 源文件中。如果您的浏览器太旧以至于无法跳过 <style> 标签,那么可能是 10 年前换新浏览器的时候了。甚至Lynx 和其他文本浏览器都知道不阅读它们,因此将其注释掉仅在硬件和软件在其当前工作状态下处于内锁状态的非常孤立的情况下才有用。

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

// 开头的单行注释以“换行符”结尾,它是/不是跨平台标准化字符。更糟糕的是,有些可能有一个换行符或 2 个字符...当这些平台混合在一起时,可能会丢失一个换行符,并且您的终止符出现了...并且您的部分或全部代码现在被注释掉了不应该是这样,您不必是天才就能知道这可能会产生什么后果,尤其是如果您仅通过 CSS 来控制网站的功能,而许多人都这样做。

#3 标准对所有人都友好且统一

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

#4 换行符是空格

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

#5 CSS != C/C++

现在,如果您要离开座位对我大喊“嘿,但是 C++...”,请记住,这些编译器和 IDE 内置了大量换行检查和检测功能,因此它们可以接受。大多数编译器除非被询问,否则不会重新格式化您的代码,并且如果无法自行猜测,许多 IDE 通常会询问您的文档正在使用哪种换行符。如果我们每次加载时都为最终用户使用 CSS 页面,想象一下它试图绕过的噩梦。此外,C/C++ 代码在运行时不会被解析并被编译,所以很多时候,用户一开始就不会得到有问题的文档。整个世界并没有在数百个平台和许多操作系统以及一百万种不同的浏览器上不断查看源文件。 cmets 在到达最终用户之前就被剥离了。 CSS 源代码直接进入用户的浏览器,并且必须非常有弹性,不知道另一边是什么,所以需要注意的是,它必须为最终用户拥有或所做的任何事情做好准备,而不是开发人员所做或拥有的任何事情!

#6 不方便

不,必须输入额外的*/ 非常烦人,但这主要归咎于不提供自动完成功能的 CSS 编辑软件开发人员。如果您使用可以做到这一点的专业编辑器,最好是开箱即用,那么您会发现它与使用 // 一样简单。养成输入/**/ 然后退格2 的习惯,这将帮助您不要忘记并使其更容易一些。更好的是,您可以设置一个热键来为您放下这些。 Windows 和 Linux 都有强大的工具来实现这一点(KDE 非常适合)。


我希望这可以帮助大家理解“如何”背后的“为什么”,记住仅仅因为某件事对你有用,并不意味着它就是标准,总结一下:

是的,使用它是不好的做法,只需对双斜线说不!!! 如果您需要视觉辅助工具来提醒您这一重要事实,只需将这张图片刻录在您的脑海中(感谢那些除了制作这样的图片之外无事可做的人):


PS:如果你真的想向那些制定/破坏 CSS 标准(W3C、肘部)的人抱怨什么,有人会开始讨论“!important”关键字的冗长和错误!但这不是这个问题的一部分,所以我不会深入探讨。

参考文献

  • W3CCSS 2.1 工作草案:注释字符。
  • W3CCSS 语法模块级别 3:解析器到字符解释的铁路图。
  • Stack Overflow与本文主题几乎相同的各种 Stack Overflow 文章。
  • w3schoolsCSS 3 语法标准(反过来引用 W3C)。
  • sitepoint关于“不使用双斜杠”的 CSS 语法注释。
  • mozilla|mdn宽松的 CSS 3 处理允许在输入文件中使用双斜杠。

【讨论】:

  • 为什么您的参考文献中没有任何链接?
  • 你没有因为发布那个没有双斜线的插图而得到更多的代表,这绝对是犯罪。
【解决方案2】:

我不知道未来和/或异国情调的浏览器将如何解释像 // 这样的非官方黑客,所以我宁愿坚持使用适当的符号:

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

【讨论】:

  • @AdamMilward - 你可以阅读revision control at Wikipedia。你肯定想用一些东西来管理你的所有类型的代码。 CVS 是祖父(以 RCS 为祖先),其次是 SVN,然后是一大批(相对)新人,如 Mercurial、Perforce、Bazaar 等。如果你刚开始接触,我推荐 git .这些天所有酷孩子都在使用它。 :-)
  • 注释掉的代码是代码异味?一般来说,我觉得这个说法太苛刻了。它通常用于文档目的,用于显示伪代码,或者一般来说,它可以帮助未来的人查看代码文件。
  • @Jan-PhilipGehrcke:是的,甚至只是在修订之间。即使我使用 git,我也不会每次编辑一行时都提交,所以每次提交时我都会多次测试更改是否符合预期,方法是注释掉特定的行并查看会发生什么.我的提交对应于经过测试和工作的离散更改(修复一个小错误;重构/整理旨在具有相同的功能/正确性;等等)(除非在过渡的情况下提交消息中另有说明)提交必须被破坏才能离散,但破坏是已知的)。
  • @Jan-PhilipGehrcke:换句话说,我的提交策略旨在使历史更清晰,以便将来更容易研究和追踪回归,而不是作为评论的替代品-当前输出代码在提交之间。所以我同意注释掉代码并不总是一种气味。
  • 嗯,这太狭隘了,太严厉了,固执己见。注释掉的代码可能对最终产品没有好处,我不会将代码放入带有注释代码的门中,但对于原型设计和实验来说就很好了,单行 cmets 比 /* * 更方便地进行 CSS 实验/
【解决方案3】:

我最近阅读了this article,它为 CSS 中的单行注释实践提供了很多启示。

CSS 允许你使用// 后一种时尚。它不完全是行注释,而是下一个构造注释。也就是说,每当您使用 // 时,下一个 CSS 构造 - 无论是声明还是块 - 都会被“注释掉”。

所以在您的代码中,sn-p list-style-type:none 是下一个 CSS 构造,它会被注释掉。

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

同样,在下面的代码sn-p中

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

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

如果您尝试使用 // 仅将 cmets 写入样式表,则必须小心 - 原始文本不是 CSS 构造,因此它会跳过它并注释掉页面中的下一个构造.所以在下面的sn-p

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

这将注释掉.foo 块。

您可以通过开头提到的链接文章获取更多信息。

【讨论】:

  • 那篇文章是在开玩笑......你跳过这部分了吗? “精明的人会注意到(或已经知道)像这样使用 // 并没有真正“注释掉”任何东西。相反,它只是将无效值放入样式表并依赖 CSS 的错误恢复规则杀死页面上的下一个构造,然后优雅地恢复。因为 CSS 的错误恢复是明确定义的,所以您可以依靠每个正确实现它的浏览器以预期的方式工作。”
【解决方案4】:

According to the Working Draft,没有什么比单行注释更好的了。

【讨论】:

  • 你是对的,但没有什么比 // 更适合使用 cmets。
【解决方案5】:

我一直使用// 来“注释掉”.css 文件中的行。因为它绑定到Vim 中的快捷方式,我总是忘记我在编辑什么。在 JavaScript 中,注释掉代码块、测试代码并再次“注释”代码块非常方便(快捷方式,是的)。

但是当我整理我的 .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 中,我只是用不同的值重新声明了相同的属性。

这很痛苦。

!important

【讨论】:

    【解决方案6】:

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

    对于初学者,如果您在团队环境中工作,那么代码的可维护性/可读性至关重要,即使您独自工作,编写可维护的代码仍然是一种好习惯,否则就会出现精神错乱。

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

    此外,单行和多行 cmets 不能完全互换,例如,您不能在不使用 hack 的情况下使用原始文本 cmets,而只能注释掉构造 //.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;
    }
    

    现在可以互换(由于构造函数为空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;
    }
    

    虽然使用构造函数 {}; 作为后缀会起作用,但 IMO 会破坏使用它的目的,因为您将使用 更多 个字符;多行注释使用四个字符 /**/,而带有 hack 的单行注释使用五个字符 //{};

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

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

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

    IMO 单行 cmets 的一个很好的用例是当您需要注释掉整个构造函数时,这真的很长(示例不会)。

    注释掉整个构造函数

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

    最后,如果您在开发过程中尝试调试某些东西,我认为用单行 cmets 注释掉构造函数以清除错误并没有什么害处。如果您正在调试,那么它将是暂时的。也就是说,我没有看到任何原始文本的用例,所以我绝对不会提倡在那里使用它们。

    【讨论】:

      【解决方案7】:

      我建议不要在不需要时将这样的 CSS 注释掉。删除您不需要的东西并将其提交到您的 SVN 或 GIT 存储库。让它完成它的工作并为您记录历史。像这样累积的 cmets 变得很笨拙,使您的代码更难阅读和理解。

      【讨论】:

        【解决方案8】:

        正如其他人所说,使用双斜杠不符合标准,但如果您真的想要使用它并且想要符合标准并且您安装了 gcc,您可以通过以下方式运行您的 CSS cpp -P 从 CSS 中删除所有双斜杠和 /* ... */ cmets。作为奖励,您可以使用宏、包含和条件,并且浏览器不会下载 cmets(性能提升很小)。

        唯一的主要问题是在 cpp barfs.解决方案有双#(到##)并通过sed传递输出,如下所示:

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

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

        【讨论】:

          【解决方案9】:

          对于内联 CSS cmets,我使用:

          .myDiv {
              @width:750px;  
          }
          

          或您想要的任何字符(即*@!ZZ) 因此,属性变得未知且 css 无法读取。

          【讨论】:

            【解决方案10】:

            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; }
            
            */
            

            More details

            【讨论】:

              【解决方案11】:

              只是添加一些进一步的信息并确认“仅使用 /* cmets”规则。有权访问网站文件夹的客户只需自行选择使用以下命令注释掉一行:

              //*  comment here   *//
              

              实际上ChromeSafari 将忽略此行之后的任何内容;我会称它为“CSS 杀手”。

              【讨论】:

              • 嗯,我会改为将其称为语法错误,导致 css 解析器忽略有问题的块...
              猜你喜欢
              • 2011-04-09
              • 1970-01-01
              • 2019-02-12
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2019-11-08
              • 1970-01-01
              • 2021-09-01
              相关资源
              最近更新 更多