LoginSignup
35
32

More than 5 years have passed since last update.

複数人でCompass+Scssでコーディングする時に決めておくと良いこと+注意点をまとめてみた

Last updated at Posted at 2015-12-06

CompassとScssでコーディングをするときに、当たり前のことですが、ある程度決め事を作っておかないと後で面倒なことになりますよね。
Sassが主流になってきたとはいえ、2015年ではまだ案件によってはCSSのみだったりと、導入されてない会社、導入しつつはあるけど社内で浸透していないケースも結構あると思います。
そんな時にコーディングする前に色々と決めておいたほうが後でメンテ楽だよ!的なことでまとめてみました。

複数人でコーディングするときのチェックリスト的な感じで使ってもらえると幸いです。

最初にチーム内で一読しておくと良いもの

CSS Styleguide

ほぼこれを守れば大丈夫!ってくらい細かくまとめられてます。
きっと参考にしている人も多いはず・・・!

脱カオスなCSSのために実践している7つの事

最初にも書かれていますが、現状は何かの設計思想をもとにガイドラインを作成、決め事を作るのがベストだと思います。
すべてを会社をルールにするのもアリだけど、属人的になるケースがほとんどなので...。

僕が普段使っているCSSのルールをコーディング規約にしてみた

できれば細かい箇所もガイドラインで決めていきたいですね。ここではあんまり書かないけど。。。

【CSS設計】拡張や修正に強いコンポーネントをマークアップする6つのテクニック

命名規則を作っていても細かい命名アイディアは迷うし、結構ここが属人的になりやすいポイントかと。
命名ルールはかなり細かく作るのも良いかもしれませんね。

ディレクトリ構造(Sass)

ディレクトリ構造に関しては、FLOCSS(フロックス)、もしくはSMACSS(スマックス)のどちらかの構造で設計すると良いと思います。

FLOCSS(フロックス)のディレクトリ構造

Foundation, Layout, Objectの3つのレイヤーから構成されるディレクトリ構造です。

参考:FLOCSS

├── foundation
│   ├── _base.scss
│   └── _reset.scss
├── layout
│   ├── _footer.scss
│   ├── _header.scss
│   ├── _main.scss
│   └── _sidebar.scss
└── object
    ├── component
    │   ├── _button.scss
    │   ├── _dialog.scss
    │   ├── _grid.scss
    │   └── _media.scss
    ├── project
    │   ├── _articles.scss
    │   ├── _comments.scss
    │   ├── _gallery.scss
    │   └── _profile.scss
    └── utility
        ├── _align.scss
        ├── _clearfix.scss
        ├── _margin.scss
        ├── _position.scss
        ├── _size.scss
        └── _text.scss

SMACSS(スマックス)のディレクトリ構造

変数やmixinはまとめて_settings.scss、もしくは_mixin.scssを作ってまとめて記述するようにします。
ほかはbase、layput、moduleと分ける形ですね。
SMACSSはルールを5つのカテゴリに分類しているので、下記を意識してディレクトリ構造を作ると良いと思います。

  • ベース      要素そのもののデフォルトスタイル
  • レイアウト    ページをエリアごとに分割
  • モジュール    再利用可能なパーツ
  • 状態(ステート) レイアウトやモジュールの特定の状態を示す
  • テーマ      サイトのルック&フィールを定義

参考:SMACSSを参考にしたCSSコーディング規約

├── README.md
├── _settings.scss
├── app.scss
├── base
│   ├── _reset.scss
│   ├── _main.scss
│   └── _util.scss
├── layout
│   ├── _header.scss
│   ├── _footer.scss
│   ├── _navbar.scss
│   └── _main.scss
│   └── _side.scss
└── module
    ├── _button.scss
    ├── _heading.scss
    ├── _chat.scss
    ├── _contacts.scss
    ├── _dropdown.scss
    ├── _modal.scss
    ├── _navbar.scss
    └── _signin.scss

FLOCSSとSMACSSの基本的な考え方はこのスライドが参考になります。

命名規則

命名規則はBEM、もしくはOOCSSの思想のどちらかに基づきます。
BEMかOOCSSは自分がどっちに向いているのかわからない時は下記のチェックリストを参考にしてみても良いと思います。

BEM派かOOCSS派か、チェックリストを作ってみた

Sassで使う変数でも命名規則は決めておく必要がありますが、個人的にはハイフンつなぎでなく、キャメルケースでも良いかとは思います。

コンパイル方法

ものすごーく当たり前のことですが、gruntやgulpなどのビルドツールを使うのか、SassのコンパイルのGUIツールでサクッとやるのかはチーム内で共通化しておいたほうが良いですね。
会社の方針として持っておいても良いかも。

記述方法について

Compass+Sassについて、もう少し細かい箇所を。

略語

略語を使うなら略語辞典をチーム内で共有し、それを参照します。
また、略語を使わないケースでも造語は使わないようにします。

/* OK */
.modal {
    position: fixed;
    width: 100%;
    height: 100%;
}

/* NG */
.modalwrap {
    position: fixed;
    width: 100%;
    height: 100%;
}

コメントアウト

FLOCSSの場合は既にサンプルがあるので、それを参考に記述すれば問題ないと思います。
もしくはこんな感じでコメント方式をチーム内で統一しておけば問題ないと思います。
目次もコードに記載するかどうかも決めておいたほうが良いです。

/* ==================================================
   Layout
   ================================================== */

/* Block
   -------------------------------------------------- */

/**
 * Element
 */

また、コメントアウトで日本語を使用する時はコンパイル時に表示されない//で記述を。

//ボタンのmixin
@mixin button {
    display: block;
    text-decoration: none;
}

プロパティの記述順序

プロパティの順番は一応下記の3つくらいの決め方があるとは思いますが、チーム内のパフォーマンスも考えて決めてしまっても良いと思います。

//ボックス、位置情報、サイズなど機能ごとに記述
.foo {
    display: block;
    position: absolute;
    right: 0;
    bottom: 0;
    width: 100%;
    margin: 0;
    padding: 0;
    font-size: 0.75em;
    color: #000;
    background-color: #fff;
}

//abc順に記述
.foo {
    background-color: #fff;
    bottom: 0;
    color: #000;
    display: block;
    font-size: 0.75em;
    margin: 0;
    padding: 0;
    position: absolute;
    right: 0;
    width: 100%;
}

//特に気にしない
.foo {
    background-color: #fff;
    display: block;
    font-size: 0.75em;
    color: #000;
    position: absolute;
    bottom: 0;
    right: 0;
    width: 100%;
    margin: 0;
    padding: 0;
}

ただし、下記に関してはあらかじめ決めておいたほうが良いです。

ローカル変数

普通に最初に書くのが一般的だと思うけど、念のため。
因みにグローバルは!defaultはつけておいたほうが良いかと思います。

.item {
    $padding: 1em;
    width: 50%;
    padding-right: $padding;
    padding-left: $padding;
}

@extend@mixin

先に書く派と最後に書く派がいるので、これも統一の必要があります。

.item {
    @extend .box;
    @include clearfix;
    padding: 8px;
}

@contentを使用している@mixin

@contentはメディアクエリで使用されるケースが多いので、1番最後が適切かとは思います。

@mixin tablet($max-width:1024px) {
    @media only screen and(max-width: $max-width){
        @content;
    }
}
.sidebar {
    width: 240px;
    float: right;
    @include tablet {
        width: 100%;
        float: none;
    }
}

ベンダープレフィックス

ベンダープレフィックスはAutoprefixerを使用。

Autoprefixer

フォントサイズの指定

cssのガイドラインでもパーセント指定なのか、rem指定なのかとかあるけど、フォントサイズの指定方法も指定してお居たほうが良いですよね。

//rem指定
@mixin font-size($size) {
    font-size: $size + px;
    font-size: ($size / 10) * 1rem;
}
html {
    font-size: 62.5%;
}
body {
    @include font-size(13);
}

//変数で指定
$font-size-small: 12px !default;
$font-size-medium: 14px !default;
$font-size-large: 18px !default;

body {
    font-size: $font-size-medium;
}

メディアクエリ

メディアクエリを記述する場合、下記の2点に注意する

メディアクエリを記述する位置

大きく分けると以下の3つの方法があると思います。
初回にどう指定するかはチーム内で統一できるよう話をしておいたほうが良いと思います。

  1. そもそもデバイスごと読み込むCSSを分けるようにする
  2. scssのファイルごと完結するように記述する。(例:_header.scssにはスマホとPCのヘッダーの記述をする)
  3. BlockごとやElementごとなど、1つの塊ごと指定していく

メディアクエリを記述する方法

色々あるけど、ネストするか、Foundationみたく定義するのか。

//ネストで指定
.item {
    display: inline-block;
    @media (min-width: 768px) {
        display: block;
    }
}

//定義する
@media #{$small-up} {...}
@media #{$small-only} {...}

@media #{$medium-up} {...}
@media #{$medium-only} {...}

@media #{$large-up} {...}
@media #{$large-only} {...}

ネスト

あんまりネストし過ぎると後でメンテしづらい上に見づらいので、
BEMならElementでひと固まり、OOCSSならストラクチャごと、擬似要素などの擬似的なものだけ、など決めておく。

//エレメントやストラクチャでネスト
.button {
    display: block;
    &-active {
        background: #f00;
    }

}

//擬似要素、擬似クラス、メディアクエリでネスト
.button {
    display: block;
    &:hover,
    &:focus {
        background: #f00;
    }
    @media (min-width: 768px) {
        ...
    }
}

extendについて

extendは複雑になるから使用しないようにしているケースが多いので、
使うか使わないかを決めておいても良いかと思います。

コーディング後のデータについて

Compass+Sassが使える人と使えない人(クライアントとか)がソースの編集を行うとき、どうするかも決めておいたほうが後でトラブルにならないかと思います。

35
32
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
35
32