I've worked on a few different front-end development teams over the past few years, and I've seen a range of coding practices—the good, the bad, and the ugly. What follows is a compendium on CSS organization.

Follow Your Code Standards Guide

I want to be clear, before I dive into any specifics, that you should always follow the code standards or style guide for the team you're working with. The goal in code organization for a team of any size is clarity and consistency. Your code base should look as though one person wrote it. If you don't have a code standards guide, then I implore you to write one or adhere to someone else's.

Use Ample White Space

White space is a key component for clarity in any aspect of design, whether it's visual design, writing, coding, etc. White space is free, so you have no reason to be stingy. I recommend using a single line break between properties in a property list; two or more line breaks between declarations starting with the same element, id, or class; and four or more line breaks between declarations for different elements, ids, or classes. One exception is a declaration with one property-value pair; the declaration and property-value pair can inhabit the same line. There's a nice side effect when using this style for line breaks: understandable and easily-skimmed git blame (or whichever repository flavor you use), diff, etc.

Comment Liberally

Most developers I work with shy away from comments, but I find them indispensable. Annotating your code allows others on your team to understand why you've chosen a certain technique. Alternatively, you could just ask why your teammate chose a certain method. This approach is fine for small teams, but it's nearly impossible for large teams. Answering the same question multiple times is a waste of time.

A well-written annotation also helps you. Sometimes you need a reminder for why you wrote a declaration a particular way. I know comments have saved me from myself more than once. Good documentation saves time.

Comments also add clarity. As Donald Knuth said, “I still think people could be documenting what they write much better. And a comment is different than writing an essay. The way you write a program for another human being is completely different from the way you write it for a computer.” Your teammates are not computers. Write a commentary they can understand. Remember, the goal is clarity.

What About File Size?

I often hear this argument, "Well-documented code with ample white space sounds nice in the theoretical world, but it leads to larger file sizes in the real world. And serving large files is not good." I'll be the first to say serving large, fully-commented, abundantly white-spaced files is bad. This sounds like a contradiction to my advice on writing team-centric CSS, but it's not. The files your team uses and tests with should be different from the files you serve your end users. How is this possible? Minification and compression. A major component in any team's build process should be the step where comments and white space are stripped from the production files. I use YUI's Compressor and gzip to drastically reduce file sizes for lightweight production files.

This leads to another valid argument, "Multiple versions of the same file bloat the repository." I agree. They do. My only counter is that having well-documented, amply white-spaced code adds clarity and consistency in a team environment. The trade-off is well worth it.

Maybe you're a freelancer and have worked on a few different teams. Maybe you're a one-man shop. Maybe you're part of an in-house team. Whatever your role, I hope you found this advice helpful. I don't claim to have the ultimate answers for code organization, and I'd love to hear how you organize your code. and share your wisdom.

Last month I read Coders at Work, a collection of Q&A interviews conducted by Peter Seibel with 15 of the top computer scientists of all time. There were some common responses that tied each of these programmers together. I like to think it's their inadvertent advice for aspiring programmers.

Read other people's code. This sounds like an inane task. Who wants to waste hours of time reading code with so much good literature out there and so little time to read it? Their arguments were simple: seeing someone else's thought process is beneficial, you might learn something new, and you may learn how good—or bad—code is organized. Douglas Crockford has an interesting method for reading code. He organizes the code before reading. This allows him to focus on the content and not the organization. Others print out code to annotate it.

Learn to write well. Nearly every programmer agreed with this point: programming is more like writing than math or engineering. It's true, there is an exorbitant amount of math, nay logic, in computer science, but writing a program others can understand is more like writing a novel than a collection of equations.

Learn one language well, then learn other languages. Learning a language well means understanding the methodologies, not just the syntax. Also, learning a language from different types of programming—procedural, object-oriented, declarative, etc.—can be beneficial as each type approaches different problems in different ways. This can influence the way you view your main language.

IDEs and debuggers are overrated. This does not mean IDEs and debuggers are bad. This simply means they are not the best tools to use when starting out. By all means, use them if you are a seasoned programmer. I am apt to agree that IDEs are bad, though. They potentially create hundreds of lines of code without your knowledge, give you far too many hints, and generally dumb down the craft of writing a well-formed program. Debuggers, on the other hand, can be extremely useful if you know how to use them. The unfortunate step is learning how to use them. Stick with a simple text editor—vim and Emacs are wonderful—and use print statements for debugging.

Practice, practice, practice. You can't learn a craft unless you practice it often. You can't improve unless you practice it daily. Based on some other reading, pace yourself. If you plan on practicing 5 hours a week, practice 1 hour each day. Cramming is not the same as practicing.

A deep understanding of complex math is not necessary to be a good programmer, but it may be necessary to be a great programmer. Donald Knuth describes himself as a mathematician and a computer scientist. He's also a phenomenal programmer. Now, there are plenty of mathematicians who are lousy programmers, so the argument falls apart, but understanding discrete mathematics—or any high-level mathematics—can only improve your understanding of computer science and programming.

Read the classics. This is the same advice I'd give to anyone in any field. Read the classics if they exist. There's a reason they're called classics. My first thought would be, “What are the classics?” Mr. Seibel asked every programmer, except Mr. Knuth, if they'd read The Art of Computer Programming, by Donald Knuth. Also, Edsger Dijkstra's A Discipline of Programming was frequently referenced. These two books (the first is a series) seem like a good place to start. Each programmer also listed books they'd recommend for anyone from novice to expert.

Learn C, not C++. Neither is great, but C is better than C++ simply because it's smaller. Some programmers defamed C++ while others were ambivalent. Regardless, learning C seems like a good place to start if you're familiar with programming. Otherwise, I'd suggest Python or Ruby as they protect you from making silly mistakes that C and C++ won't.

Start with pencil and paper. A bad design in a new or great language is still a bad design. Think through the problem as much as you can. Start by writing it. Then take it to the machine. If you hit a snag, rinse and repeat.

Brainstorm with the hive mind; program in a vacuum. Brainstorming with a few people can turn you on to multiple solutions. No two people think exactly alike. Ambivalence was rampant on eXtreme and paired Programming. Basically they all agreed that XP and paired programming work well, but they usually benefit only the weaker individual.

Multicore processing is the future of programming. Start wrapping your head around it.

I'm still mulling over their advice. Some of it seems quite controversial, though most of it is quite good. One thing I'm trying to keep in mind is most of these programmers started programming at the dawn of the age. There were small systems, small languages, and small groups of like-minded people. They could keep it all—the architecture, the memory states, the language, etc.—in their heads because it was such a small set to remember. Now, the languages are larger, the machines are faster, the memory is gigantic. They were born at the right time to be demigods.

Learning new things can be difficult. I’ve already discussed that, so I won’t dive into it again. What I’d like to talk about are a few tools that can help ease the pain as you begin your adventure in learning something new.

The most important tool for learning is the brain. That’s a given. There are, however, a few psychological tools that most of us probably don’t consider when learning that can empower our brains to learn faster and retain information better.

Curiosity is probably the most effective tool you have for learning. A curious mind doesn’t accept a simple answer. It wants to know, not only the what, by the why and the how. Walt Disney is noted for saying, We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.

If curiosity is the wick of the candle, then excitement is the wax that keeps it burning. Excitement for learning a new topic will help you get through the really difficult parts. Trust me, there will be difficult parts. A lack of excitement is why you hated linear algebra—or whatever class you hated.

I quoted Aaron Hillegass’s advice for learning new topics in a previous post. What I didn’t quote was the sentence that preceded his advice, The second trick is to stop thinking about yourself. This claim doesn’t make much sense out of context, so I implore you to read the full quote. Mr. Hillegass is saying that you lose site of the goal—learning something new—when you focus on yourself. I couldn’t agree more, and that’s why I think selflessness is so important when learning something new. It’s not about you; it’s about what you’re learning.

Sleep deprivation has some really nasty side effects, although it can be used to cure depression. There is, however, a direct correlation between getting more sleep and better grades in school. That’s why sleep is the most important physiological tool at your disposal for learning.

A healthy diet has been known to result in better scores on standardized tests, greater attention spans, and less hyperactivity. I won’t go into any more detail on this. Just remember that breakfast is the most important meal of the day.

If you would know how a man treats his wife and his children, see how he treats his books, has long been one of my favorite Emerson quotes. Not just because I’m meticulous with my books but also because I love my wife. That said, it brings me physical pain to watch someone treat a book maliciously—tearing its cover, dog-earing its pages, tossing it to and fro with no concern for its well being. Okay, it doesn’t bring me physical pain, and I’m not overly concerned with how others treat their physical possessions. I am, however, a firm believer in treating books with some respect. They’ll last longer, and you’ll, therefore, be able to reference them for years to come.

Post-It flags are a great investment for more than just keeping books in pristine condition. They allow you to mark off certain sections for quick look up. It’s a better approach than dog-earing a page because you can pinpoint the exact location of what you’re marking, jot a small note on the flag, and never put the book in harm’s way.

Another extremely useful tool is a book stand. I read a lot of books about programming languages, and every author strongly suggests—as do I—that you actually implement their code. This can be quite cumbersome with a book that is prone to close when left unattended. A book stand holds the book at a good angle for reading and keeps your pages held open. There are plenty of options to choose from, ranging from inexpensive to ridiculously overpriced. I use the Easi-Reader Bookstand. It’s inexpensive, folds up for easy storage, and doesn’t get in the way of page turns. It Just Works™.

The following tools are very specific for the material I usually ingest, namely programming languages and general technology books. I like to keep notes, mark my progress, and rate what I read at Readernaut. Readernaut is the resource for bookworms. Give it a try. I’m sure you’ll enjoy it as much as I do.

Every Mac ships with a great little application called Dictionary. Chances are you don’t have the English language completely memorized, and while contextual clues are a great way to guess a word’s meaning, it’s better to know for sure.

This is by no means an exhaustive list. There are hundreds of tools that can aid you in learning. This is just a list of tools that I find extremely useful. There are a lot of different learning styles. Be pragmatic in your approach. You might find the way you were taught in school wasn’t the best fit for your brain. Learn well and enjoy.