根本没有。

我一直使用下划线，因为连字符会打乱我的文本编辑器(Gedit)的语法高亮显示，但这只是个人喜好。

我在很多地方都看到过这些惯例。使用你认为最好的——看起来最好的/对你来说最容易阅读的，以及最容易打字的，因为你会经常使用它。例如，如果你的下划线键在键盘的下方(不太可能，但完全有可能)，那么坚持使用连字符。选择对你自己最好的。此外，所有这3个约定都很容易阅读。如果您在团队中工作，请记住遵守团队指定的约定(如果有的话)。

更新2012

随着时间的推移，我改变了我的编程方式。我现在使用驼色大小写(thisIsASelector)而不是连字符;我觉得后者相当难看。使用任何你喜欢的，这可能很容易随时间改变。

更新2013

看起来我每年都喜欢把事情弄混……在切换到Sublime Text并使用Bootstrap一段时间后，我又回到了破折号。对我来说，现在它们看起来比un_der_scores或camelCase干净得多。我最初的观点仍然有效:不是是标准。

更新2015

这里有一个有趣的惯例极端情况是生锈。我真的很喜欢这个语言，但是如果你用underscore_case以外的任何东西定义东西，编译器会警告你。您可以关闭警告，但有趣的是，编译器在默认情况下强烈建议使用约定。我想在大型项目中，它会带来更简洁的代码，这并不是坏事。

更新2016 (你请求它)

我已经为我未来的项目采用了本标准。类名最终相当冗长，但我认为它为类和与之配套的CSS提供了良好的结构和可重用性。我认为BEM 实际上是是一个标准(所以我的no可能成为yes)，但它仍然取决于你决定在一个项目中使用什么。最重要的是:坚持你的选择。

更新2019 (你请求它)

在很长一段时间没有写CSS之后，我开始在一个在他们的产品中使用允许的地方工作。我个人觉得到处乱扔类是很不愉快的，但是不必总是在HTML和CSS之间切换，感觉相当高效。

不过，我还是决定使用边界m。它很冗长，但是名称空间使得在React组件中使用它非常自然。它还非常适合在浏览器测试时选择特定的元素。

OOCSS和BEM只是其中的一些CSS标准。选择一个适合你的-他们都充满了妥协，因为CSS 就是没那么好。

更新2020

今年的更新很无聊。我还在用边界元法。由于上述原因，我的立场自2019年更新以来并没有真正改变。根据你的团队规模使用适合你的东西，尽可能多或少地隐藏CSS的糟糕特性。

我最近才开始学习XML。下划线版本帮助我将所有与xml相关的内容(DOM、XSD等)与Java、JavaScript(驼色大小写)等编程语言分开。我同意你的观点，使用编程语言中允许的标识符看起来更好。

编辑:可能不相关，但这里有一个关于命名XML元素的规则和建议的链接，我在命名id时遵循这些规则和建议(“XML命名规则”和“最佳命名实践”部分)。

http://www.w3schools.com/xml/xml_elements.asp

HTML和CSS没有统一的命名规范。但是你可以围绕对象设计来构造你的命名法。更具体地说，我称之为所有权和关系。

所有权

描述对象的关键字可以用连字符分隔。

car-new-turned-right

car -一个名词，一个对象
New -一个形容词，一个更详细地描述对象的对象描述符
Turned -一个动词，一个属于对象
的动作 右-形容词，动作描述符，更详细地描述动作

注意:动词(动作)应该用过去时(turn, did, ran等)。

的关系

对象也可以具有父对象和子对象的关系。Action和Action- descriptor属于父对象，不属于子对象。对于对象之间的关系，可以使用下划线。

car-new-turned-right_wheel-left-turned-left

• 新车右转(遵循所有权规则)
• 车轮左转左(遵循所有权规则)
• car-new- turning -right_wheel-left-turn -left(遵循关系规则)

最后指出:

• 因为CSS是不区分大小写的，所以最好用小写(或大写)来写所有的名称;避免骆驼式或帕斯卡式，因为它们会导致名字模糊。
• 知道什么时候使用类，什么时候使用id。这不仅仅是一个id在网页上被使用一次。大多数情况下，您希望使用类而不是id。Web组件(按钮、表单、面板等)应该总是使用类。Id很容易导致命名冲突，在标记的命名空间中应该谨慎使用。上面的所有权和关系概念适用于类和id的命名，并将帮助您避免命名冲突。
• 如果您不喜欢我的CSS命名约定，还有其他一些命名约定:结构命名约定、表示命名约定、语义命名约定、BEM命名约定、OCSS命名约定等。

tl,博士;2022

似乎"-"将成为行业标准。

#弃用

我建议你用下划线代替连字符(-)，因为…

<form name="myForm">
<input name="myInput" id="my-Id" value="myValue"/>
</form>


<script>
var x = document.myForm.my-Id.value;
alert(x);
</script>

你可以通过id很容易地访问这个值。但如果使用连字符，则会导致语法错误。

这是一个旧的示例，但它可以没有jquery工作-:)

多亏了@jean_ralphio，才有了绕开的方法

var x = document.myForm['my-Id'].value;

dash style将是谷歌代码风格，但我真的不喜欢它。 我更喜欢TitleCase作为id, camelCase作为类

没有一个正确的答案。您可以从众多标准中挑选一个，也可以根据与您合作的对象创建自己的标准。它100%依赖于平台。

原始帖子

还有一个可供考虑的标准:

<div id="id_name" class="class-name"></div>

在你的剧本里:

var variableName = $("#id_name .class-name");

这只是对变量、id和类分别使用了驼峰式大小写、下划线和连字符。我在几个不同的网站上读到过这个标准。虽然在css/jquery的选择器中有一点冗余，但冗余使它更容易捕获错误。如果你在你的CSS文件中看到.unknown_name或#unknownName，你知道你需要弄清楚它们实际上指的是什么。

UPDATE 2019

(连字符被称为'kebab-case'，下划线被称为'snake_case'，然后你有'Title Case'， 'PascalCase'和'camelCase')

我个人不喜欢连字符。我最初发布这是作为一个替代方案(因为规则很简单)。然而，连字符使得选择快捷方式非常困难(双击，ctrl/选项 + 左/正确的，和ctrl/cmd+D在vsCode。此外，类名和文件名是唯一使用连字符的地方，因为它们几乎总是在引号中或css中，等等。但是捷径仍然适用。

除了变量、类名和id，还需要注意文件名约定。还有Git分支。

我办公室的编码小组实际上在一两个月前开过一次会，讨论我们将如何命名事物。对于git分支，我们无法决定是321-the_issue_description还是321-the -issue-description。(我想要321_theIssueDescription，但我的同事不喜欢。)

举个例子，说明在别人的标准下工作……

Vue.js确实有一个标准。实际上，他们的一些项目有两个备选标准。我不喜欢这两个版本的文件名。他们推荐"/path/kebab-case.vue"或"/path/PascalCase.Vue"。前者更难重命名，除非您特别试图重命名它的一部分。后者不利于跨平台兼容性。我更喜欢"/path/snake_case.vue"。然而，当与他人或现有项目一起工作时，遵循已经制定的标准是很重要的。因此，我在Vue中使用烤串格式的文件名，尽管我会完全抱怨它。因为不这么做就意味着要修改vue-cli设置的很多文件。

UPDATE 2021

在我生命中的这一点上，我尝试专门使用kebab-case作为项目文件名。

还有一个奇怪的snake_case.kebab-case.dot.case.Title.Case组合，用于人类通信的文件。例如，包含报告的excel文件可能是"Report_Name-Report_Type-2021.05.04_13.02"，用于5月4日下午1:02生成的报告。我实际上是要使用Title Case在说的报告名称，但如果你重新保存文件，你将没有空格。我打算用烤肉盒，让日期戳符合iso标准，但客户感到困惑，因为他们使用美国月-日-年格式的日期。另一个例子是"SomeRequestForm-ProjectName-01.pdf"。

客户端可读的东西很难解决。

我尽量避免使用空格(而且客户端不会要求使用空格)，因为它们不是cli安全的。我在项目中采用了Angular的文件名方法。some-thing.type.ts，其中描述为kebab-case，文件中存储的标准对象类型用点分隔，如扩展名。我通常不做some-area_some-thing.type.ts，除非文件是独立的和可移植的。如果它在一个项目中，那么我只使用some-area/some-thing.type.ts这样的文件夹

此外，我使用kebab-case为css类，我有时混合snakeAndCamel_case为html id，但通常我不再使用html id，因为我使用可重用的组件，这就坏了。当我使用id时，它通常是类似someComponent-someElement_49bea6c9-551b-400a-a3e0-59ed40967646的东西，其中uuid是由每个组件实例自分配的生成的uuid。这在Angular中是不支持的，所以我倾向于想出其他的解决办法，比如把整个表单输入保存在标签中。

此外，对于变量名，除了类名和函数名之外，我仍然主要使用驼峰式大小写。当使用外部包时，我只是做他们正在做的事情。对于模拟环境变量的东西，我确实使用ALL_CAPS_SNAKE_CASE，这包括node.js的process.env.SOME_ENV_VAR和combinedConfiguration.SOME_ENV_VAR(用于当我重写进程时。带参数配置的Env)

我的tl,博士;几年后仍然适用。没有一个正确的答案。但是尽量保持每个项目一种风格。尽可能减少符号中的字数。

许多人喜欢在CSS id和类名中使用连字符的另一个原因是功能。

使用键盘快捷键，如选项 +左/正确的(或Windows上的ctrl+左/正确的)逐字遍历代码，将光标停在每个破折号上，允许您使用键盘快捷键精确遍历id或类名。下划线和驼峰字不会被检测到，光标会在它们上面漂移，就好像它们都是一个单词一样。

我认为这取决于平台。当在。net MVC中开发时，我使用引导风格的小写字母和连字符作为类名，但是对于id我使用PascalCase。

这样做的原因是我的视图是由强类型视图模型支持的。c#模型的属性是pascal case。为了与MVC绑定模型，绑定到模型的HTML元素的名称与视图模型属性保持一致是有意义的，视图模型属性是pascal case。为了简单起见，我的id使用与元素名称相同的命名约定，除了单选按钮和复选框，它们需要为命名输入组中的每个元素提供唯一的id。