CSS is not a pretty language. While it is simple to get started with, it soon becomes problematic at any reasonable scale. There isn’t much we can do to change how CSS works, but we can make changes to the way we author and structure it. In working on large, long-running projects, with dozens of developers of differing specialities and abilities, it is important that we all work in a unified way in order to keep stylesheet maintainable, scalable, and to keep code transparent, sane and readable as well.

MySolidWorks site was initially built up with Boostrap 2 using the LESS CSS Preprocessor. CSS preprocessing is a method of extending the feature set of CSS by first writting the style sheets in a new extended language, then compiling the code to vanillar CSS so that it can be read by Web browsers. LESS is one of most notable of several CSS preprocessors like SASS.

LESS was designed to be as close to CSS as possible, so the syntax is indentical to the current CSS code, and can be used right away with the existing code in dev. SASS was designed to both simplify and extend CSS, so things like curly braces were removed from syntax. But SASS also introduced a CSS-like syntax called SCSS (Sassy CSS) to migrating easier. Bootstrap 3 still uses LESS for styling, but also provides an official SASS port to SASS/SCSS.

Now we are upgrading the framework from bootstrap 2 to 3, and also moving from LESS to SCSS in consideration of getting ready for furhter framework upgrade, since Bootstrap 4 will say goodbye to LESS.

We learn that all common CSS methodologies are trying to separate content from structure by placing styles in reusable modular blocks of code. Among them, the OOCSS Framework is an methodology similar to Bootstrap Framework CSS for its rules of classing, subclassing and naming convention. This can be an appraoch to derive a standard of writing our CSS.

Although separating frond-end from back-end is an ideal technique to develop web projects, MySolidWorks was not built in that way. Every developer has chance to touch CSS, creat new classes, edit and modify them at will without guidelines. Along with our website grows, our CSS gets messier. There is obviously a need for a better system and standard of writing CSS so as to keep code maintainable, easy to read and standard-based. Having good coding guidelines, when well followed, will:

• set the standard for code quality across a codebase;
• promote consistency across codebases;
• give developers a feeling of familiarity across codebases;
• increase productivity.

One of the simplest forms of guidelines is a set of rules regarding syntax and formatting. Having a standard way of writing (literally writing) CSS means that code will always look and feel familiar to all members of the team.

Further, code that looks clean feels clean. It is a much nicer environment to work in, and prompts other team members to maintain the standard of cleanliness that they found. Ugly code sets a bad precedent.

Basic Syntax

• Use soft-tabs with fixed space indent. Spaces are the only way to guarantee code renders the same in each developer's environment.
• If writing pure CSS or using CSS compatible SCSS syntax, always put spaces after : in property declarations and before { in rule declarations - this makes code easier to read. SASS syntax enforces you to place space after each semicolon.
Good

homepage-banner {
margin-top: 20px;
}
Bad
homepage-banner{
margin-top:20px;
}
• End all declarations with a semi-colon (for CSS and SCSS). Despite that fact that the last declaration's is optional, it is better to put semi-colon at the end of each line.
  Good
  

  homepage-banner {
  margin-top: 20px;
  color: #fff;
  }

  Bad

  homepage-banner{
  margin-top:20px;
  color:#fff
  }
• Each CSS declaration should appear on its own line. Do not place whole ruleset on a single line, minifier will do that for you. Multiline blocks are easier to read and understand.
  Good
  

  homepage-banner {
  margin-top: 20px;
  color: #fff;
  font-size: 22px;
  }

  Bad

  homepage-banner{
  margin-top:20px; color:#fff; font-size:22px
  }
  
  
  
• Comma-separated property values like multiple background or multiple box-shadows should include a space after each comma. But do not include spaces after commas in rgb(), hsl(), or deg() values.
• Don't use color name white or blue to define color, use all hex values in lowercase. #fff instead of #FFF. And use shorthand hex values where possible #fff instead of #ffffff. Remember that you can shorten hexes like #aabbcc to #abc
• You can drop leading zero for opacity in color parameters (e.g. rgba(0,0,0,.4)) and transition durations (e.g. margin .5s linear)
• Use shorthand notations for margin, padding, font, background and border where available (margin: 5px 10px; instead of margin: 5px 10px 5px 10px;). And avoid specifying units for zero values (margin: 0; instead of margin: 0px;
• Quote attribute values in selectors with double quotes (e.g. input[type="text"]). Even though they are optional in some cases, it is a good practice to use them for consistency.

Naming Covention for Class Selectors

• For styling purposes, use classes only as CSS selectors. Using tag names as CSS selectors is a bad idea unless you want to specify initial styling of specific tag (e.g. typography rules for text and headings). Using tag names even if they are name spaced by a class name can lead to collisions and applying unwanted tag styles that were defined elsewhere in stylesheets.
Good

.navigation .item {
...
}
Bad
navigation li a {
...
}
• Always keep class names lowercase and use single dash between words. This look natural, it is easy to read and this is pretty common and nice CSS convention whilst camelCase is more JavaScript style and underscore_case is used in Ruby. A mix of couple of this styles in the stylesheets is a worst crime against consistency.
Good

homepage-banner {
...
}





Bad
homepageBanner {
...
}

homepage_Banner {
...
}
• Keep classes as short as possible, but use only meaningful names. Don't need to be so verbose to define class like .navigation-top-bar-stripped instead of simple .navigation-top. But do not shorten it to .nav or even .n because it might not have sense for other developers working with you and will not have sense for you after sometime.
• Keep classes as short as possible, but use only meaningful names. No need to be too verbose to define class like .navigation-top-bar-stripped instead of simple .navigation-top. But do not shorten it to .nav or even .n, because it might not have sense for other developers working with you.
• Avoid presentation or location specific words in the name, like blue, text-gray, or side-block.
• Names should be lowercase, using a dash - as a separator in a multi-word class names. It's clear, readable and distinguish CSS from underscore case and camel case naming.
• Use full descriptive words. Abbreviating a word may save you a few milliseconds to type initially, but may make your code harder to read, costing you more time down the road. Being consistent in this will save you the time spent thinking how exactly you abbreviated a word couple of months ago.
• Use nouns for naming objects and modules.
• When it comes to naming modifiers and states, use adjectives as they are describing type or state of an object.