“CSS速记”在团队开发方面是不是很好？
当多人在同一个项目上工作时。任何人都可以拥有不同级别的CSS知识，这样一些人在需要css更改时可能会与速记混淆。
For example:
我应该避免这个
font: 1em/1.5em bold italic serif
并使用此
font-size: 1em;
line-height: 1.5em;
font-weight: bold;
font-style: italic;
font-family: serif
团队发展？其他CSS简写的哪些简写不适合用于可读性，哪些是好的？
答案 0 :(得分：9)
当“编写代码”时，我倾向于相当冗长。当诸如css / js之类的代码被推向生产时，它们可以通过交付脚本轻松地自动最小化/优化，为您提供两全其美的优势。
答案 1 :(得分：4)
虽然在SO上显然不受欢迎，但有几个人支持在团队场景中将事情分解为多行：
1）使用源代码管理时的清晰度。在查看更改日志时，源代码控制中的各个行更改通常更容易处理并且非常清晰。
2）当你在一行中调整属性，搜寻，保存，重新加载与多个属性相比时，使用像firebug等工具与精确行号相关的工具会很有帮助。
答案 2 :(得分：3)
这取决于您的团队。就个人而言，我的团队喜欢他们，干净，简洁，他们并没有那么令人困惑。
我认为padding: 0 0 5px 0;比你的字体例子更令人困惑，因为你需要知道它的顶部，右边，底部，左边......无论顺序如何，你都可以阅读大多数简写并仍然轻松看看发生了什么。
我甚至打赌普通的Word用户也可以看到你的字体示例并弄清楚发生了什么，这说明了很多。
答案 3 :(得分：3)
如果一个人正在编辑CSS文件，他应该能够至少谷歌它如果有疑问。经过足够多次看到速记后，这将是他们的第二天性。此外，他们很可能会发现阅读5行时很麻烦，因为他们可以阅读1（我知道我这样做）以了解正在发生的事情。在尝试获取大量信息时，更加冗长并不是一件好事。
可读性至关重要，但其感知因人而异。我发现速记表达式更具可读性，即使我不时要进行谷歌搜索，以确保订单是正确的。在Python上，我绝不会认为不使用@decorators或列表推导只是因为一个谚语初学者可能发现它很奇怪，它使我的代码更短，因此更具可读性。
握手对开发者不起作用。让它们搞砸，并学习创建/阅读所支付的语言。
答案 4 :(得分：2)
我倾向于将代码视为一次写入，经常阅读。所以我认为如果短手牌显而易见并经常使用，那么短手牌就可以，但我认为最好避免使用奇数球。我认为自己是一个称职的CSS编码器，我必须承认font-size / line-height简写对我来说是新的。
答案 5 :(得分：1)
可读性代码（适用于项目的生命周期）
使用编译器，优化器和压缩来提高性能
这几乎适用于任何代码，而不仅仅是CSS
答案 6 :(得分：0)
从这里看起来都一样。如果有人不知道如何查找短版本参数的含义，那么他们就是错误的角色。第二个占用更多带宽。如果你想设置几个参数而不是所有参数，我只会使用长形式
答案 7 :(得分：0)
您的代码越可读，越好。永远不要假设任何人知识。