Are "CSS Shorthands" not good in team development?

Are "CSS Shorthand" not good in team development?

When multiple person work on same project . any person can have different level knowledge of CSS so some people开发者_运维知识库 can be confused with shorthand when they need any changes in css.

For example:

Should i avoid this

font: 1em/1.5em bold italic serif

and use this

font-size: 1em;
line-height: 1.5em;
font-weight: bold;
font-style: italic;
font-family: serif 

in team development? and Which shorthands are other CSS shorthand are not good to use for readability and which are good?

---

When "writing code", i tend to be fairly verbose. When code such as css/js are pushed to production they can easily be minimized/optimized automatically by a delivery script, giving you the best of both worlds.

---

While evidently unpopular on SO, a couple points in favor of breaking things onto multiple lines in team scenarios:

1) Clarity when using source control. Individual lines changing in source control are often easier to deal with and very clear when reviewing changelogs.

2) With tools like firebug, etc. having the correlation to exact line numbers can be helpful when you are tweaking properties, hunting, saving, reloading vs. one property of many in one line.

---

It depends on your team. Personally though, my team likes them, clean, concise and they're not that confusing.

I'd argue that padding: 0 0 5px 0; is more confusing than your font example because you need to know it's top, right, bottom, left...with most shorthand you can read no matter the order and still easily see what's happening.

I'd wager even the average Word user could see your font example and make out what's happening, and that says a lot for clarity.

---

If a person is working editing CSS files, he should be able to at least google it if in doubt. After enough times seen the shorthand, it will be second nature to them. Furthermore, they most likely will find it cumbersome to read 5 lines when they could have read 1 (I know I do) to understand what is going on. Being more verbose is not a good thing when trying to get a lot of information.

Readability matters, but its perception changes from person to person. I find the shorthand expression more readable, even if I have to do a google search every now and then to make sure the order is correct. On Python I would never think to not use @decorators or list comprehensions just because one proverbial beginner might find it strange, it makes my code shorter and hence, more readable.

Hand holding doesn't work for developers. Make them suck it up, and learn the language they are being paid to create/read.

---

I tend to think of code as write-once, read-often. So I think short-hands are OK if they're obvious and frequently used, but I think it's best to avoid the odd-ball stuff. I consider myself a competent CSS coder and I must admit that font-size/line-height shorthand is new to me.

---

Code for readability (appropriate for the lifetime of the project)

Use compilers, optimisers, and compression for performance

This applies to practically any code, not just CSS

---

It all looks the same from here. If somebody doesn't know how to look up the meaning of the parameters for the short version they're in the wrong role. Also the second takes up more bandwidth. I'd only use the long form if you want to set a couple of the params instead of all of them

---

The more readable you can make your code, the better. Never assume anyones knowledge.