Remove optional phrasing from README

When stating preferred practices, we should always state them in terms
of the default. Users can investigate if they want to configure the
lint check.

Change-Id: I42d77586608eb8bcbf9e665b51fa4d28167c9254
Reviewed-on: https://gerrit.causes.com/32824
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add StringQuotes linter

Add linter which enforces single or double quotes depending on the
user's configuration.

This also introduces the `source_from_range` helper, which extracts the
original source code given a `Sass::Source::Range` object.

Closes #72

Change-Id: I61a86e28c2ad8b3ee498b64e9db4447fbae911e3
Reviewed-on: https://gerrit.causes.com/32823
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add UrlQuotes linter

Add linter which checks for literal URLs (i.e. URLs which are not
contained within quotes). This is a bizarre feature of CSS that doesn't
seem to offer much convenience and instead introduces inconsistency by
attempting to treat URLs as first-class entities.

Change-Id: I171d3e0fad3e37cc281206cddfe51ac158ff5e3b
Reviewed-on: https://gerrit.causes.com/32825
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Tony Wooster <tony.wooster@causes.com>
Fix source_from_range crash on invalid source range

There is a case where the Sass parser reports the end of a source range
on a non-existent line. One such example is the code below, which has no
trailing semicolon:

    @import 'file'

Add a check to the `source_from_range` method to gracefully handle this
edge case. I'm refraining from doing a blanket check for _any_ invalid
source range as I want to know the actual cases when this happens.

Change-Id: I300f3847bb77ed22eac21e89480d863aece2f75c
Reviewed-on: https://gerrit.causes.com/32914
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Upgrade RSpec from 2.13.0 -> 2.14.1

In the process, silence a deprecation warning by renaming a use of
`stub!` to `stub`.

Change-Id: Ice7ed367967976a2f572c56f7a58a64e5102f023
Reviewed-on: https://gerrit.causes.com/33013
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Upgrade colorize from 0.5.8 -> 0.6.0

Change-Id: I551004935a99e84ccdf27a02067bdd3eec75c778
Reviewed-on: https://gerrit.causes.com/33014
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add .bundle directory to .gitignore

Change-Id: Ic337793bb70d41c8371782d57ce29aa26d7d0b72
Reviewed-on: https://gerrit.causes.com/33015
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Fix error when using `@keyframe`s

When using a `@keyframe`, the SelectorDepth linter would run into the
following error:

    Failure/Error: Unable to find matching line from backtrace
    NoMethodError:
      undefined method `rest' for ["0%", ""]:Array

This happens because the Sass Selector Sequence members may be,
SimpleSequence objects, Strings, or Arrays[1], but some code in the
SelectorDept linter was written with the assumption that the members may
be only either SimpleSequence objects or Strings but not Arrays.

Unfortunately, the documentation isn't very clear on when these members
may be Arrays, but it appears to happen for `@keyframe` percentages.
Since this is the first time we have run into this problem, we are
simply skipping over these Arrays because selector depth does not apply
when in a `@keyframe`.

Fixes #74

[1]: http://sass-lang.com/documentation/Sass/Selector/Sequence.html#members-instance_method

Change-Id: I549677d179335fddebb395085d70dea75b897130
Reviewed-on: https://gerrit.causes.com/33038
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Joe Lencioni <joe.lencioni@causes.com>
Cut version 0.17.0

Change-Id: I89e9b8827eb3a8dba4a54c112485e09addb30515
Reviewed-on: https://gerrit.causes.com/33086
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Downgrade colorize from 0.6.0 -> 0.5.8

This dependency was upgraded in 431ce29 with the thought that there were
no breaking changes.

It turns out that it actually removed the automatic disabling of
colorization when the terminal was not a TTY. This resulted in
`scss-lint` printing color escape sequences even when it was being
output to a file.

This is obviously not ideal. Since there are no significant reasons to
upgrade to 0.6.0, downgrade back down to 0.5.8.

Change-Id: If92d7b9ae9c3a11697c1ae833ddc31cfcc328e62
Reviewed-on: https://gerrit.causes.com/33122
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Cut version 0.17.1

Change-Id: I1de004ec4c075b91b9166c6983c9ccf2a9092c2b
Reviewed-on: https://gerrit.causes.com/33123
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Updating README with Linter references

This will make it easier for developers to figure out which linter name
they need to specify to disable/customize a check.

In the process, alphabetize the list and add some additional examples.

Change-Id: I2e9b6e6421c0a31eeff8adf6e458124fdcfce482
Reviewed-on: https://gerrit.causes.com/33621
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Reword intro to linter section in README

Now that `scss-lint` is more customizable, the wording of this section
was misleadingly suggestive that `scss-lint` was still opinionated.

Change the wording to say that the defaults are opinionated.

Change-Id: I28ea02b17361f5fc7bb3375862fc7eb69bf565a3
Reviewed-on: https://gerrit.causes.com/33622
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Change indentation of linter descriptions

Now that each linter has a heading, they no longer need to be indented
as bullet points.

Change-Id: I493e5cebeefb45f3ac736277c70852792ef2b5bf
Reviewed-on: https://gerrit.causes.com/33623
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add additional explanations to README

Add some more explanations to the reasoning sections of various linters.
This will hopefully help better justify their existence to developers.

Also replaced some occurrences of "TBC" in the README with actual
content.

Change-Id: I2112c4dce69b3753f157df505d1f5b98f0991592
Reviewed-on: https://gerrit.causes.com/33624
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Modify examples in README

Change examples to have "Bad" and "Good" headings instead of inline
comments, and split each example into its own code block.

Also removed an extra `HexFormat` section which snuck in.

Change-Id: I53fd6d3b7e68f08400251a9e8fb82911843f8bc9
Reviewed-on: https://gerrit.causes.com/33669
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Correctly order linters in README

Some of the linters were out of order. Reorder them into their proper
positions.

Change-Id: I0eff039464e1f70374741b3722c9098b802a1859
Reviewed-on: https://gerrit.causes.com/33670
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Combine DeclaredName and UsageName linters

It was mentioned in #75 that there was some confusion around when
`DeclaredName` would report a lint versus `UsageName`. Since these
checks go hand-in-hand, combine them.

Change-Id: Ic5574aeb1a7349ffdeafd0a4b865704126437e08
Reviewed-on: https://gerrit.causes.com/33671
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Move Compass linters into separate README

The Compass linters (well, currently just linter) deserve a section of
there own so as to not overcrowd the main README. Instead, we link from
the main README to the individual one for Compass.

Change-Id: I6264e5f8b5e422fecc0c113a973691c870aafc2e
Reviewed-on: https://gerrit.causes.com/33672
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add configuration options to README

In order to make it clearer to users that `scss-lint` is customizable,
include the configuration options in the README.

Change-Id: Id48ea992ed2a7e04772239c9b7eb30b1b16b979e
Reviewed-on: https://gerrit.causes.com/33673
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>