Coding Conventions and Guidelines

Coding conventions:

  • We use the BEM approach to write css.
  • Every css class must be prefixed with dc-.

Sass conventions:

  • All variables and mixins must be prefixed with dc- and must use the hyphen-case (with hyphens as separators).
  • To mark a function/variable/mixins/placeholder/selector as private, its name should start with one underscore. _dc-*


Future compatibility

Each atom/molecules/module is prepared to be independently loaded, by requiring its own dependencies. So you will notice at the top of each file a commented import directive, something like this:

// @import "../core/core";

@mixin dc-checkbox($sibling-label-selector : ".dc-label") {
    // ...

We hope that sass 4 brings us a new cool import directive that works as the less one (import once by default). We are not the only one requesting that feature


Contributing to Dress Code

Git workflow

The git workflow that we use to contribute is mostly based and well explained in this article: a-successful-git-branching-model

Main branches:

  • master : the default branch. Never work on it directly, always merge topic branches and hotfix branches into this branch.
  • topic/[topic-name]: for every new feature or task, open a topic branch from master and work on it, when you are done open a pull request and ask for review.
  • hotfix/[hotifx-name]: used to fix stable versions
  • release/[release-name]: used to work on release candidates

If a github issue is related to a branch we suggest to append the number at the end of the branch name.
example: topic/dropdown-refactor-98

Git Commit Guidelines

We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. It is important to note that we use the git commit messages to generate the Dress Code Changelog document.

A detailed explanation of guidelines and conventions can be found in this document.

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>

Any line of the commit message cannot be longer 100 characters!
This allows the message to be easier to read on github as well as in various git tools.


Must be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation


The scope could be anything specifying the place of the commit change.


The subject contains succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize first letter
  • no dot (.) at the end


Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes" The body should include the motivation for the change and contrast this with previous behavior.


The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes are intended to highlight (in the ChangeLog) changes that will require community users to modify their code with this commit.

Sample Commit message:

refactor(button): prefix btn class with dc-

    BREAKING CHANGE: btn class now is prefixed with dc namespace.

    Change your code from this:

    <button class="btn">submit</button>

    To this:

    <button class="dc-btn">submit</button>



Step by step instructions to release a new version of the dress-code.

  1. Pull latest from the master branch and run the following command. Ensure that you follow the semver specification.

    git checkout master
    git pull
    npm run release [ major | minor | patch | <newversion> ]
  2. A release branch will be created and pushed automatically with a generated changelog. Confirm the changelog is accurate and clear. Feel free the manually edit the changelog in the release branch.

  3. Open a PR from the release branch to master.

  4. After the PR is merged, publish to npm. This will output the newly published version for verification, create and push the tag and deploy the demo.

    git checkout master
    git pull
    npm publish