Project Detritus

Zielun asks of managing projects:

It often happens in projects that based on one, large system with tons of modules that can be enabled or disabled, and documentation is often not up-to-date or doesn`t exist at all. At least I have such experience. I know that real problem lies elsewhere like in project management but such things often plays main role when you or team decides which coding standard to pick for a project to solve such issues.

This project detritus can definitely be frustrating. Big projects that go on for extended periods of time begin looking like sediment layers of a rock formation. It becomes an interesting archaeological expedition as you chip away at the months (and years) of development and can almost pinpoint the time that a chunk of code was written based on the style it was written.

I've rarely seen a long running project maintain an absolutely rigid and consistent coding style. We make mistakes in the course of building a project, correct those mistakes, but rarely go back to correct the ill-conceived approaches used at the beginning of a project.

Nobody wants to clean out the cruft for fear of unsettling the foundation and having the entire project collapse on them.

A modular approach, a good naming convention, and an reduction of element selectors can make it much easier to determine what is and isn't being used on a project. Do a search for a module name and you'll discover right away if it is used and where it is used. Tools can be built to automatically review which classes are being used and which aren't.

This is easier to do if you keep styles in the CSS. Don't keep them inline and don't set them in script.

Why avoid element selectors? HTML can change but it's not as easy to tell if the CSS is being used or not unless you examine every instance. How relevant is #sidebar h2 if I've long since switched level 2 headings to level 3 headings?

To be clear, element selectors can be quite useful. Don't throw out the baby with the bath water. Just strike that balance between when to use an element selector and when adding a class would be cleaner, clearer, and more semantic.

Of course, I talk more about this in a little e-book I wrote...*ahem*

Published April 24, 2012
Categorized as HTML and CSS
Short URL: https://snook.ca/s/1017

Conversation

3 Comments · RSS feed
Wesley said on May 22, 2012

I agree there are times to use classes and id selectors as opposed to element selectors. Do you have any preference or recommendation for CSS frameworks that might reduce unclean code? Also what folder structure do you typically use for your websites, I know there is now right or wrong way, I just want to know how you usually do it?

Jonathan Snook said on May 22, 2012

@Wesley, I don't think there's one CSS framework that will get you through the entirety of a project. Ultimately, code needs to be written and that code needs to follow some guidelines. That's one of the reasons I wrote SMACSS.

As for folder structure, I approach things modularly. For CSS, I'll have each module separated into its own file and use a preprocessor or build process to bundle up the files. Base styles in a file, layouts in a file, dialogs in a file, buttons in a file, etc.

sorry said on June 05, 2012

I really like your site! But I have to try this<blink><h1> ;)

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.