Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • D digitec-wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Digitec
  • digitec-wiki
  • Wiki
  • css and sass coding standards

css and sass coding standards · Changes

Page history
mmclin created page: css-and-sass-coding-standards authored Dec 11, 2013 by Mike McLin's avatar Mike McLin
Show whitespace changes
Inline Side-by-side
css-and-sass-coding-standards.markdown
View page @ 32086ac7
# Principles of writing consistent, idiomatic CSS
# CSS + Sass
The following document outlines a reasonable style guide for CSS development.
These guidelines strongly encourage the use of existing, common, sensible
patterns. They should be adapted as needed to create your own style guide.
**REMEMBER** - If in doubt when deciding upon a style use existing, common patterns.
This is a living document and new ideas are always welcome. Please
contribute.
## Table of contents
1. [General principles](#general-principles)
2. [Whitespace](#whitespace)
3. [Comments](#comments)
4. [Format](#format)
5. [Practical example](#example)
[Acknowledgements](#acknowledgements)
[License](#license)
<a name="general-principles"></a>
## 1. General principles
> "Part of being a good steward to a successful project is realizing that
> writing code for yourself is a Bad Idea™. If thousands of people are using
> your code, then write your code for maximum clarity, not your personal
> preference of how to get clever within the spec." - Idan Gazit
* Don't try to prematurely optimize your code; keep it readable and
understandable.
* All code in any code-base should look like a single person typed it, even
when many people are contributing to it.
* Strictly enforce the agreed-upon style.
* If in doubt when deciding upon a style use existing, common patterns.
<a name="whitespace"></a>
## 2. Whitespace
Only one style should exist across the entire source of your code-base. Always
be consistent in your use of whitespace. Use whitespace to improve
readability.
## 1. Whitespace
* _Never_ mix spaces and tabs for indentation.
* Choose between soft indents (spaces) or real tabs. Stick to your choice
without fail. (Preference: spaces)
* If using spaces, choose the number of characters used per indentation level.
(Preference: 4 spaces)
* Use spaces for indenting and (4) space characters for each indentation level.
Tip: configure your editor to "show invisibles" or to automatically remove
end-of-line whitespace.
Tip: configure your editor to "show invisibles" or to automatically remove end-of-line whitespace.
Tip: use an [EditorConfig](http://editorconfig.org/) file (or equivalent) to
help maintain the basic whitespace conventions that have been agreed for your
code-base.
Tip: use an [EditorConfig](http://editorconfig.org/) file (or equivalent) to help maintain the basic whitespace conventions that have been agreed for your code-base.
<a name="comments"></a>
## 3. Comments
Well commented code is extremely important. Take time to describe components,
how they work, their limitations, and the way they are constructed. Don't leave
others in the team guessing as to the purpose of uncommon or non-obvious
code.
## 2. Comments
Comment style should be simple and consistent within a single code base.
......@@ -73,10 +24,9 @@ Comment style should be simple and consistent within a single code base.
* Make liberal use of comments to break CSS code into discrete sections.
* Use "sentence case" comments and consistent text indentation.
Tip: configure your editor to provide you with shortcuts to output agreed-upon
comment patterns.
Tip: configure your editor to provide you with shortcuts to output agreed-upon comment patterns.
Example:
CSS Example:
```css
/* ==========================================================================
......@@ -106,6 +56,40 @@ Example:
/* Basic comment */
```
For Sass, double-slash comments should be used instead
Sass Example:
```css
// ==========================================================================
// Section comment block
// ==========================================================================
// Sub-section comment block
// ==========================================================================
// Short description using Doxygen-style comment format
//
// The first sentence of the long description starts here and continues on this
// line for a while finally concluding here at the end of this paragraph.
//
// The long description is ideal for more detailed explanations and
// documentation. It can include example HTML, URLs, or any other information
// that is deemed necessary or useful.
//
// @tag This is a tag named 'tag'
//
// TODO: This is a todo statement that describes an atomic task to be completed
// at a later date. It wraps after 80 characters and following lines are
// indented by 2 spaces.
// Basic comment
```
<a name="format"></a>
## 4. Format
......
Clone repository
  • alpha beta testing
  • browser testing
  • camtasia licenses
  • code delivery processes
  • coding practices
  • css and sass coding standards
  • database schema standards
  • dependency management
  • development environments
  • digitec agile process
  • digitec gitlab styles
  • digitec software promises
  • digitec spec process
  • gitlab administration
  • gitlab issues tags
View All Pages