HTML and CSS Reference
In-Depth Information
Comments are also an excellent way to show o " . Ever wanted to tell
someone how awesome a bit of your code is but never found the chance?
This is that chance! Explain how clever it is, and just wait for people to read
it.
Egos aside, though, comments do force you to write nicer code. I've found
that writing extensive comments has made me a better developer. I write
cleaner code, because writing comments reminds me that I'm intending for
others to read the code.
Multi-Line CSS
This issue really divides developers: single-line versus multi-line CSS. I've
always written multi-line CSS. I love it and despise single-line notation. But
others think the opposite — and they're no more right or wrong than I am.
Taste is taste, and consistency is what matters.
Having said that, when working on a team, I firmly believe that multi-line CSS
is the way to go. Multi-line ensures that each CSS declaration is accounted
for. One line represents one piece of functionality (and can often be
attributed to one person).
As a result, each line will show up individually on a di " between two
versions. If you change, say, only one hex value in a color declaration, then
that is all that needs to be flagged. A di " on a single-line document would
flag an entire rule set as having been changed, even when it hasn't.
Take the following example:
Search WWH ::




Custom Search