jarvus-style-guide.css

css {
    should-look: like-this;
    /* one space after the selector */
    /* opening brace on the same line */
    /* 4-space indent */
    /* closing brace on its own line */
    /* one blank line between rules */
}

.one-liners { can-look: like-this; } /* but only do this if the rule has only one property and it's unlikely to gain more */

grouped,
selectors {
    go: 'on separate lines'; /* single quotes around strings in CSS and JS, double quotes for HTML attributes */
}

colors {
    use: #b4d455; /* lowercase alpha digits */
    use: #cdc;    /* three-digit hex if it's available */
    use: white;   /* keyword if it's common */
}

sort {
    all: properties;
    in: alphabetical;
    order: for-sanity;
}

div {
    /* always use the shortest notation possible for box-model lengths */
    /* remember that bottom will copy top and left will copy right, unless otherwise indicated */
    /* also, leave units off zero values */
    border-radius: 2px;           /* not 2px 2px 2px 2px */
    border-width: 1px 0;          /* not 1px 0px 1px 0px */
    margin: 10px 20px 30px;       /* not 10px 20px 30px 20px; */
    padding: 10px 20px 30px 40px; /* write out all four only if necessary */
}

div {       
    /* sometimes it's more readable to declare an all-around value and then "tweak" it */
    /* this makes the outlier stand out better */
    padding: 10px;
    padding-right: 0;
    /* not padding: 10px 0 10px 10px */
    /* but this is not a hard and fast rule */
}

In terms of “always use the shortest notation possible for box-model lengths” I would clarify that you shouldn’t use the shorthand only to avoid an extra lines. You should still only target what you want to change.

I also have a few somewhat higher level suggestions that might be outside the scope of this document and might not be something you run into when using frameworks, but should probably be formalized/discussed somewhere:

• Don’t use IDs as CSS hooks, mostly because their high specificity is a pain in the ass.
• Avoid using generic selectors (div, section, footer, h1, ul, etc.) in CSS, particularly for elements that can contain flow content, unless you explicitly want to set up a generic, site-wide selectors. There is definitely some leeway here, but you generally should create class names instead in order to avoid inheriting properties that you would need to overwrite, and to avoid having to endlessly SASS nest or put parent selectors in front of your target. This avoids unnecessary specificity and also allows you apply styles independent of markup.
• Indent selectors based on their parent/child relationships in HTML (this was discussed somewhat on Slack). To reiterate, I support doing this, regardless of SASS/raw CSS, because I find it helps make the SASS/CSS more understandable and helps prevent adding unnecessary specificity for the purposes of readability.
• I am a big proponent of BEM for naming classes. It can result in long, hideous selectors, but it makes the structure of things extremely clear, promotes creating sensible cascades, alleviates some of the burden of coming up with selector names, and can also help prevent the temptation to add unnecessary specificity.
• And this sort of straddles CSS/JS and doesn't apply when using a framework, but when building from scratch or for more traditional sites I suggest creating separate class names to use as hooks for CSS and JS. Prefix the js hook with js-, even if you end up keeping the same suffix. That way you can apply styles and behavior independently and you’re more free to change things without breaking one or the other.

Another one:

• Avoid using shorthand for things like background, where there are a bunch of values that you might be inadvertently overwriting by omission. Use the individual properties instead to avoid cascade weirdness.