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
Hide 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. **REMEMBER** - If in doubt when deciding upon a style use existing, common patterns.
These guidelines strongly encourage the use of existing, common, sensible
patterns. They should be adapted as needed to create your own style guide.
This is a living document and new ideas are always welcome. Please
contribute.
## Table of contents ## 1. Whitespace
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.
* _Never_ mix spaces and tabs for indentation. * _Never_ mix spaces and tabs for indentation.
* Choose between soft indents (spaces) or real tabs. Stick to your choice * Use spaces for indenting and (4) space characters for each indentation level.
without fail. (Preference: spaces)
* If using spaces, choose the number of characters used per indentation level.
(Preference: 4 spaces)
Tip: configure your editor to "show invisibles" or to automatically remove Tip: configure your editor to "show invisibles" or to automatically remove end-of-line whitespace.
end-of-line whitespace.
Tip: use an [EditorConfig](http://editorconfig.org/) file (or equivalent) to 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.
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, ## 2. Comments
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.
Comment style should be simple and consistent within a single code base. 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. ...@@ -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. * Make liberal use of comments to break CSS code into discrete sections.
* Use "sentence case" comments and consistent text indentation. * Use "sentence case" comments and consistent text indentation.
Tip: configure your editor to provide you with shortcuts to output agreed-upon Tip: configure your editor to provide you with shortcuts to output agreed-upon comment patterns.
comment patterns.
Example: CSS Example:
```css ```css
/* ========================================================================== /* ==========================================================================
...@@ -99,13 +49,47 @@ Example: ...@@ -99,13 +49,47 @@ Example:
* @tag This is a tag named 'tag' * @tag This is a tag named 'tag'
* *
* TODO: This is a todo statement that describes an atomic task to be completed * 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 * at a later date. It wraps after 80 characters and following lines are
* indented by 2 spaces. * indented by 2 spaces.
*/ */
/* Basic comment */ /* 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> <a name="format"></a>
## 4. Format ## 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