SASSではなく、SCSSの記法を使うSASSの記法(HAMLっぽいやつ)は使わず、SCSS(よりCSSっぽい記法)のほうを使います。単純に学習コストが低いことと、JSライブラリ付属のCSSやネットで公開されているコードなどを取り込む時もコピペでとり込んだりしやすいからです。color:green;}```ID指定でスタイルを書くことはしません。全てクラスで指定します。specificity)が高すぎて、他の場所でカスケードしてスタイルを上書きしようとした時`!important`を多発しなくてはいけなくなったり、あれこれと障害になるためです。color:red;}```タグ名でスタイル指定はせず、面倒でも全部クラスを割り振ります。タグの構造は制作していく途中や、JSとの兼ね合いで変えることがよくあるので、その際に書き換える手間を減らし、HTML構造とCSSによるスタイリングを極力分離しておくためです。例外として、たとえばMarkdownパーサが出力するHTMLなど、クラスの割り当てられない部分で、かつタグにスタイルを指定するのが妥当な部分は除きます。color:red;}```大文字小文字を両方使って書く前提にすると、必ず大文字小文字のタイプミスでスタイルが当たらなくてうんうん悩む時間が発生するので、基本的に大文字は一切使いません。例外として、Angularアプリを書いていてdirective名とCSSの接頭辞を合わせたい、などの理由で接頭辞部分(一番先頭の部分)に限り、camelCaseを使ったりするのはアリです。同一ファイル内にある、同じ接頭辞のクラスのみネストして上書きできます。それ以外のネストは基本的に禁止です。クラス名の接頭辞と、そのクラスの書かれたファイル名を一致させるどのクラスがどのファイルに書かれているか、が瞬時にわかるようになります。sourcemapなどに頼る必要が発生したら負けです。`_mode.scss`(あるいは_mode-hoge.scss)は後述のJavascriptとの連携に関わる予約語的なものなので、作成禁止です。JSから使うクラスは「.x-」で始め、CSS側でそのクラスは絶対に使わないJSで使っているクラスなので変更に注意が必要、ということを明示するために特別なクラスを指定します。JSでのDOM操作と、CSSでのスタイル指定はできるかぎり切り離しておいたほうがよいので、「.x-」のついたクラスに対してスタイルを当てることは絶対にしないようにします。後述の「.mode-」のついたクラスでコントロールします。JSで使うIDは「x」で始めたcamelCaseとし、CSS側でそのIDは絶対に使わないjsでのDOM操作のためにIDを割り当てる場合は`id="xSomeElement"`というようにxから始まるcamelCaseで指定します。JSとCSSで連携する場合は`.mode-`というクラスを通して行う要素のアニメーションなどはできる限りCSSのtransitionやanimationで行います。SASSの変数名はスネークケースで書くハイフンは使わず、`$some_sass_vars`といったような、アンダースコア区切り+小文字のスネークケースで変数を定義します。クラス名と区別をつけやすくすることと、SASSだと「-」が演算子としても機能するので、それとの区別をつけて意図しない演算などを防ぐためです。SASSの変数名も、ファイル名と一致させる変数名は、ファイル名と同じ接頭辞で始めます。別に`$vars_`とかでもいいんだけどね。レスポンシブ対応はmixinで行うここはまだ練ってるところ今のところ以下のようなコードでやってます。`@extend`は出来る限り避ける`@extend`は、extend元のスタイルを変更した時に影響する範囲が見えず、意図しない部分に影響が出たりするのでできる限り避けます。extendsしたいようなクラスは`.g-`のクラスとして定義して、ネストさせるのを推奨です。`@extend`を活用したSASSライブラリなどを使う場合は除きます。一つのモジュールのつもりで書いていたものの中のパーツをモジュールとして切り出したくなるとかいった変更をしたくなった時にストレスといった理由で採用していません。SASSではなく、SCSSの記法を使うSASSの記法(HAMLっぽいやつ)は使わず、SCSS(よりCSSっぽい記法)のほうを使います。単純に学習コストが低いことと、JSライブラリ付属のCSSやネットで公開されているコードなどを取り込む時もコピペでとり込んだりしやすいからです。color:green;}GOODID指定でスタイルを書くことはしません。全てクラスで指定します。specificity)が高すぎて、他の場所でカスケードしてスタイルを上書きしようとした時!importantを多発しなくてはいけなくなったり、あれこれと障害になるためです。color:red;}GOODタグ名でスタイル指定はせず、面倒でも全部クラスを割り振ります。タグの構造は制作していく途中や、JSとの兼ね合いで変えることがよくあるので、その際に書き換える手間を減らし、HTML構造とCSSによるスタイリングを極力分離しておくためです。例外として、たとえばMarkdownパーサが出力するHTMLなど、クラスの割り当てられない部分で、かつタグにスタイルを指定するのが妥当な部分は除きます。color:red;}GOOD大文字小文字を両方使って書く前提にすると、必ず大文字小文字のタイプミスでスタイルが当たらなくてうんうん悩む時間が発生するので、基本的に大文字は一切使いません。例外として、Angularアプリを書いていてdirective名とCSSの接頭辞を合わせたい、などの理由で接頭辞部分(一番先頭の部分)に限り、camelCaseを使ったりするのはアリです。同一ファイル内にある、同じ接頭辞のクラスのみネストして上書きできます。それ以外のネストは基本的に禁止です。クラス名の接頭辞と、そのクラスの書かれたファイル名を一致させるどのクラスがどのファイルに書かれているか、が瞬時にわかるようになります。sourcemapなどに頼る必要が発生したら負けです。_x.scss(あるいは_x-hoge.scss)_mode.scss(あるいは_mode-hoge.scss)は後述のJavascriptとの連携に関わる予約語的なものなので、作成禁止です。JSから使うクラスは「.x-」で始め、CSS側でそのクラスは絶対に使わないJSで使っているクラスなので変更に注意が必要、ということを明示するために特別なクラスを指定します。JSでのDOM操作と、CSSでのスタイル指定はできるかぎり切り離しておいたほうがよいので、「.x-」のついたクラスに対してスタイルを当てることは絶対にしないようにします。後述の「.mode-」のついたクラスでコントロールします。JSで使うIDは「x」で始めたcamelCaseとし、CSS側でそのIDは絶対に使わないjsでのDOM操作のためにIDを割り当てる場合はid="xSomeElement"というようにxから始まるcamelCaseで指定します。JSとCSSで連携する場合は.mode-というクラスを通して行う要素のアニメーションなどはできる限りCSSのtransitionやanimationで行います。SASSの変数名はスネークケースで書くハイフンは使わず、$some_sass_varsといったような、アンダースコア区切り+小文字のスネークケースで変数を定義します。クラス名と区別をつけやすくすることと、SASSだと「-」が演算子としても機能するので、それとの区別をつけて意図しない演算などを防ぐためです。SASSの変数名も、ファイル名と一致させる変数名は、ファイル名と同じ接頭辞で始めます。別に$vars_とかでもいいんだけどね。レスポンシブ対応はmixinで行うここはまだ練ってるところ今のところ以下のようなコードでやってます。@extendは出来る限り避ける@extendは、extend元のスタイルを変更した時に影響する範囲が見えず、意図しない部分に影響が出たりするのでできる限り避けます。同じスタイルならできるだけ同じクラス名を割り振る似たスタイルならクラスを複数振って上書きして調整するextendsしたいようなクラスは.g-のクラスとして定義して、ネストさせるのを推奨です。@extendを活用したSASSライブラリなどを使う場合は除きます。その他BEMなどを使わない理由BEMは、画面設計がしっかりできていて、CSSの設計に時間がかけられる場合はよいですが、だいたい自分の作るようなものは日々変化の多いものなので、ルールとしてやや複雑すぎるっていうかどれがBlockでどれがElementでどれがModifierだとかあれこれ余計な事を考えたくない一つのモジュールのつもりで書いていたものの中のパーツをモジュールとして切り出したくなるとかいった変更をしたくなった時にストレスといった理由で採用していません。SASSの記法(HAMLっぽいやつ)は使わず、SCSS(よりCSSっぽい記法)のほうを使います。JSライブラリ付属のCSSやネットで公開されているコードなどを取り込む時もコピペでとり込んだりしやすいからです。ID指定でスタイルを書くことはしません。全てクラスで指定します。specificity)が高すぎて、他の場所でカスケードしてスタイルを上書きしようとした時`!important`を多発しなくてはいけなくなったり、あれこれと障害になるためです。タグ名でスタイル指定はせず、面倒でも全部クラスを割り振ります。タグの構造は制作していく途中や、JSとの兼ね合いで変えることがよくあるので、その際に書き換える手間を減らし、HTML構造とCSSによるスタイリングを極力分離しておくためです。例外として、たとえばMarkdownパーサが出力するHTMLなど、クラスの割り当てられない部分で、かつタグにスタイルを指定するのが妥当な部分は除きます。大文字小文字を両方使って書く前提にすると、必ず大文字小文字のタイプミスでスタイルが当たらなくてうんうん悩む時間が発生するので、基本的に大文字は一切使いません。例外として、Angularアプリを書いていてdirective名とCSSの接頭辞を合わせたい、などの理由で接頭辞部分(一番先頭の部分)に限り、camelCaseを使ったりするのはアリです。ネストして上書きできます。それ以外のネストは基本的に禁止です。どのクラスがどのファイルに書かれているか、が瞬時にわかるようになります。sourcemapなどに頼る必要が発生したら負けです。後述のJavascriptとの連携に関わる予約語的なものなので、作成禁止です。JSで使っているクラスなので変更に注意が必要、ということを明示するために特別なクラスを指定します。JSでのDOM操作と、CSSでのスタイル指定はできるかぎり切り離しておいたほうがよいので、「.x-」のついたクラスに対してスタイルを当てることは絶対にしないようにします。後述の「.mode-」のついたクラスでコントロールします。jsでのDOM操作のためにIDを割り当てる場合は`id="xSomeElement"`というようにxから始まるcamelCaseで指定します。要素のアニメーションなどはできる限りCSSのtransitionやanimationで行います。ハイフンは使わず、`$some_sass_vars`といったような、アンダースコア区切り+小文字のスネークケースで変数を定義します。クラス名と区別をつけやすくすることと、SASSだと「-」が演算子としても機能するので、それとの区別をつけて意図しない演算などを防ぐためです。変数名は、ファイル名と同じ接頭辞で始めます。別に`$vars_`とかでもいいんだけどね。今のところ以下のようなコードでやってます。`@extend`は、extend元のスタイルを変更した時に影響する範囲が見えず、意図しない部分に影響が出たりするのでできる限り避けます。`@extend`を活用したSASSライブラリなどを使う場合は除きます。いった理由で採用していません。