Code Progressions from Large Websites

This year has been a busy one for me in terms of changing the way I code everyday. While I try not to jump on bandwagons or use the latest ‘techniques’ or plugins, of course it’s necessary to constantly both keep up with what’s new in our industry, as well as to try and improve our code. I’ve been coding since the six grade (that’s 14 years ago!), so I tend to have most of what I do down to a solid science. Therefor, I can spend my time, not in learning new code, but in learning optimization and organization.

The biggest teacher for me this year has been the opportunity to work on large projects. When working alone on basic WordPress sites, you can leave your CSS in one document and code the way you want, however larger projects with multiple developers require standard sets of practices, multiple includes, stylesheets and script files. This has taught me ways to break up the code so you’re not having to search through 20,000 lines of CSS, how to limit specificity to avoid stringing multiple IDs, classes and !important tags, and just how important using commenting for both documentation and visual organization can be.

Here’s a bit of detail on just how I’ve changed the way I code recently, while some of these are probably obvious to those working in groups, they come in handy to those of us used to working alone!

Spaces, Not Tabs

I know this debate has been going on for forever and never seemed all that important to me. I’ve always used tabs (the default in Coda and most IDEs I’ve tried) and had the impression using spaces would be a PIA, mostly because I assumed you had to manually hit the space bar for each indention. However, I recently switched to using spaces when one of the programmers I began working with suggested it as a way to avoid Github conflicts. I rarely use Github, and am usually never coding at the same time as others on a project, but this time we were overlapping each other’s work. For some reason, Github gets all wacky when you’re using tabs (and someone else is using spaces), even when you’re not working in the same section of the document so I switched. Of course, if I work with another developer or programmer who’s using tabs, we might be back to square one-I wish Github could equate spaces with tabs to avoid these issues. I would like to hear from some of you who are better versed in Github about this issue.

Classes, Not IDs

I’ve always been a fan of using IDs on elements you know you’re only going to use once. But that’s the issue with larger projects – you don’t always know. I discovered that an element in design 1 that I thought was unique was being used in almost the exactly same way as an element in design 60. Using IDs meant I then had specificity problems when needing to change something simple like the background or font color. I then starting stringing classes, elements and IDs together and my OCD started getting angry after the 3rd or so element. This also caused problems when I needed to make a change across the board.

I’ve gone from simple IDs to multi word classes. Consider:

#comments {
 
}

By itself and on most sites, no big deal. However I ended up also having user messages that used the same layout, as well as 2-3 different versions of comments that only had small differences. Things quickly began looking ugly:

#comments {
 
}
 
#comments.messages {
 
}
 
.loved #comments {
 
}
 
.loved #comments.messages {
 
}

Another example came from a site I was working on today. When I might’ve once used:

.home #newest-products,
.home #popular-products {
 
}

I’ve consolidated into:

.product-display {
 
}

Now, if I need the popular products to have, say a different background, I would simply string along a second class.

.product-display {
 
}
 
.product-display.popular-products {
 
}

This allows me to customize the element, without later running into overwriting with overly specific rules, or having to use the !important tag. This is especially apparent in media queries, when you’re wanting to make a change across the board. I now rarely use IDs, and only as specific selectors for JS.

Extra Comments on Top

I’ve always used comments to split up my CSS, JS and extra long bits of HTML, but this huge project needed something more. While scrolling through endless amounts of CSS (see next section), my eyes would quickly pass by the small comments I left delineating each section. Therefor instead of

/*Header*/

I ended up splitting each main section and page layout with:

/***************************************************************************************************************************************************************************************/
 
/*HEADER STYLES*/
 
/***************************************************************************************************************************************************************************************/

Sub sections and headings would progressively get a smaller comment:

/***************************************************************************************************************************************************************************************/
 
/*HOME STYLES*/
 
/***************************************************************************************************************************************************************************************/
 
.....
 
/******HERO******/
 
.....
 
/*HERO NAV*/

This meant I could significantly speed up my scrolling while still having the comments catch my eye. Long blocks of HTML were also broken up by comments, just so you knew what was what as soon as you opened the document. Javascript remains the only code that’s significantly commented for functionality, as no one ever freaking knows what’s going on there.

Splitting Stylesheets & Scripts

Working with such a large site (this sucker had 60+ mockups for designs), meant that my CSS was naturally going on and on and on. When I needed to scroll in the middle of the document to find a specific color, size or whatever, it required endless scrolling and searching, especially if I didn’t know exactly what I was looking for (an therefor couldn’t use the IDE search or developer tools). Plus, even when you could use these items, it just got completely annoying to have a document that size to scroll through, as well as made the IDE load pretty slowly.

I know a lot of you already break up your CSS into multiple files, but I’ve never been a fan of this. I think it’s ridiculous for most sites to have a main.css, fonts.css, colors.css, layout.css, etc (yes I’ve seen this). Some of these styles could be in one or more of the stylesheets, and when a developer is jumping on board an already coded site, this could make it difficult for them to both find items, as well as maintaining in the long run.

However, I found it extremely helpful (especially so all the developers weren’t stepping on each others’ toes) to break out the responsive, retina and some of the main section elements into their own stylesheets. For example – the entire archive section of the site had it’s own stylesheet, as well as grabbing the main one, since it used a lot of the same elements as the “live” part of the site. Retina had it’s own stylesheet to control for differences between large retina and mobile retina screens. All the media queries were on their own stylesheet as well.

The same was done for all of the JS – especially for those that needed to only apply to one or two pages. We used a variable to check against the page URL to grab only the necessary scripts, as well as breaking up scripts that were long and rambling (like all of the sliders on the site).

During breakout and testing, these will remain separate, but our programmer will obviously concat and minify all stylesheets and scripts.

Wanted: A Flexible Box

The next thing I’m tackling is to learn Flexbox. I’ve done some reading up on it and am ready to try it out on something as soon as I get a bit of free time. I’d love to hear your thoughts on it, and whether you’re using it or not.

All of these amount to small, but important, changes and are more about technique than code. However, it’s helped us break down a very large project into manageable chunks! I’d love to hear about your coding techniques as well, I’m always up for debates and discussion. 😉