在 Smashing Magazine 最近的一篇 问答文章 中，有人问到如何判断开发者是否写出了糟糕的 CSS。具体来说
哪些迹象表明 CSS 并非最佳，或者开发者没有做好？在 CSS 中，你观察什么来判断它的好坏？
我认为这是一个有趣的问题，我想对我的答案进行一些扩展。
为什么？
也许你雇了人来为你编写 CSS，并且想评估他们的工作质量。也许你正在查看某个你可能要雇佣的人的 CSS 代码。也许你想以某种方式评估你自己的 CSS。
显而易见的测试
查看网站。如果看起来乱七八糟，那么他们的工作就做得不好。
更进一步，根据你同意支持的浏览器进行检查。设计应该在所有浏览器中都能正常工作。
如果设计应该具有响应式，请调整浏览器窗口大小，以确保设计无论宽度或高度如何都能正常工作。
如果一切看起来都很好，那是一个好的（也是必需的）第一步。但这并不能绝对证明 CSS 很好。
格式化测试
浏览编写的 CSS 文件。请记住，最佳实践是提供已压缩的 CSS 文件（所有不重要的空格都已删除），因此不要查看该文件。
如果你有一个已建立的样式指南，并且期望遵循它，那么它是否被遵循了？
如果没有，它看起来是否一致——就像他们有自己的样式指南并坚持遵循一样？还是有点随意？随意是指有时选择器后面有一个空格，有时没有。一些代码块缩进了，而另一些则没有。单行 CSS 与多行 CSS 混杂在一起，毫无章法。
整洁的代码是尊重开发者的标志。一个尊重手艺和他们所做工作的人。
如果这两个测试都通过了，那很好。但仍然不能完全证明 CSS 很好。
选择器测试
前两个测试几乎任何人都可以完成，但从这里开始，你需要自己熟悉 CSS。开始阅读 CSS，看看你看到的内容是否有意义。
选择器看起来是否合理？如果你看到一个像这样的选择器
.article #comments ul > li > a.button {
/* Crazy town */
}我会担心。那是一个开发者在与自身特异性问题作斗争，好的 CSS 不会这样做。
类名怎么样？易于理解吗？希望你不会发现任何像“bigGray”或“left50”这样的东西，因为它们的准确性肯定会短暂，导致未来的开发变得混乱。
重复程度如何？例如，如果你看到完全相同的 box-shadow 在 20 个不同的地方应用，这可能表明缺乏重构。优秀的 CSS 开发者会感知到这样的模式，并更好地适应它们。
大小测试
已部署的 CSS 文件大小如何？对于 CSS 文件来说，100k 绝对是巨大的。小巧是好的。即使（尤其是在）复杂的网站上。巨大的文件通常是缺乏一致性的标志。
编辑测试
想出一个你想要更改网站上样式的方案，并尝试自己进行更改。例如，将所有使用的字体替换为其他字体。你能够快速熟悉代码吗？感觉是否有关于字体处理的计划？你能够多快完成？比你通常处理这类事情的速度快还是慢？
你是如何做到的？
你是否曾经处于需要评判他人 CSS 的位置？你是否使用了类似的测试？你是否有更明确的指标？
在文件中搜索“!important”。
参见
http://oli.jp/img/2011/important-inheritance.png
:)
我完全同意任何使用“!important”都是令人痛苦的，但确实有一些情况下它是有道理的。当实现一个 jQuery 插件，它会向特定元素添加自己的内联 css，并且出于某种原因需要覆盖这些样式时，我偶尔会使用它。我看到的另一种情况（有点不那么合理）是在合并来自多个开发人员的样式表时不小心留下了一个，这些开发人员在同一个开发服务器上工作，并且被迫相互覆盖。
如果你曾经尝试过在 MS SharePoint 上进行样式设置，你很快就会习惯于使用 !important。
我特别关注的另一件事与样板代码有关。
使用 html5 样板代码在开发中变得相当流行，我总是会看看：他们是否只是将他们手工制作的 CSS 放入样板代码的 css 文件中并忽略了其中的内容？或者（你希望的）他们是否真的查看了样板代码并删除了他们项目可能不需要的内容。看到空的媒体查询语句让我感到难过。
同样，如果他们的 CSS 中有一组打印样式，请打印预览页面并检查它打印时是否真的看起来不错（默认的 html5bp 并非对每个项目都适用）。
我认为这是一个评估 CSS 质量的很好的入门清单。我认为另一个大问题是重复的样式声明（它们相互冲突）以及没有注释的 CSS。
不过，关于选择器…你说“那是一个开发者在与自身特异性问题作斗争，好的 CSS 不会这样做。”我同意，但我们并不总是使用我们自己编写的完美 HTML。因此，我们经常需要更改现有应用程序、工具、附加组件、插件等的样式。非常特定的选择器可能是 CSS 编码人员知道如何在不添加脚本和修改 HTML 的情况下解决工具限制的标志。它也可能是 CSS 编码人员没有过度使用 HTML 中的类和 ID，而是利用语义 HTML 来定位项目的标志。
完全同意。此外，时间也是一个巨大的因素。对于我的个人代码，我比在工作中严格得多，仅仅是因为客户通常不关心代码是否写得好。他们宁愿使用尽可能快且混乱的代码，只要我们能够在创纪录的时间内交付即可。而且他们根本不在乎以后是否容易更新。
只是好奇…如果你/当你在压缩 CSS 时，是否会删除注释？我从不注释我的 CSS，因为要压缩文件。
压缩工具可以删除注释，以下是一个示例：http://www.cssdrive.com/index.php/main/csscompressor
无论如何，我都会为我的 CSS 添加注释。有时甚至会注释到声明级别，以便客户知道这个确切的属性是设置他们的背景等。这取决于项目。我还在使用一个开箱即用就包含近 50 个 CSS 文件的产品，所以为我必须添加在顶部的 CSS 文件添加注释至关重要。
除了您已经列出的内容之外，一致性是我在代码中寻找的主要内容之一。如果某人保持一致，那么他们很可能知道自己在做什么。
我首先寻找的一件事是过于冗长的代码。例如
而不是更简洁的
或
而不是
最后，另一个重要的一点是，如果可能，他们是否使用简短的十六进制颜色，例如 #FFF 而不是 #FFFFFF。
最后，一个非常有趣的事情是，几年前我曾为一家以 Research in Motion 为客户的代理机构工作。当时他们的主要样式表有 700kb 大，我们必须在处理的任何页面上包含它，并确保我们的 CSS 不与它发生冲突。
我同意过于冗长的代码不好……但是，如果您要覆盖无法控制的现有冗长 CSS，则需要坚持使用冗长的方法。这只是对发表在本文中的新用户（看到他们发表评论真是太好了）的澄清。“Background-url”比简写“background”具有更高的权重。
@ Heather（以及更重要的是阅读她评论的人）
按照这种逻辑：div{background-color: #FF0000;background: #FFFFFF;} 将显示红色背景。但除了在某些情况下发现的一些奇怪的错误之外，这个 div 绝对是白色的（幸运的是，因为红色背景很难看）
@ Ryan
您首先写
background:url(‘background.jpg’) 10px 10px no-repeat #FFF;
然后你说你不喜欢人们写简短的十六进制代码。有趣，不是吗？
我个人更喜欢编写简写代码，但有人编写 margin-top 等并不是什么大问题。有些事情比实际的良好或不良编码实践更个人化。
@Ryan
background-url**不存在**。我希望您的意思是写background-image: url("background.png");。我一直输入完整的十六进制颜色，因为我有强迫症。我使用的大多数颜色都无法缩短，我喜欢统一性，所以 #FFFFFF 看起来更好，对我来说更有意义。但这只是我的个人偏好；)
我不确定是否同意始终使用简写声明的说法。首先，这会降低可读性。此外，这与网站无关，但大多数电子邮件客户端会忽略简写，并要求您使用完整的声明。
我认为您不能根据某人使用简写编码技术来判断他们编写 CSS 的能力。这就像说说俚语比说完整的英语更好。并非如此。这只是个人喜好。它只会节省文件大小的一小部分 KB。我认为，如果您需要担心完整声明使 CSS 文件的大小膨胀，那么您可能会有更大的问题需要担心。
好吧，简写确实有其方便的一面，例如：能够将其放在一个声明中（从而使用更少的字节并对 CSS 的整体包含方面感到满意），当然，意见可能会有所不同，但我认为首先这就是我们拥有简写 CSS 的原因。除此之外，如果您有一个包含 CSS 规则（作为基础），您仍然可以在以后更精确地仅更改 CSS 行的某些方面。（例如，如果您使用简写背景属性，您可以在以后指定另一种颜色、另一张背景图片、另一个位置等，同时保留项目早期建立的基础）。再说一遍，这也是个人偏好的问题。这一切都取决于您在特定项目中使用的策略。
我首先寻找的一件事：忘记继承，或避免它。
有些人忘记了，并且在类中声明了数千次相同的属性。
然后，我看到属性的重复是荒谬和不必要的。这也与前面提到的滥用 !important 有关。
个人项目
您可以花大量时间制作超级整洁的 CSS
代理机构、客户端网络
1.) 时间至关重要，它有效，好的，截止日期已到
2.) 您需要使用无法更改的糟糕 CSS，这也很有趣
3.) 其他情况或上述情况的组合
因此，在客户端工作中看到糟糕的 CSS 并不总是意味着 CSS 开发人员不好（只是别无选择）
这总结了很多内容。不幸的是，有时无法用细齿梳子检查代码或花时间考虑所有内容。
是的，这里几乎每天都会发生。在我的个人项目中，我尝试保持 CSS 文件的整洁和组织（至少在我的新项目中哈哈），但在工作中，我很少能负担得起这种奢侈。我一直在处理由很多人管理的 CSS 文件，祝你好运保持组织，世界上所有的注释都无法拯救它……
同意 #2。我做过很多客户工作，在之前的开发者被解雇后或只是被聘用来进行特定定制后，我接手了这些工作。在这种情况下，我尽力修改代码并使其尽可能简洁。大多数情况下，对于自由职业工作，您不会被雇用来清理 CSS 或 HTML，并且很难证明我花费自己的空闲时间清理代码是合理的，除非代码真的非常糟糕并且影响了我正在尝试做的事情。
但是，对于 #1，我认为这并不总是尽快完成。如果我想留住客户，我需要确保我的 CSS 能够扩展到未来的项目。我编写了一些糟糕的代码，然后第二年客户雇用我更新项目，我就像“谁写了这些垃圾！”直到我意识到是我自己写的。
Chris 对 CSS 管理的深刻见解。我始终确保在将站点部署到其实时状态之前压缩样式表。
“单行 CSS 与多行 CSS 混杂在一起，毫无章法。”
有时我编写的代码看起来像这样，但实际上并非如此。如果我只有一个属性，那么整个内容很可能都与选择器位于同一行。这并不是世界上最一致的事情，但它有效，并且不会影响可读性。
就是这样。如果只有几个属性，我经常使用单行，但如果属性很多，则切换到多行，因为如果单行开始换行到下一行，就会变得很乱。
只要您以明显且一致的方式在这些样式之间交替，那就完全没问题。我也这样做。
我也在使用这个
如果只有一个属性，使用单行
如果更多，则使其在行上可读
.lorem {color: red;} .ipsum { color: blue; height: 50px; line-height: 50px; }感谢这篇文章，它对像我这样刚接触 CSS 编码的人来说非常有用（评论也很有用）！
谁能推荐一篇关于组织 CSS 的有用方法的文章（例如，是否将所有类组合在一起，以及是否根据颜色/排版等进行划分）。我正在努力使我的 CSS 组织良好！
谢谢
Nicolas Gallagher 的 Idomatic CSS
github.com/necolas/idiomatic-css
尽管您可以找到有关组织的技巧，但我建议您尝试开发自己的方法。两者都可以很好地工作，或者可以结合在一起。我个人不喜欢颜色/排版类型的分组，但这仅仅是因为它不是我思考的方式，而不是它本身是错误的。
像所有代码一样，将其组织成易于查找和理解的方式，并希望让下一个人也能做到这一点更为重要，除非您为一家足够大的公司工作，并表示“效率无关紧要，每个人都一直都在这样做。”
嵌入字体和图像变得越来越普遍，以减少页面加载时的 HTTP 请求。它们大大增加了样式表的大小，并误导性地让人觉得开发人员不一致或缺乏经验。因此，在根据 CSS 文件的大小进行判断时请记住这一点。（是的，是的，它们应该可能被移植到不同的文件中；这真的都取决于情况。）
同意你的观点。设计师在遵循规则方面应该保持一致性。
评判 CSS 通常从查看生产文件开始。是否有明确的章节来帮助其他参与项目的开发者理解你的代码。
例如，我通常会以一个**关键信息**开头，然后用标题定义以下部分
关键信息的想法很不错，如果你觉得它有用的话。我不确定我个人是否会因此增加或减少任何分数。
我不同意
生产文件 = 压缩后的输出，不适合人类查看。
我做类似的事情
在 CSS 中说明它包含或不包含什么内容
这样我就可以复制/粘贴/搜索它，因为我已经对每个部分进行了注释
STYLE.CSS 包含
http://krsiak.cz/style.1.1.0.css
我现在在我的样式表中使用目录，但我不会对节点进行编号，以便以后更容易插入内容而无需重新编号。我确保目录使用与章节标题注释相同的文本，以便于使用搜索跳转到该文本（例如，Sublime 中的⌘-I 或 TM 中的⌃-S）。
@ Chris – 虽然康纳在他的回复中没有提到，但我认为他通过首先检查生产代码可能发现了什么。不是为了了解它的结构，而是为了证明**你**主要的生产要点：文件应该被最小化并且不可读。如果它们没有被最小化，这应该被视为第一个危险信号。
我在顶部添加了一个颜色键。
我也在主样式表 (MASTER.CSS) 中使用颜色。
#000; black (body, text, menu) #333; gray (dark - menu hover) #666; gray (text, border) #999; gray (table border) #CCC; gray (background) #EEE; gray (light - menu, background) #FFF; white (background, text, text shadow) #0645AD; blue (links) #98C22A; green (slider button) #AECA20; green (slider button:hover) #F9F9F9; gray (bg color in jQuery) #C4ED68; green (.highlight border) #E2FF9E; green (.highlight background)我真的很想知道像“left50”或“bigGray”这样的类。有什么不好的地方吗？有什么文章可以阅读和学习吗？因为我有时会使用它，我想知道问题出在哪里。
非常感谢！
这都是关于语义化的——即不要使用描述元素外观而不是结构的名称。
例如，如果你的客户需要更改颜色方案，你的 .bigGray 现在可能变成绿色。或者你的 .left50 边距需要更改为只有 25px，这样名称就没有任何意义了——尤其是如果其他人试图编辑你的代码。
也许可以阅读这篇文章，Chris 对此的解释要好得多！
希望对您有所帮助。
这是我唯一不同意的一点。如果该类仅且始终“执行该操作”，则 left50 类是可以的。
例如，如果 left50 只是浮动到左侧并且宽度为 50%，那么为什么要将其命名为其他任何名称？如果在将来的某个时间点，您希望元素的宽度为 40%，例如，则将其类更改为 left40。
960gs 的类名代表它们的样式。
澄清一下，我同意大多数类名应该足够宽松以接受样式更改，但类名中的清晰度也使标记更易于阅读。
例如：ul.list_normalize.left50
如果您知道样式表，您可以轻松阅读此标记并了解（例如）此 ul 没有边距或填充，并且向左浮动，宽度为 50%。
我更偏向于可读性而不是模糊性。
仅供参考，但我欢迎批评。
语义化在很大程度上是个人喜好，实际上没有“正确”答案
@Devin – 使用 left50 作为类实际上并不正确，因为不仅在宽度变为 25px（因此为 .left25）时需要更改 CSS 文件，还需要更改 html/php 文件——我认为这会增加工作量。
另一个快速测试…
滚动到 CSS 文件的底部，看看应用了多少黑客手段。
如果你将条件样式表也视为黑客手段的话 :)
在我的情况下
IE 7 = 15 次
IE 8 = 1 次
http://krsiak.cz/style.1.1.0.css
老实说，这篇文章需要一个很大的免责声明。根据文章内容，你根本没有资格评判别人的 CSS。其他人已经谈到了这个话题——上下文决定一切。你没有考虑到
1. 开发人员集成他们无法控制的代码。
2. 使用自动生成类和其他代码的 CMS 或其他框架。它可能不符合逻辑，但需要输出。
3. 其他开发者自开发人员处理代码以来对其进行了修改。也许它看起来相同并且具有相同的结果，但没有开发人员会回过头来查看旧站点以查看自他们处理代码以来是否有任何代码更改过。
4. 修改 CSS 的 JavaScript。并非所有开发人员都可以选择如何集成 JS，以及它是否会使 CSS 变得混乱。
还有许多其他场景，优秀的 CSS 开发人员会无法通过你的所有测试。
这篇文章顶部有一个名为“为什么？”的部分，其中介绍了您可能需要执行此操作的原因。这些都是有效的观点，但我认为您要么已经知道它们，要么会在讨论中出现。
Chris，是的，我读过。但是，似乎不能安全地假设每个人都知道他们不能仅仅以表面价值来接受你的测试。即使在与人们讨论之后，我发现许多面试官自己对代码的了解也不够，即使进行讨论也无法理解这种情况。
我想这个页面在 SEO 中的排名会很高。因此，许多面试官将阅读此页面并获得错误的信息，对优秀的开发者做出错误的判断。
如果一个优秀的开发者因此而被淘汰，那可能是在帮他们一个忙，让他们没有得到这份工作。
话虽如此，可能只需要在开头附近加上一句话来澄清一下，也许更容易根据开发者的个人代码进行评判，因为很多因素都会影响代理代码的标准*叹气*
尽管如此，这是一篇很棒的文章！
关于 CSS，评论中所说的重复性基本上是不正确的。这正是 LESS 和 SASS 之类的东西存在的原因，它们应该以该标准进行评判。但是，当坚持使用 CSS 本身时（直到 CSS 变量和其他一些内容得到普遍支持），对于像 box shadows 和 gradients 这样复杂的规则，你可以用来减少重复性的技巧是有限的。我会通过说存在可避免的重复是良好/不良 CSS 的指标来改进它。
对我来说，“选择器测试”中还包含每个样式在后面被覆盖的次数。拥有一些基本样式，然后稍后使用更具体的类覆盖它们是好的，但是如果在单个样式表中多次重置相同的样式，在我看来这很糟糕。
但这并不是通过浏览 CSS 文件就能轻松检测到的，你需要使用过 CSS 和相应的 HTML 才能知道哪些部分可以改进。
我最近实际上继承了一个非常大的项目，其中所有内容都是类，并且无法控制一些 HTML 输出，但某些样式需要特定于页面，因此需要执行以下操作…
.article #comments ul > li > a.button {
/* 疯狂的城镇 */
}
不幸的是，这是必要的。如果我有时间重写所有内容，相信我，我会这样做。绝对是使用类的错误方法。这也是代理内部开发隔离开来的巨大缺点之一。
这是我的 CSS 提示。我不会详细说明理由，但如果你使用这些技巧，你就会从中受益。
– 无论单词分隔符是什么，都不要使用多单词类名
– 避免使用 ID，除非在 body 标签上和/或用于识别 JS 元素（不用于样式）
– 识别内容，而非样式。例如，类名永远不应该明确说明规则中定义的任何内容（不要使用像“.one-third”这样的类名）。
– 记录项目 CSS 开发生命周期中使用的每个类名。
此外，对上面提到上下文的人表示感谢。例如，在需要与您无法完全控制的系统集成的情况下，反对使用 !important 是荒谬的。而且，至少对我来说，项目越小，越可以打破规则。CSS 实践最重要的是应用于长期性和可维护性……您只需要快速完成的超小型项目并不总是需要应用这些规则。如果项目变得很大，您总是可以在以后重构。如果您一开始就擅长编写 CSS，那么重构不一定很难。
话虽如此……我也认为有意地不要过于努力也有一些道理。有时，您会通过稍微粗心一点来“发现”您的展示趋势的共性，而不是一开始就试图过度设计。编写优秀的 CSS 就像编写优秀的英语，需要多次草稿和多次迭代才能做到简洁、切中要害，但最重要的是，仍然有趣。
阿门 ;) CSS 确实以某种“风格”（此处无意双关）编写，即使应该有一些基本准则，但也有一些原因导致某些“工具”（如“!important”）可用。
所有这些，加上逻辑感和事后的清理，都能起到很大的作用！
我认为大型 CSS 文件并不总是糟糕 CSS 的标志，它可能是设计人员不一致的表现。
上面给出了很棒的建议。命名对我来说也很重要。用事物本身命名，而不是用其功能命名。
至于 CSS 中的注释，我从来不写。因为只有我一个人在处理它，所以我认为没有必要添加注释。对我来说，添加注释就像用写着门、墙、桌子、床等的便签覆盖我的房间一样。如果要将其作为示例发布或为其他人编写，则注释是有意义的。
至于我的个人 CSS 文件，如果独立 CSS 文件超过 7kb，我总是喜欢回去仔细检查我的工作。我还将样式切换器使用的 CSS 文件保持在 100 字节或更少。
此外，大约每月一次，我会清理我的 CSS。如果我在 HTML 文件中删除了一个类，那么将其保留在 CSS 文件中就没有意义了。同样，我还检查是否有冲突的样式。如果父级指定了边框，子级指定了无边框，另一个子级指定了另一个边框，那么就需要调查原因并找到一种简化代码的方法。
即使只有我一个人在处理，我也会为我的 CSS 添加注释，因为如果我六个月后不得不回头看它，我绝不可能记得所有内容是什么或者我将所有内容放在哪里。
你一定是那个为我接手清理的这个项目编写 CSS 的人。幸运的是，我按时间收费，包括弄清楚构建该网站的廉价人员试图实现的目标的时间。
这些都是我抱怨的事情。但是，在当今以 CMS 为中心的 Web 开发中，很难保持最佳实践。通常您会继承类名和 ID 名称，以及来自第三方开发人员的大量 CSS。有些非常合乎逻辑，有些则很疯狂。
有时您可以简单地注释掉样式表并从头开始。有时您必须深入挖掘扩展程序并更改内容以满足您的需求。
我希望我可以用一个低于 100k 的 CSS 文件创建一个简单的网站。
我听过的关于“CSS 最佳实践”的最佳演讲。
名为“面向成人的 CSS：成熟的最佳实践”，由 Andy Hume 发表。
http://schedule.sxsw.com/2012/events/event_IAP9410
听一听吧，它会震撼你的（CSS）世界！
还有幻灯片。 :)
https://speakerdeck.com/u/andyhume/p/css-for-grown-ups-maturing-best-practises
谢谢，非常有帮助 :)
这里已经涵盖了要点。了解此线程中的任何人在以下方面有什么想法会很有趣。
将各个区域划分为单独的样式表，然后在网站上线时将它们压缩成一个文件——我正在开发一个基于 Skeleton 的网站，其 CSS 文件到处都是！
按特定顺序（例如字母顺序）组织样式表。
这些算作“最佳实践”吗？
谢谢！
字母顺序？这太荒谬了，您应该按优先级组织它们。
我最近开始用 LESS 编写 CSS。对我来说，用这种方式编写 CSS 意味着我的选择器更简洁，总体代码更易于阅读，结果也更干净。
我缺少一个 !important 指标来表示“不太好的”CSS，对我来说，它会立即揭示编码人员的 CSS 知识水平：那就是相互矛盾的属性。我经常遇到像 .left_img {float: left; clear: left;} 或 div {display: block; display: inline;} 这样的情况——这真的是有人不知道该怎么做，只是在尝试。
另一个类似的指标：属性自身覆盖，例如 .error{color: red; color: pink;}——每次我看到这样的东西时，当不得不继续使用这个 CSS 时，我都会感到一种恐惧。这意味着永远无法准确知道属性是在哪里设置的。结果是大量的调试和搜索——这些时间本可以更好地利用。
天哪，我读了每一条评论并点击了每个链接……潜在的脑损伤即将发生……
无论如何，我喜欢所有的输入，但是对于我自己来说，我会说使用 !important，对我来说，99.999999% 都是纯粹的懒惰，正如论点所说，客户通常不在乎，他们只想要结果，而且越快越好。
我想如果我要写的东西要受到审查，我会确保没有这种情况。无论如何，我发现自己坚持一个可靠的结构，不是为了别人，而是为了我自己……我不得不修改一两年前的东西，我早早就学会了，如果没有某种系统和干净的代码，真的会让你自食其果。
精彩的文章，喜欢这场争议 ;-P
我发现 !important 真正有用之处只在 print.css 中。
http://www.alistapart.com/articles/goingtoprint/
我不确定选择器测试。我知道保持选择器尽可能短是最佳实践，但我更喜欢正确性而不是简洁性。
缩短选择器要么意味着在 HTML 中散布额外的类（糟糕），要么使选择器不那么具体。当 HTML 组件使用新的和不可预见元素或粒子扩展到网站的新版本或更新时，就会出现问题。突然，旧的选择器开始应用于比预期更多的元素，这显然是灾难的根源。这肯定会导致丑陋且难以维护的代码。
因此，我宁愿检查选择器的正确性，并尽可能减少覆盖，而不是使用短/简洁的选择器。
需要关注的一点是他们对 IE 的处理方式——他们是否完全忽略了它？
他们是否使用了老式的 IE 技巧？（例如下划线技巧）
他们是否使用了内联条件注释或使用了将“添加 IE 类”到 html 标签的技巧？
IE 列表还在继续。这些只是一些明显的例子。
对我来说，技巧更糟糕，因为它们很难找到而且很容易被忽视。
html 类很好，因为您可以在一个地方将其放在样式表中。
这篇文章对我来说非常及时。我目前担任初级前端开发人员。这是我第一个纯粹的前端角色，这意味着我不得不忍受被贴上初级标签。上个月我们聘用了一位新的高级前端开发人员。他病了，所以我不得不顶替他。他的代码包含所有这些错误，甚至更多。我现在正在处理他的代码，试图在他在已有的时间内的一半时间内完成相同的截止日期。我将把这篇文章转发给我的项目经理……
正如其他人所提到的，在处理具有大量第三方模块的 CMS 平台时，类名和 HTML 输出通常嵌入在 PHP 深处，或者在不断变化的、客户端编辑的 HTML 中，这使得很难重构结构以适应 CSS。虽然此建议对许多其他网站非常有用——并且一些建议肯定适用于 CMS 样式表——但在使用 Drupal 的 ZEN 样式表进行主题设计时，一些冗余和特异性是必要的邪恶。
我很惊讶http://www.slideshare.net/stubbornella/object-oriented-css还没有被提及，尽管它已经被引用了很多次。
除了以上几点，我还想寻找
1. 规则中常见的并且可以嵌套的元素，例如：
.mymodule div {}
尤其是在结合字体大小时，字体大小当然（也应该是）使用相对单位。
2. 导致可访问性问题的 CSS
例如，如果一个元素具有 position: absolute，则需要在浏览器中检查它，以确保在文本放大时不会覆盖其他内容。在像素中设置高度并使用 overflow: hidden 也需要在浏览器中检查，以确保在文本放大时不会截断内容。还有很多其他问题，例如轮廓、在 :focus 和 :hover 上的变化、display: none 与 position: absolute 和 left:-99999px 等。
如果你/其他人不认同企业责任方面，那么可以这样想：代码正在使你的公司和/或你的客户面临诉讼风险。
3) 如果文本变长，背景不会扩展
4) 没有利用层叠样式表也是一个常见的缺点。
5. 或者，重用一个样式，而这个样式的名称会让你误以为它只应用于特定区域。在模块 A 中更改了某个样式的填充，然后发现模块 B 崩溃了？就是这种情况。
@ Matthew J. Sahagian – 为什么不使用多单词类名？你是在进行骆驼命名法运动，还是有良好的性能原因？
我使用骆驼命名法命名脚本变量，使用下划线命名 CSS。除了混合两种不同的编程范式之外，它还可以使我的代码更易读。
关于“!important”问题……虽然我总体上同意，但有时它是一个好主意，例如在使用 @media 查询进行屏幕大小或打印时，以确保代码被覆盖，无论其他任何内容正在发生或将来可能发生什么变化。
有多少人压缩了他们的 CSS？在一个小的静态 7-12 页网站上，这样做值得吗？
压缩是为了获得更快的加载时间，因为文件大小更小。
如果你正在处理大型项目，请压缩！
如果这是一个你想让人们查看代码的网站，请不要压缩，因为你想让它易于阅读。
我建议使用 CSSLint、CleanCSS、Chrome Inspector CSS Selector Profile 或 Dust-Me Selectors 等工具运行糟糕的 CSS，以生成报告，展示样式规则的缺陷。网站所有者不太可能将这些发现视为意见。
很棒的文章。学习改进方法总是一件好事。当然，建立起适合自己的系统需要一段时间。代码凌乱并不一定是因为设计师/开发人员懒惰，而是有些人还没有找到适合自己的方法。
不过，读起来很棒，我难以将模板作为起点使用，很难融入别人的风格。我正在考虑创建一些自己的默认模板，尤其是在响应式设计盛行的当下。
好文章，只是希望更多开发者能够遵循“良好的编码实践”。
WordPress 主题就是一个很好的例子，我感兴趣的每个主题都有一些非常“脏”的 HTML 和 CSS 代码。
好文章，我认为另一个测试（这可能在评论中，我只读了前十几条或更多）是 CSS 文件的末尾是什么样子。
对于运行了一段时间的网站或经历了多轮客户反馈的网站，查看底部并查看是否有一系列修复被附加到文件的末尾，这很有趣。如果在一个大型项目或长期客户中，这可能会变成一个接一个的修复。
这是我的建议
过好你的生活！让混乱统治！终身使用廉价的脏 CSS！
对我来说，一个明显的标志是在生产 CSS 中使用**@import**。
即使我理解在创建 CSS 时必须应用某些“标准”或“行为准则”（首先是为了自己的理智）。但我必须补充一点，最终，只要一切看起来都很好，工作起来都很好，速度很快，一切都很好。如果你必须在一个团队中在一个文件上一起工作，那么一些规则很可能非常受欢迎：D
我对它的看法
http://cdn.memegenerator.net/instances/400x/17312350.jpg
对于那些说永远不要使用 !important 声明的人，显然你们从未尝试过修改一些 Dojo 主题。至少在 < dojo 1.5 中，他们的 CSS 充满了不必要的长选择器链，其中包含大量 !important。（说真的，Dojo 团队不知道如何编写 CSS）
不幸的是，对于我正在处理的内容，我无法删除基本的 Dojo 主题，因为这需要花费太多时间来迁移我们使用的样式，并确保整个应用程序仍然可以工作。
当然，这一切都非常主观。有许多不同的组织风格。有些人喜欢按字母顺序排列选择器中的所有属性。就我个人而言，我喜欢先对位置相关的属性进行分组（position、display、margins/padding、float 等），然后是边框、颜色和其他特殊效果，最后是文本样式。
这反映了我在更高层次上的做法，我同样首先使用影响页面整体布局的通用规则，然后逐步处理更具体的元素（这是自然的，考虑到 CSS 层叠样式表的工作方式）。
至于“糟糕”的选择器示例，在我看来它并不算太糟糕。我可以很容易地想象在其中它将是一个完美的选择器的用例。但是，当你开始在一个规则中看到多个 ID 选择器（例如“#main #content #comments .foo”）时，我就会开始怀疑。在 CMS 驱动的网站中，有时这是必要的，但希望不是。我通常只在从其他开发人员那里继承的 CSS 中看到这种事情，或者在网站经历了多次设计大修但没有机会丢弃旧代码并从头开始的情况下看到这种情况。这在现实世界的项目中不幸的是很常见。
我总是尊重那些承认自己 CSS 完美的 前端开发人员。让我们面对现实吧，我们可能都回去查看过自己的旧 CSS，并意识到事情应该以不同的方式完成。我知道我做过。同样重要的是，CSS 编码人员不断尝试改进技术。一个很好的衡量标准是：他们上次重建自己的作品集网站是什么时候？我已经根据过去 6 个月学到的东西，对自己的开发/设计工作了几个月。
对于更技术性的内容，他们是否使用了有趣伪选择器，例如
等等。
他们是否使用全局选择器，例如
对我来说，这些东西表明了他们对实际“思考”结构/特异性/未来修改/开发以及简化可能不需要的许多 CSS 规则的更深入理解。
一个承认自己不会编写完美 CSS 的开发人员（尤其是在他们确实编写了优秀的 CSS 时）是很少见的。
糟糕……在第一行，我的意思是说我尊重那些可以承认自己的 CSS 不完美的 前端开发人员。
呵呵，当我阅读评论时，我猜到了类似的事情（即使评论也容易出现一些微小的错误，这些错误可能会将含义改变 180 度：p），并且当你使用更高级的选择器来“掌握 CSS”时，你确实有道理。不幸的是，这也仅适用于更高级的浏览器，因此，只有在应用渐进增强方法时才应使用此 CSS。（或基于 jQuery 的模拟 css3 .js 文件）。无论哪种方式，本文确实触及了一些敏感点。（我也首先承认我的 CSS 并不完美，也永远不会像我想要的那样完美……我将 CSS 看作一种不断发展的方式，它是一个会随着时间推移而发展的生命体，并且对相同的问题会有许多不同的方法。虽然对其基础知识的了解可能会设定一个标准，但最终，是编码人员的“手”或“签名”最终体现了对它的真正掌握。就像有许多不同的绘画风格一样，也存在许多不同的编码方式。话虽如此，这可能不会是关于手头主题的最后一句话。
@CiNiTriQs – 说得对！
非常有用的判断 CSS 的清单。学习新东西总是好的。每个开发人员都有不同的编码风格，这个测试可以帮助判断任何开发人员的 CSS。我认为代码应该简洁易读。
感谢这篇文章 :)
对于微小的、单开发者项目来说，如果创建 CSS 的人同时也要压缩它并通过 FTP 将文件上传到“生产”服务器，你可能会这样判断，但对于此类项目来说，追求最佳实践的额外开销可能是浪费的，因此判断可以在明显的测试上停止。CSS 代码不像核心系统那样需要复杂的业务逻辑，所以没有必要投入太多精力去维护它。优秀的开发者有足够的经验知道何时打破规则，而一些使用 css-tricks.com 上的帖子来评判他们的家伙只会抱怨找不到好的开发者，因为按照这些规则编写代码的人并不是那些能够解决问题的人。他们必须在一个团队中工作，使用与他们习惯不同的编码风格，处理遗留代码，应对比 IE 更糟糕的嵌入式浏览器，处理不可修改的 HTML，处理 SVG 的 CSS，以及预算紧张和截止日期严格等问题。在招聘时，代码是我最后考虑的事情。
但是，类名中缺少命名空间是一个明显的迹象……
我是一个自学的前端开发者，我经常想知道我的 CSS 是否“好”，这确实帮助我评估了自己的水平。在大多数情况下，我都能通过！我认为我最大的缺点是注释不足，而且不太常用简写。这是一篇非常好的文章，谢谢！
我原本以为文章中会有一节提到浏览器 hack 的内容？
惯用 CSS 非常好；我帮助将其翻译成法语（所以非常了解它），并且相信它是一个很好的起点。
你不必完全按照它说的去做；它只是给你一个如何使事情一致运行的想法，并提供了一个“最佳”示例。
这里再投一票给 惯用 CSS。它是一个简洁的参考，包含了可靠的原则。
有没有办法使用 CSS 隐藏所有 !important 标签，例如，来自那些想要通过揭露你的无能来毁掉你生计的混蛋？
作为使用它的惩罚，人们应该写一千遍
.lazy-developer { use-!important-as-a-get-out-of-CSS-jail-free-card: none !important;}
实际上没有，我自己也讨厌使用 !important，但是多个 CSS 的结构以及它们在某些（不方便提及的）CMS 中被调用的随意方式可能意味着它是有必要的。
我也倾向于在响应式设计中使用一点 important 来覆盖样式，别评判我！
基本上在所有情况下，我只有在时间非常紧迫，别无选择时才会使用 important！=)