Sassスタイルガイド：より良いCSSコードを書く方法に関するSassチュートリアル

うまくスケーリングする一貫性のある読みやすいCSSを作成することは、困難なプロセスです。 特に、スタイルシートが大きくなり、複雑になり、保守が困難になる場合。 開発者がより良いCSSを作成するために利用できるツールの1つは、プリプロセッサです。 プリプロセッサは、あるタイプのデータを取得して別のタイプのデータに変換するプログラムです。この場合、CSSプリプロセッサはCSSにコンパイルされる前処理言語です。 フロントエンド開発者が推奨して使用しているCSSプリプロセッサはたくさんありますが、この記事ではSassに焦点を当てます。 Sassが提供するもの、他のCSSプリプロセッサよりも好ましい選択である理由、およびSassを最良の方法で使用し始める方法を見てみましょう。

Sassとは何ですか？なぜそれを使用する必要がありますか？

Sassとは何かを知らない方は、Sassの公式Webページにアクセスすることをお勧めします。 Sassは、Syntactically Awesome StyleSheetsの頭字語であり、基本言語にパワーとエレガンスを追加するCSSの拡張機能です。

Sassは、多くの強力な機能を備えたCSSプリプロセッサです。 最も注目すべき機能は、変数、拡張、およびミックスインです。

変数には、色やその他の一般的に使用される値など、後で再利用できる情報が格納されます。 拡張は、ルールの継承を可能にする「クラス」を作成するのに役立ちます。 Mixins、あなたは「機能」のように考えることができます。 Sassには、ロジックステートメント（条件文とループ）の使用、カスタム関数、Compasなどの他のライブラリとの統合など、他のプリプロセッサと比較して他の驚くべき機能もあります。 これらの機能だけでも、あなたとあなたのチームがより生産的になり、最終的にはより良いCSSを作成するのに役立ちます。

CSSスタイルガイドが必要な理由

残念ながら、プリプロセッサでさえすべてを修正して、優れたCSSコードを作成するのに役立つわけではありません。 すべての開発者が直面している問題は、現在のWebアプリケーションがますます大きくなっていることです。 そのため、コードはスケーラブルで読み取り可能である必要があり、スパゲッティコードとその未使用の行を避ける必要があります。 上記の問題を回避するには、日常業務におけるチームの何らかの基準が必要です。 スパゲッティコードとは何ですか、そしてそれはどのように起こりますか？ スパゲッティコードは、悪く、遅く、反復的で、読めないコードの名前です。 チームが定義されたガイドラインや標準を設定せずに大きなアプリケーションを作成する場合、各開発者は必要なものと必要な方法を作成します。 また、開発者が多くのバグ修正、修正プログラム、およびパッチを作成している場合、問題を解決するコードを作成する傾向がありますが、最良の方法でコードを作成する時間がありません。 このような状況では、アプリケーションのどのセクターでも使用されなくなったCSSの行が大量に発生するのが非常に一般的です。 開発者はコードをクリーンアップするのに十分な時間がなく、修正をできるだけ早く公開することを余儀なくされています。 もう1つの再発する状況は、壊れたものをすばやく修正するために、開発者が多くの!importantを使用することです。これは、保守が困難な非常にハッキーなコードになり、予期しない動作が多くなり、後でリファクタリングする必要があります。 すでに述べたように、コードが大きくなるにつれて、状況は悪化するだけです。

この記事の目的は、より良いSassを作成するためのルール、ヒント、およびベストプラクティスを共有することです。 これらのSassのヒントとベストプラクティスをグループ化すると、Sassスタイルガイドとして使用できます。 このスタイルガイドは、開発者が上記の状況を回避するのに役立つはずです。 ルールは参照しやすいように論理セグメントにグループ化されていますが、最終的にはすべてを採用して従う必要があります。 または少なくとも、それらのほとんど。

スタイルガイド

このスタイルガイドの一連のルールとベストプラクティスは、多くのチームでの作業経験に基づいて採用されています。 それらのいくつかはエラーによる試行から来ており、他はBEMのようないくつかの人気のあるアプローチに触発されています。 一部のルールでは、それらが設定された理由と方法に特定の理由はありません。 唯一の理由として過去の経験を持つだけで十分な場合もあります。 たとえば、コードが読みやすいことを確認するには、すべての開発者が同じ方法でコードを記述していることが重要です。したがって、括弧の間にスペースを含めないという規則があります。 括弧の間にスペースを含める方がよいかどうかを議論することができます。 括弧の間にスペースがあると見栄えが良くなると思われる場合は、このスタイルガイドとルールを好みに応じて調整してください。 結局、スタイルガイドの主な目標は、ルールを定義し、開発プロセスをより標準的にすることです。

一般的なCSSルール

一般的な規則は常に従う必要があります。 それらは主に、コードの一貫性と読みやすさをもたらすためにSassコードをフォーマットする方法に焦点を当てています。

• インデントには、タブの代わりにスペースを使用します。 ベストプラクティスは、2つのスペースを使用することです。 このオプションを使用して独自の聖なる戦いを実行できます。また、独自のルールを定義して、タブ、スペース、または自分に最も適したものを使用できます。 ルールを定義し、一貫性を保ちながらそのルールに従うことが重要です。
• 各ステートメントの間に空の行を含めます。 これにより、コードがより人間に読めるようになり、コードは人間によって書かれますよね？
• 次のように、1行に1つのセレクターを使用します。

 selector1, selector2 { }

• 括弧の間にスペースを入れないでください。

 selector { @include mixin1($size: 4, $color: red); }

• 文字列とURLを囲むには、一重引用符を使用します。

 selector { font-family: 'Roboto', serif; }

• すべてのルールをスペースなしのセミコロンで終了します。

 selector { margin: 10px; }

セレクターのルール

次に、セレクターを処理するときに使用する一連のルールに従います。

• IDセレクターの使用は避けてください。 IDは具体的すぎて、主にJavaScriptアクションに使用されます。
• !importantは避けてください。 このルールを使用する必要がある場合は、CSSルール全般に問題があり、CSSが適切に構造化されていないことを意味します。 多くの!importantルールを持つCSSは簡単に悪用される可能性があり、CSSコードを維持するのが面倒で困難になります。
• 子セレクターは使用しないでください。 このルールは、IDのルールと同じ理由を共有しています。 子セレクターは具体的すぎて、HTML構造と緊密に結合されています。

Sassルールを整理する

コードの一貫性を保つことが重要です。 ルールの1つは、ルールの順序を維持する必要があるということです。 このようにして、他の開発者はより多くの理解を持ってコードを読むことができ、自分の道を見つけるために費やす時間が少なくなります。 提案された注文は次のとおりです。

1. 最初に@extendを使用します。 これにより、このクラスが他の場所からルールを継承していることが最初にわかります。
2. 次に@includeを使用します。 ミックスインと関数を一番上に含めると、何を上書きするかを知ることができます（必要な場合）。
3. これで、通常のCSSクラスまたは要素ルールを記述できます。
4. ネストされた疑似クラスと疑似要素を他の要素の前に配置します。
5. 最後に、次の例のように、他のネストされたセレクターを記述します。

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

いくつかの命名規則

スタイルブックの命名規則の一部は、開発者の間で普及した2つの既存のBEMおよびSMACSS命名規則に基づいています。 BEMは、Block、Element、Modifierの略です。 これはYANDEXチームによって開発され、BEMの背後にある考え方は、開発者がプロ​​ジェクト内のHTMLとCSSの関係を理解できるようにすることでした。 一方、SMACSSは、CSSのScalable andModularArchitectureの略です。 これは、保守性を可能にするためにCSSを構造化するためのガイドです。

それらに触発されて、私たちの命名規則の規則は次のとおりです。

• 要素のタイプごとにプレフィックスを使用します。 レイアウト（ l- ）、モジュール（ m- ）、状態（ is- ）のように、ブロックのプレフィックスを付けます。
• すべてのブロックの子要素に2つのアンダースコアを使用します。

 .m-tab__icon {}

• すべてのブロックの修飾子に2つのダッシュを使用します。

 .m-tab--borderless {}

変数

変数を使用します。 色などのより一般的でグローバルな変数から始めて、それらの_colors.scss用に別のファイルを作成します。 スタイルシート上でいくつかの値を複数回繰り返していることに気付いた場合は、その値の新しい変数を作成してください。 乾かしてください。 その値を変更したいとき、および1か所だけで変更する必要があるときは感謝します。

また、ハイフンを使用して変数に名前を付けます。

 $red : #f44336; $secondary-red :#ebccd1;

メディアクエリ

Sassを使用すると、メディアクエリを要素クエリとして記述できます。 ほとんどの開発者は、メディアクエリを別のファイルまたはルールの下部に記述しますが、これはお勧めしません。 Sassを使用すると、メディアクエリをネストすることで、次の例のようなものを書くことができます。

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

これにより、次のようなCSSが生成されます。

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

このネストされたメディアクエリルールを使用すると、名前付きメディアクエリが使用されているSassスニペットでわかるように、上書きしているルールを非常に明確に知ることができます。

名前付きメディアクエリを作成するには、次のようにミックスインを作成します。

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

メディアクエリの命名について詳しくは、次の記事を参照してください：メディアクエリの命名とSassを使用したより優れたメディアクエリの記述。

その他の考慮事項

最後に、以下の考慮事項も念頭に置いて従う必要があります。

• ベンダープレフィックスは絶対に記述しないでください。 代わりに自動プレフィックスを使用してください。
• ネストされたルールの最大3レベルを使用します。 ネストされたレベルが3つを超えると、コードが読みにくくなり、ひどいセレクターを作成している可能性があります。 最後に、HTMLと結合するCSSコードを記述しています。

 .class1 { .class2 { li { //last rules } } }

• 50行を超えるネストされたコードを記述しないでください。または、X行を超えるネストされたコードを記述しないことをお勧めします。 独自のXを設定しますが、50は適切な制限のように見えます。 その制限を超えると、コードのブロックがテキストエディタウィンドウに収まらない可能性があります。
• すべてのブロック、パーシャル、および構成をインポートするメインファイルを作成します。
• 最初にベンダーとグローバルの依存関係をインポートし、次に作成された依存関係、次にレイアウト、パターン、最後にパーツとブロックをインポートします。 これは、ベンダーとグローバルルールを管理できないため、ルールのインポートと上書きが混在しないようにするために重要です。
• 恥ずかしがらず、できるだけ多くのファイルにコードを分割してください。

結論

このスタイルガイドの背後にある考え方は、Sassコードの記述方法を改善する方法についてアドバイスを提供することです。 Sassを使用していない場合でも、このスタイルガイドで提供されているヒントとルールが適用可能であり、VanillaCSSまたは別のプリプロセッサを使用する場合に従うことをお勧めします。 繰り返しますが、どのルールにも同意できない場合は、自分の考え方に合うようにルールを変更してください。 最終的に、このスタイルガイドを採用するか、他のスタイルガイドを使用するか、まったく新しいスタイルガイドを作成するかは、あなたとあなたのチーム次第です。 ガイドを定義して、すばらしいコードを書き始めてください。