Posted 02.16.2015

Getting your Git On: A Beginner’s Guide to Git

What is git anyway? Short answer: version control. Long answer: Think of it as having unlimited undos on your code. Or better yet, if you’re collaborating with another developer, it allows you to both work on the same project without overwriting each other’s code. Awesome!

This has saved my butt on more than one occasion. I’ve vowed to always use source control, regardless of how big or small the project is.

git

So, now that you’re interested in git, where do you begin? To get started, you’ll need to install git on your local machine (don’t worry, I’ll explain). Eventually, you’ll want to use an online service to store your code, like GitHub, BitBucket, or Beanstalk. (more on that below, too)



Installing git Locally

NOTE:

I use a Mac, so unfortunately, I can only speak to that. However, if you’re using another operating system try looking here.

The easiest way to to install Git on your Mac (if you’re on Mavericks or older) is to install the XCode Command Line Tools. This is as simple as trying to run git from the Terminal.

NOTE:

Remember, when you’re working in the Command Line, the dollar sign ($) is the prompt and signifies a new line. No need to copy it.

$ git

If you don’t have git installed already, it will prompt you to do so.

If you want a more up to date version, or would rather run the binary installer, you can grab that here.

The first thing you’ll want to do is configure your git settings.

$ git config --global user.name "John Doe"
$ git config --global user.email "john@doe.org"
$ git config --global color.ui auto

Git is typically run from the Terminal. However, as a designer, I tend to be a little leary of the Termianal. Granted I’ve gotten more comfortable, but I still prefer a GUI (Graphical User Interface) when I can get one.

I think the easiest thing to do is learn the vocabulary. Then, it doesn’t matter whether it’s the Terminal or GUI, the same concepts apply no matter what.


Learning the vocabulary

NOTE

Here’s a cheat sheet you can print out and keep handy.

Let’s walk through this as you would for a real project.

You’ll want to create a folder on your computer for your project. In my user folder, I have a folder called Code. Then, a subfolder called GIT. I keep all my project folders there.

Code > Git folder structure

If you’re trying to do everything from the command line, these commands create a new folder and then navigates inside:

$ mkdir new_project
$ cd new_project

Let’s initiatize our git repository. (All your git projects are called repositories.)

$ git init

So what does initializing really do? It creates an empty repository in a hidden folder, .git.

NOTE:

If you ever wanted to remove the repository, all you’d need to do is delete that .git subdirectory:

$ git rm -rf .git

Notice, I said empty. It did not add the current content within your folder. You have to tell it to do that yourself.

All the content within your project folder is considered the working copy. Once you get to a place where you want to save those files, you’ll stage your changes and then commit them to your local repository.



The advantage here is not all of the files you’ve modified since your last commit have to be staged and committed.


Status

Let’s get an overview of everything that has changed since we last committed:

git status

git status

Git will put your changes into three main categories:

  • Changes not staged for commit
  • Changes to be committed
  • Untracked files

Add

You can add all these changes by using:

git add .

If you don’t want to add the changes you’ve made, but cherry pick files, you can list them out:

git add assets/dist/css/main.css assets/dist/js/production.js

Remove

If we removed a file, we’d need to confirm that too:

git rm something.html

Commit

Now, let’s commit our updates:

git commit -m "Initial commit"

The first commit, I usually title as “Initial commit” but as you continue to make changes and commit your code, you’ll want these messages to be meaningful. This will make it easier for you (or your teammates) to understand the changes you made later down the road.

Your message should include information like, “What was the motivation for the change? How does this differ from the previous version?”

If you need a longer commit message than 50 characters, you can leave out the “-m” parameter and Git will open an editor application for you to write a longer message.

Here are a few guidelines from Tower’s eBook, Learn Version Control with Git:

  1. Related Changes A commit should only contain changes from a single topic. Don’t mix up contents from different topics. This will make it harder to understand what happened.
  2. Completed Work Never commit something that is half-done. If you need to save your current work temporarily in something like a clipboard, you can use Git’s “Stash” feature. But don’t eternalize it in a commit.
  3. Tested Work You shouldn’t commit code that you think is working. Test it well — and before you commit it to the repository.
  4. Short and Descriptive Messages A good commit also needs a good message.

Log

If you want to review a history of all the commits that have been made to a project:

git log

You’ll see a list in chronological order, beginning with the newest item.

git log

If there are more items than what can be displayed on one page, you’ll see a : at the bottom of the screen. You can go to the next page by hitting the <SPACE> key and quit with “q”.

You’ll notice from the log, every commit has:

  • Commit Hash This is that crazy long string of letters and numbers (i.e. aa093b890c78e9d0869a3f267b2530cf2cbeb83f)
  • Author Name and Email Remember when we set our name and email address within the git configurations above? This is where it gets used.
  • Date
  • Commit Message

Remote

Now that we’ve made a bunch of commits, let’s publish (or push) them online. First we need to tell Git where our remote repository is.

There’s several services you can use, three of the most popular ones are:

I go into a little more detail on each service’s features below.

Regardless of the service you use, when you create a repository, they will give you an SSH address and HTTPS address.

You can use either:

$ git remote add origin git@bitbucket.org:ahhacreative/git_blog_post.git

OR

$ git remote add origin https://ahhacreative@bitbucket.org/ahhacreative/git_blog_post.git

In this case, we named our remote repository “origin.” This is the default within Git. However, I could just as easily name it something else. I usually name mine based on where the remote repository is. This makes it easy within Tower (my GUI of choice) to tell where it’s being saved:

Git Remotes on Tower

From the command line:

$ git remote add BITBUCKET git@bitbucket.org:ahhacreative/git_blog_post.git

You can see a list of all your remotes:

git remote -v

git remotes

You’ll notice there are two URLs listed (fetch and push). One is for read access (fetch) and the other is for write (push). Uusally, the two URLs are the same, but you could use different URLs for security and performance issues.


Push

Now, we need to push our code up to our remote:

$ git push origin master

Hopefully, some of these things are starting to look familiar. origin is the name of the remote repository and master is the name of our branch. (We haven’t talked about branching yet. It’s OK, just trust me for now, but it’s coming.)

git push

Let’s pause for a moment. I just want to take a moment to point out: you’re more than halfway there! It wasn’t that hard, was it?! You know everything you need to know to save, commit, and publish your files online! There’s still more topics to cover, but you already know the basics. That’s worth celebrating!


Pull

OK. So far, we’ve just published our changes online. But, what if we’re collaborating with another developer? They’re publishing their changes too. How do we pull down there code?

First you may want to see what you’re pulling:

$ git fetch origin
$ git log origin/master

If you want to integrate these changes into your local working copy:

$ git pull

If you have multiple remotes and branches, you may need to specify:

$ git pull origin master

Branching

OK, so let’s (finally) talk about branching.

When you’re coding, there are usually several different contexts or “topics” you’re working with:

  • features
  • bug fixes
  • experiments

In the real world, these all happen simultaneously. You’re trying to fix a bug while a teammate is working on the new about page design.

If branching didn’t exist, how would you integrate some of these changes, but not all of them? You need to post the code for the bug fix, but your teammate isn’t ready to launch the new about page. You find out the new “members only” code you’ve been working on is going in a different direction, but you’ve already integrated that code in with everything else. How do you separate it out?


no git branches

Branching!

You can create a branch to handle each of these topics. It stays separate from all the other contexts. When you make changes, they only apply to the current active branch.


git branching

Your current branch can be referred to as the active branch, checked out branch, or HEAD branch. They all mean the same thing.

Whenever you run git status, it will tell you what branch you’re currently on.

current branch by running git status

NOTE

You may have noticed from my screenshots, that my Terminal shows me what branch I’m in and changes color based on whether I’ve there are uncommitted files or not.

git inside iTerms2 and oh my zsh

I’m running Oh My Zsh within iTerm2. I have more details in a blog post.

To create a new branch:

$ git branch feature/about-page

NOTE:

I like to name my branches my contexts. So, you’ll notice, I prepended my branch name (about-page) with “feature.” This is nice because within Tower, it treats these contexts as folders:

branches within Tower

We’ve created a branch, but it’s still not our current branch. To change branches, you’ll need to checkout:

$ git checkout -b feature/about-page

To view a list of all our branches:

$ git branch -v

The -v (verbose) flag, provides more information, than just git branch.

git list branches

Now, that you know how to create and change branches. What happens when you’re ready to commit that code to your main (master) branch?

First, you’ll want to navigate to your master branch. Then, merge in your new branch:

$ git checkout master
$ git merge feature/about-page

Once a branch is merged and deployed, you no longer need it. To delete a local branch:

$ git branch -d feature/about-page 

Stashing

Remember when we talked about not committing half done work? How do you get around that?

Stashing.

git-tower.com explains it well:

Think of the Stash as a clipboard on steroids: it takes all the changes in your working copy and saves them for you on a new clipboard. You’re left with a clean working copy, i.e. you have no more local changes.

To stash your local changes:

$ git stash

To see an overview of all your current stashes:

$ git stash list

The most recent Stashes will always be listed first.

When you want to apply a Stash, you can run:

$ git stash pop

This will pull the latest Stash and clear it from your clipboard. Or

$ git stash apply <StashName>

This pulls the specified Stash, but unlike pop, it remains saved. To delete it, you’ll need to run git stash drop <StashName>


Clone

These things are all great, but what if you’re not starting from scratch? What if you’re joining a project that already exists?

Then, you’ll want to use clone.

$ git clone https://ahhacreative@bitbucket.org/ahhacreative/git_blog_post.git

This will automatically set the remote to the “origin.” Anytime you pull, it will grab any updates made to the repository.

Sometimes, you’ll want to grab the code from a repository, but start with a clean history. To do so, simply add the flag --bare:

$ git clone --bare https://ahhacreative@bitbucket.org/ahhacreative/git_blog_post.git

.gitignore

There will be times when you don’t want to put all your code within your repository. For example, if you’re using bower, you probably don’t want the bower_components folder. Or, if you’re running grunt or gulp, you don’t need node_modules. A teammate only needs to run bower init or npm install to get those files. Committing them would only bloat your repository.

You can create a file called .gitignore and list all the files or folders to exclude. For example, here’s my .gitignore file for a WordPress project:


Remote Repositories

There are several services that you can use to host your remote repositories.


GitHub

GitHub

GitHub is probably the most popular. If you make your repositories public, then you can create an unlimited number of repositories for free. You start paying when you create private repositories.

GitHub also has an excellent issue tracker built in among several other great resources.

Even if you don’t plan on paying for a GitHub account, I would highly recommend signing up for an account anyway. GitHub has practically become a standard for developers. Meaning, if you’re applying for a programming job, your potential employer could ask to see examples on GitHub.


BitBucket

BitBucket

I actually store all my code on BitBucket. BitBucket does everything that GitHub does, but is missing the community that surrounds GitHub.

For me, the decision came down to $$. GitHub’s business model revolves around the number of private repositories you create. BitBucket’s bases its pricing tiers on the number of users. As long as you have under 5 users, it’s free.

As a one-woman web shop, I was easily in the top tier with GitHub. But, with BitBucket, I can have as many free private repositories as I want. That’s a no brainer.


BeanStalk

Beanstalk App

BeanStalk is another great service. Like GitHub, you’re paying based on the number of repositories you use.

It’s missing a lot of the features that the other two services provide, but the biggest benefit it has is built in deployment. Meaning, you can push changes to your repository and it will automatically send those updates to your server via FTP (or however you specify). That’s almost enough to make me switch.

In the meantime, I’m using dploy.io instead. It’s made by the same company (WildBit) that makes Beanstalk. Dploy.io allows you to deploy commits from BitBucket or GitHub. Pricing is based on the number of repositories you’ve connected.


The Apps

OK, now that you know the correct terminology, I want to introduce a few GUIs:


Tower

Tower App

I use Tower. IMHO, it’s the best. Just from glancing at the screenshot, you can see the buttons along the top for most of the vocabulary terms covered in this post. If you want a little more information, check out this screencast (from the Tower app team):


GitHub

GitHub on Mac

GitHub has their own GUI. Unlike Tower, it’s free. I’ve downlaoded it, but I rarely use it since I have Tower.

At the end of the day, it’s whatever you’re the most comfortable with. They all accomplish the same thing. My thing is don’t let the tools get in the way of making cool stuff.



Additional Resources

Granted, we’ve covered the basics, it should be enough to get you up and going. However, if you want to dig a little deeper, here are a few additional resources to check out:



Posted 02.03.2015

Posted 02.03.2015

My SASS Extends, Mixins, and Functions

Last week, I wrote a little post about the SASS I have running on my site. Continuing on, I thought I’d share my SASS broilerplate with some of the mixins, functions, and extends.


Naming Breakpoints

In my SASS breakpoints file, I’m using Chris Coyier’s Breakpoint trick. — It’s a mixin within _2_helpers / _breakpoints.scss file. It takes a break point name and builds out the media query for me.

@mixin breakpoint($point) 		{
	@if $point == zurb-xxlarge {
		@media (max-width: 1921px) { @content; }
	}
	@if $point == large-screen {
		@media (max-width: 1600px) { @content; }
	}
	@if $point == zurb-xlarge {
		@media (max-width: 1441px) { @content; }
	}
	@else if $point == retina {
		@media (-webkit-min-device-pixel-ratio: 2), screen and (max--moz-device-pixel-ratio: 2) { @content; }
	}
	@else if $point == regular-screen {
		@media (max-width: 1250px) { @content; }
  	}
  	@else if $point ==  zurb-medium {
		@media (max-width: 1024px)  { @content; }
  	}
	@else if $point ==  smaller-screen {
		@media (max-width: 800px)  { @content; }
  	}
	@else if $point ==  ipad-portrait {
		@media (max-width: 768px)  { @content; }
	}
	@else if $point ==  zurb-small {
		@media (max-width: 640px)  { @content; }
	}
	@else if $point ==  iphone-four {
		@media (max-width: 360px)  { @content; }
	}
	@else if $point ==  iphone {
		@media (max-width: 320px)  { @content; }
	}
}

I name my breakpoints according to the device (I know. I know.) I’m using: ipad-landscape, ipad-portrait, smaller-screen, iphone. I know the world exists outside of Apple and we are becoming (if not there already) device independent. However, I think in those dimensions.

I also have breakpoints for zurb-medium and zurb-small. I use the Zurb Foundation framework and those breakpoints already exist within the framework. Since, the grid is already collapsing at those points, I need to be able to make adjustments in my code as well.

When I want to implement these breakpoints within my SASS, it will look like this:

.something {
	padding: 100px;

	@include breakpoint(zurb-small) {
		padding: 10px;
	}
}

I have a snippet set up Sublime Text 3 that makes this really easy to implement.



Arrows

On CSS-Tricks, there’s a post about creating triangles in pure CSS. I decided to turn that into a mixin.

@mixin arrow ($direction, $size, $color) {
	@if $direction == up {
		border-left: $size solid transparent;
		border-right: $size solid transparent;
		border-bottom: $size solid $color;
	} @else if $direction == down {
		border-left: $size solid transparent;
		border-right: $size solid transparent;
		border-top: $size solid $color;
	} @else if $direction == right {
		border-top: $size solid transparent;
		border-bottom: $size solid transparent;
		border-left: $size solid $color;
	} @else if $direction == left {
		border-top: $size solid transparent;
		border-bottom: $size solid transparent;
		border-right:$size solid $color;
	}
}

Then, when I want to implement it:

.read-more { 
		&:before {
			@include arrow (right, 3px, black);
		}
}

That’s easy enough.



Color

I have a set of functions for dealing with color:

@function darkest( $color ) 	{ @return darken($color,20%); }
@function darker( $color ) 		{ @return darken($color,13.333%); }
@function dark( $color ) 		{ @return darken($color,6.667%); }
@function light( $color ) 		{ @return lighten($color,16.667%); }
@function lighter( $color ) 	{ @return lighten($color,33.333%); }
@function lightest( $color ) 	{ @return lighten($color,50%); }

I can easily make the rollover color, a shade darker by using:

a {
	&:hover {
		color: darker($red);
	}
}

I don’t have to open Photoshop or create an additional variable.



Black and White (and Color)

%black-and-white {
	filter: grayscale(100%);
}

%color {
	filter: grayscale(0%);
}

Now, I can easily convert anything to black and white:

.my-image {
	@extend %black-and-white;
}

Then, if I want to give it color, say on rollover:

.my-image {
		&:hover {
			@extend %color;
		}
	}


Columns

@mixin columns ($columns: 2, $gap: 90px) {
	column-count: $columns;
	column-gap: $gap;
}

This mixin makes it easy to implement columns. You can tell from the code that I have defaults set for 2 columns with 90px between each column. Meaning, I can implement it without adding any parameters:

.two-columns {
	@include columns();
}

Or if I want to over ride it I can:

.three-columns {
		@include columns(3, 30px);
}

If I want to get crazy, I can even use some of my mixins together:

.two-columns {
	@include columns();

	@include breakpoint(zurb-small) {
		@include columns(1);
	}
}

This just says that the two column class will display 2 columns, unless we’re on mobile. Then, display 1 column.



path

I have a path function that makes it easy to include images within my SCSS:

@function path($src, $dir: img) {
	$src: unquote($src);
	@return url(unquote("..")/$dir/$src);
}

When I set a background image, it might look like this:

.background-image {
	background: path("my-background-image.jpg") center top no-repeat;
}

By default, it puts my images within a img directory. I can override that, either by passing in another parameter or adjusting the function.



Floats

%left,
.left {
	float: left;
}

.right,
%right {
	float: right;
}

%text--left,
.text--left {
	text-align: left;
}

%text--right,
.text--right {
	 text-align: right;
}

%center,
.center,
%text--center,
.text--center {
	text-align: center;
	width: 100%;
}

Tehse are a few alignment classes that make it easy to knock something left, right, or center. You’ll notice I have an extends (%) as well as the class (.) that way I can use these classes on the within my HTML as well.



List Styling

.no-bullets,
%no-bullets {
	list-style: none;
}

This is great when I’m working on site navigation:

nav ul {
	@extend %no-bullets;
}


No Margin, No Padding

.no-margin-padding,
%no-margin-padding {
		margin: 0;
		padding: 0;
}

Just as the name suggests, using this will remove any margin and padding from the element:

nav ul {
	@extend %no-margin-padding;
}


Circles

.circle,
%circle {
	border-radius: 50em;
}

This turns any item into a circle:

.circle-thumbnail {
		@extend %circle;
}


Conclusion

These are all great, but what’s the point? Well, instead of having to write these styles everytime I sit down to work on a project, I have a starting point. Don’t reinvent the wheel every time if you don’t have to. Make it easier on yourself!

Second, any project that I work on, I know I have certain classes available to me. I don’t have to look up the class names. I’ve established a set of standards. Remember, smarter not harder.



Posted 01.28.2015

My SASS(y Pants)

logo-235e394c

There’s been a lot of talk recently about SASS and CSS structure and Style Guides. It’s kind of cool, really, to see front-end take the “front stage.”

I thought I’d add my two cents and pull back the curtain a little bit. Or…watch this video and replace “tight pants” with “SASSy pants.”

Jokes.


Preprocessing

Yes, please.

To me this is a no brainer. Any tool that is going to make my job easier, sign me up!

I’ve run the gamut on these.

I started with LESS because I could put less.js on the server and not worry about compiling. Granted, this isn’t ideal, COUGH graceful degradion.

Then, I started looking into SASS. I was curious because it seemed to be more popular and have more features. At the time, I was running an older verison of MacOS that wasn’t supported by CodeKit. So, I turned to LiveReLoad.

When I did upgrade, though, CodeKit was one of the first things I installed. I LOVED CodeKit…until I started working on a larger project that took a minute plus to compile. In all fairness, I don’t think it was CodeKit’s fault. It was probably the result of Compass building sprites and RubySASS.

Regardless, it forced me to turn to grunt and then finally, to gulp. — And gulp, I shall remain (for now).

The good part about this progression is that it allowed me to experiment with a variety of tools. When I’m collaborating with another developer, I’m able to use whatever method they’ve already put into place.


Prefixing

I used to rely on Compass for prefixing, but Autoprefixer is awesome. The best part is that it utilizes the most recent data from Can I Use to add only the necessary vendor prefixes.


Organization of Files

I keep all my images, fonts, sass, css, and javascript files in an assets folder. They are separated into 2 subdirectories, dist for distributed, compiled files, and src for source, original files.

Screen Shot 2015-01-28 at 8.58.04 PM

Back in the day, when I used to write long form css by hand, I would list my redefined styles at the top: p, a, hr, you get the idea. Then, layout specific styles, pieces I would use on multiple pages, and finally page specific styles. This made sense from a cascading standpoint.

I’ve tried to maintain a similar structure for my SCSS files:

  • _1_base This contains Zurb Foundation overrides and WordPress specific styles
  • _2_helpers These are functions, extends, mixins, variables, and thene files
  • _3_vendor Any third party styles I want to incorporate: fonts, icomoon, etc.
  • _4_redefine Start to lok familiar now? These are the redefined styles that I mentioned earlier.
  • _5_layout Layout specific styles
  • _6_pieces Pieces that I’ll reuse in multiple places (like social media icons)
  • _7_pages Page specific files.

Within each folder, there’s a file with a similar name as the folder (within _7_pages, there’s a _pages.scss file. It lists out all the other files within that directory to include:

@import "home";
@import "blog";
@import "clients";
@import "ebooks";
@import "coaching";
@import "podcast";
@import "speaking";
@import "contact";

Within the main scss folder, there’s a main.scss that imports Foundation and each folder’s “index” file:

@import “_1_base/base";
@import “_2_helpers/helpers";
@import “_3_vendor/vendor";
@import “_4_redefine/redefine";
@import “_5_layout/layout";
@import “_6_pieces/pieces";
@import “_7_pages/pages";

This means all my SASS gets compiled into 1 large CSS file. If I do end up having multiple CSS files, it’s to account for IE specific styles.

All my partial files are prefixed with an underscore.


Naming Conventions

If you didn’t know, naming CSS stuff is really hard. Plenty of really smart people, people much smarter than me debate about these things. There seems to be two main camps: BEM and SMACCS.

BEM stands for block, element, modifier.

SMACSS stands for Scalable and Modular Architecture for CSS

A lot more alphabet soup to add to the equation!

When I started trying to figure out my guidelines, cssguidelin.es became a terrific resource. There’s a section there on BEM-like naming conventions.

The fastest way to describe it is nested elements have double underscores:


.social-media__icons {}

.social-media__text {}

You don’t want to repeat the DOM in your CSS, but you do want to make it easier to identify.

Modifiers or statuses have double dashes:

.social-media-—large {}

You can also tell from my example that multiple words are not camel cased, but rather have a single dash between each word.

NOTE:

SASS actually makes this type of naming really easy:

.social-media {
    &__icons {}
    &__text {}
    &—-large {}
}

Renders:

.social-media {}
.social-media__icons {}
.social-media__text {}
.social-media—-large {}

Extendable Classes

When I’m writing classes I know I want to extend, I’ll prepend the class name with a %.

%no-margin-padding {
     margin: 0;
     padding: 0;
}

There are several advantages here: (1) The class doesn’t actually get written unless it’s used. So, I’ve been able to create a small library of elements that are available to me in all my projects. (2) The % signifies it’s was meant to be extended and is being used in multiple places = don’t change it unless you want it to risk changing multiple elements across the board.


Classes vs IDs

I try to use classes instead of IDs. The main reason is because of specificity. You want your code to be as reusable as possible and all your ID elements should be unique.

If I’m using JavaScript to hook on to a particular element, I’ll add an addition class, prepended with js-. This lets me know later that JavaScript is using that particular tag, so don’t change it!


Naming Variables

All my colors are stored in variables:

$brown     : #847b6c;
$green     : #35b774;
$sky-blue    : #5ecbea;
$teal     : #3a6a77;

When I’m naming grays, instead of trying to remember the difference between $dark-gray, $darker-gray, and $darkest-gray, I name them by the first letter / number in their hex value: $gray-a, $gray-8, or $gray-c.

All my font names are stored as variables. If you’ve used fonts.com or Google Fonts, you’ll know sometimes it’s hard to remember the exact syntax for a font name. So, storing these values within a variable makes this a no-brainer.

I’ll try and abstract this even further by creating a _themes.scss file. I’ll write an extendable classes with a more generic name:

%body { font-family: $dagny; } %sans-serif { font-family: $brandon; text-transform: uppercase; } %serif { font-family: $adelle; }

Now, if a client wants to change the font, this becomes really easy. Instead of finding and replacing all my $dagny variables, I simply, change the typeface within my %body definition.

The same concept extends to colors:

$border-color : $gray-c;
$heading-color : $red;

When I’m defining the typography, I’ll write an extendable class and then include it:

%h1 {
    @extend %sans-serif;
    font-size: emCalc(72px); /* emCalc() is Foundation function */
}

h1 {
    @extend %h1;
}

Separating it out that way, helps me do things like this easily:

.page-title { @extend %h1; }


Tabs vs. Spaces

I know I will be judged here. It’s OK, go ahead pull out your stones.

I prefer tabs. I just like seeing the extra space.


CSS Rule Sets

  • I have one selector per line. The main reason is that it makes git commits far more meaningful. Plus, it means the display width of my scss file is not very wide. I can keep it in a second pane within Sublime without sacrificing to much of my screen.
  • 1 space before the opening curly bracket {
  • A line break after the opening curly brace
  • No space before the colon
  • 1 space after the colon
  • No space before the semi-colon
  • A line break after the semi colon. (this wasn’t always the case)
  • No space before the closing curly bracket }
  • Put the closing curly bracket on its own line
  • A line break after the closing curly bracket
  • Most properties have 1 blank line between them. But, if they’re not related, they’ll have 5 blank lines between.

SASSY things

I try to stick to the following order of properties:

  • @extend

    • @includes
    • Regular property values (in alphabetical order)
    • Pseudo element nesting
    • Regular element nesting
    • Media queries

I know the alphabetical order thing sounds dumb, but it really does help when you’re skimming for a specific property.


Nesting

I try not to nest. I’m not always great at it, though. SASS just makes it way too easy.


Comments

At the top of every file, I have a comment labeling the file:

/*------------------------------------*\

VARIABLES

/*------------------------------------*/

The # is supposed to make it easy to find within the project.


Sprites

I’ve finally moved to an SVG spriting system.

Let me describe a little bit of the history, here. I originally started with Compass. It worked great, but I was having to create multiple sprite sheets to account for retina, an icon might have multiple versions within one sheet to account for the various sizes, and on larger projects, it’d take a while to render out.

Then, I discovered icomoon. It was great because it handled a lot of the problems I found with Compass. I was able to resize icons on the fly, change colors on the fly, and it cut down on my render time. However, every time I wanted to make a change, I had to visit the icomoon site, upload the new icon, download the new files, and replace my existing files.

Then, once I got a setup for SVG sprites, all these things magically fell into place.

<Insert picture of the unicorn here> Just kidding.

Within my src / img / svg folder, I’ll save all my exported svgs. Then, gulp will handle the rest. Awesome!


Other Style Guides

I’ve compiled a short list of some of the other “style guides” I’ve read on the Internet:


Additional Resources

  • styleguides.io – This is a fantastic resource that compiles style guides and style guide information from all over the inter webs.
  • cssguidelin.es – I know I mentioned it earlier, but seriously, check out this site and take the time to read it. It definitely helped me.

sassy_pants

In the Comments

How do you structure your style sheets?