Writing CSS For Others - CSS Essentials - page 141

• You could leave the company, take a vacation or be o " sick, at which
point someone else will inherit your code, even if only temporarily.
• Someone will inevitably poke through your source code, and if they've
never met you, this could be the only basis on which they judge your
work. First impressions count!
Comments Are King!
One thing I've learned from building a massive front-end framework at work
and from producing inuit.css is that comments are vital. Comments,
comments, comments. Write one line of code, then write about it. N.B. This
is not meant to mean write about every line of code, as that would be
overkill. Only comment where it helps/is useful.
It might seem like overkill at first, but write about everything you do. The
code might look simple to you, but there's bound to be someone out there
who has no idea what it does. Write it down. I had already gotten into this
habit when I realized that this was the same technique that a good friend
and incredibly talented developer, Nick Payne, told me about. That
technique is called “rubber-duck debugging”:
… an unnamed expert programmer would keep a rubber duck by his
desk at all times, and debug his code by forcing himself to explain it, line
by line, to the duck.
Write comments like you're talking to a rubber duck!
Good comments take care of 99% of what you hand over and — more
importantly — take care of your documentation. Your code should be the
documentation.