CSS 向け SASS スタイル プログラミング ガイド

SASS を使用する開発者が増えるにつれて、SASS コードの数に注意する必要があります。 SASS 構文のいくつかの特別な機能を説明するために、まず CSS (Cascading Style Sheets) の構文から始めることができます。結局のところ、CSS スタイル ガイドは非常に一般的です。

この記事では主に、私が個人的に興味を持っている機能をいくつか紹介します。この記事を参考にして、独自の SASS 使用ガイドラインを作成できるかもしれません。
通常のCSSフォーマットルールとスタイルガイドに従ってください

この記事では SASS に関する内容に焦点を当てていますが、これに基づいて、開発者は既存の適切な書式設定ルールを維持する必要があります。まだ独自の書式設定ルールを作成していない場合は、独自の CSS 記述習慣を作成するのに役立つスタイル ガイドを以下にまとめました。含まれるものの一部を以下に示します。

1. 行のインデントを一定に保つ
2. コロン/中括弧の前後のスペースの数を一定に保つ
3. 1行に1つのセレクタと1行に1つのルールを記述する
4. 関連する属性を一緒に書いてみる
5. クラスの命名規則に関する計画がある
6. CSS IDセレクタの使用を避ける
7. 待つ

次に、美しい SASS コードの書き方を学びましょう。.weather クラスのプロパティの記述を例に挙げます。
最初に@extend(s)をリストする

そうすることで、開発者は明確な考えを保ち、このクラスとその属性、および他のクラスとその属性との関係をすぐに理解し、属性の一貫性と属性の再利用に関する明確な考えを維持できるようになります。
通常スタイル

これにより、開発者は @extend(s) と @include(s) の展開を一目で確認できるようになり、開発者自身や他の開発者がコードを解釈しやすくなります。場合によっては、カスタム @include とパブリック ソースからの @include を区別するかどうかを決定することもできます (特にコードの再利用性と適時性を考慮して)。
セレクタのネスト

ネストされたセクション内では、上記のスタイル ルールを引き続き使用します。ネストされたセクションは常に最後に来る必要があります。
すべてのベンダープレフィックスは@mixinsを使用します

メーカープレフィックス (CSS プレフィックス) は時間に非常に敏感です。 最新のブラウザが更新されるにつれて、これらのプレフィックスはますます使用されなくなります。ミックスインの内容を更新することで、これらの変更に適応できます (または、ミックスインで使用される一部のライブラリが自動的に更新されます)。 ミックスインが 1 行だけであっても問題ありません。
しかし、一部のベンダー プレフィックスが高度にプライベート化されると、これらのプレフィックスを標準化することが非常に困難になり、他のプレフィックスやプレフィックスなしのバージョンを適用することは労力に見合う価値がなくなります。私はこれらのベンダー プレフィックスの @mixin を放棄することを選択します。たとえば、-webkit-line-clamp、-mscontent-zoom-chaining などです。
ネストレベルは 3 レベルを超えてはなりません。

3 回以上ネストしている場合は、不適切な (不適切な?) セレクターを記述している可能性が非常に高くなります。この失敗の理由は、セレクターが HTML アーキテクチャに依存しすぎている (不安定)、詳細すぎる (強力すぎて柔軟性がない)、再利用するのが難しすぎる (あまり使いにくい) ことです。同時に、ネストされたレベルが多すぎると、コードがわかりにくくなり、理解しにくくなる可能性があります。

クラス関連のコードが多すぎて、タグセレクターを使用する必要がある場合があります。不要なカスケードを回避するには、クラスに何を記述するかを非常に具体的に指定する必要がある場合があります。 extend を使用して、CSS の再利用機能の一部を活用することもできます。

ネストされたコードの数は 50 行を超えてはなりません。

SASS のネストが 50 行を超えると、コンパイラの 1 ページに完全には表示されない可能性があり、コードの読み取りと理解が困難になります。ネスト機能は、もともと、思考とコードの構成を容易にし、簡素化することを目的としていました。読みにくくなる場合はネストしないでください。
グローバルおよびローカライズされたSASSファイルシーケンスはテーブルの内容と同等です

つまり、決まったスタイルがないのです。開発者は、すべての部分のスタイルを一貫して整然としたものに保つように注意する必要があります。

最初にベンダー/グローバル ライブラリがリストされ、次にカスタム ライブラリ、次にモード、最後に各部門で使用されるライブラリがリストされます。

この方法では、「ディレクトリ」は次の例のようになり、一目で非常に明確になります。

これらのファイルはコンパスのようなもので、色やミックスインはコンパイルされた CSS コードを生成せず、完全に独立したライブラリです。その後、排他性の競合を起こさずに書き換えをより安全に行うためにパターンが導入されました。
SASSを複数の小さなファイルに分割する

これをやっても何も悪いことはありません。可能な限り、複数の小さくて正確なファイルを使用してください。これにより、開発者は、長いコードを含む複数の大きなファイルの中から干し草の山から針を探す必要がなくなり、特定のファイルを見つけやすくなります。

...

私がよく行うのは、_header.scss ファイルを参照してから _header.scss ファイル内でこれらのファイルを 1 つずつ参照するのではなく、グローバル scss ファイル内でこれらのファイルを 1 つずつ参照することです。そうすることで、インデックス作成時間が短縮され、読み取り効率が向上します。

このようなファイルの数が多すぎてインポート シーケンスが長すぎる場合は、Globbing を使用することをお勧めします。
パーシャルの名前を_partial.scssにすることを忘れないでください。

これは、自身をコンパイルしないファイルの一般的な命名規則です。このようなファイルは多かれ少なかれ他のファイルに依存するため、独立してコンパイルすることは不可能になります。私は個人的に、_dropdown-menu.scssのようにファイル名の前にアンダースコアを追加するのが好きです。
ローカルコンパイル時に行マッピングを追加する

ここで、これは、インポートされた部分ファイルであっても、開発ツールが各ルールのソースを通知できることを意味します。
デプロイするときは、縮小されたファイルをコンパイルすることを忘れないでください

機能する Web ページでは、最小限の CSS のみを使用する必要があります。
.cssファイルを提出する必要はありません

これには多少時間がかかるかもしれませんが、リポジトリに .css ファイルが存在しないことは素晴らしいことです。コンパイルはデプロイメント時に行われます。 したがって、表示されるのは、縮小された美しくフォーマットされた sass ファイルだけです。 これにより、ファイルの説明が非常に役立ちます。ファイルの説明は、バージョン発行者によって行われた変更を比較するために使用されます。すでに合理化された .css ファイルの場合、ファイルの説明は基本的に必要ありません。
豊富な使用上の注意

コード内にコメントを残したことを後悔する人はほとんどいません。コメントは、有用であろうと無用であろうと、縮小された CSS ファイルにコンパイルされると、最終的には削除されます。開発者に追加コストはかかりません。

。かぶせる {
/* モーダルは 6000、保存メッセージは 5500、ヘッダーは 2000 */
zインデックス: 5000;
}

コメントについて言えば、コメントに対して標準化の調整を加えることも必要になる場合があります。 SASS では、コメントを追加するには '//' が非常に適しています。 '//' を使用すると、コメントの追加とコメント解除が非常に便利になります。
よく使われる値や特別な意味を持つ値を変数に変換する

値を再利用する場合 (フロントエンド設計では非常に一般的です)、値を変数に変換した方がよいでしょう。こうすることで、値に名前を付けることでその値の意味を思い出すことができ、コードを書くときに一貫性を保つことができるため、値を変更するときに行ごとに調整する必要がなくなります。

数字に明らかな意味がある場合は、それを変数に変換することが不可欠です。

これらの数値は単一のファイルに保存され、@imported としてインポートされる場合があります。この方法では、すべてのZインデックスやその他の変数を統一的に管理できます。
色を変数に変換する

白黒以外。二度と使わないと思っていても、何度も使われる色はたくさんあります。しかし、それを変数に変換すると、他の場所でも必要になる場合があります。カラー変数については、lighten() や darkern() など、Sass で処理できるカラー関数があります。これにより、全体の色を簡単に制御できます（一度変更したら、あとは忘れてください）
メディアライブラリをネストして名前を付ける

Sass でメディア ライブラリをネストできるということは、1. 他の場所でセレクターをオーバーライドして不要なエラーを発生させる必要がないこと、2. オーバーライドするルールが明確であること (CSS の最後や別のファイルにある場合、非常に混乱する可能性がある) を意味します。

より詳しい説明はこちらをご覧ください: http://css-tricks.com/naming-media-queries/
恥は最後に

グローバル スタイルシートの最後に _shame.scss ファイルをインポートします。

すぐに変更する必要がある場合は、ここで変更できます。後で時間とエネルギーがあれば、
_shame.scss の全体的なアーキテクチャに加えられた変更は、より適切に整理され、構造化されています。詳細については、http://csswizardry.com/2013/04/shame-css/ をご覧ください。
すべてを決めるのはあなたです

Sass は指示されていないことは何も行わないので、Sass ファイルの最終的な出力はあなた次第です。 Sass を使用して CSS ファイルを書くのは、Sass を使用せずに CSS ファイルを書くのと同じです。あなたはコードのマスターです。