はじめに
CSSは完璧ではありません。 最初は簡単に習得できるように見えますが、実際のプロジェクトで作業すると多くの問題が発生します。 CSSの動作を変更することはできませんが、作成するコードを変更することはできます。
さまざまな専門性とスキルを持つ多数の開発者が参加する大規模な長期プロジェクトで作業する場合、特定のルールに従うことが非常に重要です。 レイアウト設計者にとって、これらのルールは次のようになります。
- 開発者はサポートされているコードを作成する必要があります。
- 開発者は、透明で読みやすいコードを作成する必要があります。
- 開発者はスケーラブルなコードを作成する必要があります。
これらのルールを順守するために使用しなければならない多くのテクニックがあります。 CSS GuideLinesには、これらすべてのルールに従うのに役立つ基本的なガイドラインとアプローチが含まれています。
コード設計ガイドラインの重要性
コード設計ガイドは、次のようなチームにとって貴重なツールです。
- 長期にわたる製品の開発と保守。
- 異なるスキルレベルと異なる専門分野の開発者がいる。
- 特定の数の開発者が常に何かに取り組んでいる。
- 定期的に新しい開発者を雇います。
- さまざまな人々が常に作業する一定数のソースコードを持っています。
大規模な開発者チームを持つ大規模プロジェクトでは、誰もがコードの標準化に努める必要があります。
コードのスタイル設定に関する優れたガイドは、以下を実現します。
- すべてのソースのコード品質基準の確立。
- ソースコード間の一貫性を確保します。
- すべての開発者による標準に従う。
- 生産性を向上させます。
コードの設計に関するガイドラインは、すべての開発者が習得して適用する必要があり、ルールからの逸脱は正当化する必要があります。
免責事項
CSS StyleGuideは、必須のテクニックと方法論のコレクションです。 これは、私の個人的な経験でテストした推奨事項のコレクションです。 それらを適用するかどうかはあなた次第です。
構文とフォーマット
コード設計のための最も単純なタイプのガイドの1つ（以降、スタイルガイド、およそ翻訳者と呼ばれます）は、構文と書式に関する一連のルールです。 CSSスタイルの設計のためのルールの存在は、チームのすべてのメンバーにとってコードが常に明確であることを意味します。
きれいなコードは
清潔感を与えます。 クリーンなコードを使用する方がはるかに快適です。そのようなコードは、他のチームメンバーがコード記述基準を遵守することを奨励します。 汚いコードはひどくうんざりします。誰もそれを使いたくありません。
理想的には、開発者は以下を使用する必要があります。
- インデント用に4つのスペース。 タブではなくスペースです。
- 行は80文字以下です。
- 複数行のCSS
- 空スペースの効率的な使用。
コードのフォーマットに関連するルールを見てみましょう。
複数ファイルの分割
CSSプリプロセッサの人気が急速に高まった後、多くの開発者はCSSコードを別のファイルに分割することが多くなりました。 プリプロセッサを使用しない場合でも、コードの独立した部分を別々のファイルに配置し、プロジェクトをビルドするときにそれらを1つのファイルに結合するとよいでしょう（たとえば、GruntまたはGulpを使用）。
何らかの理由で複数のファイルを使用することを拒否した場合、次の手順では微調整が必要になる場合があります。
目次
CSSファイルに目次を追加するのは非常に面倒ですが、これらのコストは価値があります。 はい。目次を修正し、最新の情報を維持するために、開発者の勤勉さが必要です。 しかし、その後、チーム全体が、CSSファイルに含まれる内容、その内容、スタイルの配置順序に関する情報を含む単一のテーブルを取得します。
たとえば、目次の最も単純なバージョンは、セクションの名前とその説明を追加することです。
当然、多くのプロジェクトでは目次がはるかに大きくなる可能性がありますが、この例がプロジェクトのメインCSSファイルの目次がどのようにプロジェクトで何が、どこで、どのように使用されているかを開発者に示すことができることを願っています。
80文字の線幅
可能であれば、CSSファイルの行を80文字に制限することが望ましいです。 そうする理由：
- 複数の開いているファイルを隣り合わせに配置する機能。
- GithubなどのサイトまたはターミナルウィンドウでCSSを表示する機能。
- コメントを追加するための快適な行の長さを提供します。
このルールには例外があることに注意してください-たとえば、長いURLの文字列。
コードセクションの命名
CSSの各大きなセクションは、次のように開始する必要があります。
.selector {}
セクション名の先頭に「＃」記号を追加すると、ファイルをより速く検索できます。 「SECTION TITLE」クエリは多くの結果を返す可能性がありますが、先頭にグリッドがあるクエリは1つの望ましい結果のみを返す可能性があります。 セクション名と最初のセレクターの間に空の行を残すことも価値があります。
各セクションが個別のファイルに配置されているプロジェクトで作業している場合、セクション名はこのファイルの先頭にある必要があります。 プロジェクトで1つのファイルに複数のセクションがある場合、最後のセレクターと新しいセクションの名前を5つの空の行で区切ります。 これにより、特に長いファイルを表示する場合に、コードの可読性が大幅に向上します。
.selector {} .another-selector {}
CSSルールの構造
開発者がCSSルールを記述する方法について説明する前に、使用されている用語を明確にしましょう。
[] { []: []; [<----->] }
例：
.foo, .foo--bar, .baz { display: block; background-color: green; color: red; }
このコードでは、次のことがわかります。
- 1つの行の関連セレクター、異なる行の非バインドセレクター。
- 括弧（{）を開く前のスペース。
- プロパティとその値を1行で;
- プロパティに関連するコロンの後のスペース。
- 各行のプロパティ宣言とその値。
- 開始ブラケットは、最後のセレクターと同じ行にあります。
- 最初のプロパティ宣言は、開き括弧の後の新しい行にあります。
- 閉じ括弧は別の行にあります：
- 各広告は4つのスペースでインデントされます。
- セミコロンは、プロパティ値の直後にスペースなしで配置されます。
この書き方は、概して、一般に受け入れられている普遍的な方法です（インデント用のスペースの数を除く。多くの開発者は、4つではなく2つのスペースを使用することを好みます）。
したがって、以下の例は正しくありません。
.foo, .foo--bar, .baz { display:block; background-color:green; color:red }
この例の問題：
- スペースではなくタブ。
- 1行の非バインドセレクター。
- 別の行の開始ブラケット。
- 最後の宣言と同じ行の閉じ括弧。
- セミコロン（ちなみに、最後の広告のオプション）は最後の広告の最後にはありません。
- コロンの後にスペースはありません。
複数行のCSS
CSSは、非常に特殊な状況を除いて、常に数行で記述する必要があります。 利点：
- 各広告が別々の行にあるという事実により、広告をマージする際の競合のリスクを減らします。
- 信頼性が高く読みやすい差分。単一の行には1つの変更のみが含まれるため。
このルールの例外はかなり明白です。 たとえば、内部に宣言が1つしかない類似したルールセットが複数ある場合、すべてを1行で記述できます。
.icon { display: inline-block; width: 16px; height: 16px; background-image: url(/img/sprite.svg); } .icon--home { background-position: 0 0 ; } .icon--person { background-position: -16px 0 ; } .icon--files { background-position: 0 -16px; } .icon--settings { background-position: -16px -16px; }
これらのタイプのルールは、次の理由で1行で記述できます。
- 彼らはまだ1行で1つの変更の規則を順守しています。
- それらは1つのコードブロックに結合するのに十分類似しています。 他の独立したルールと同じ注意で読む必要はありません。
くぼみ
宣言のインデントと同様に、関連するルールセットをインデントします。
.foo {} .foo__bar {} .foo__baz {}
これにより、開発者は.foo__bazが.foo__bar内に配置され、さらに.foo__barが.foo内に配置されていることがわかります。 DOMをシミュレートするこの方法により、開発者はクラスの場所について多くのことを知ることができるため、毎回マークアップを開いて適切なコードを探す必要はありません。
Sassのインデント
Sassは、ルールを相互にネストする機能を提供します。 これは、そのようなscssコードを書くことにより：
.foo { color: red; .bar { color: blue; } }
...次のコンパイル済みCSSを取得します。
.foo { color: red; } .foo .bar { color: blue; }
Sassを使用する場合、インデントに同じ4つのスペースを使用し、ネストされたルールの前後に空の行を残す必要があります。 ところで、Sassでのネストは避けてください。 これについては、次のパートでさらに説明します。
アライメント
可能であれば、同様の行をプロパティに合わせます：
.foo { -webkit-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; } .bar { position: absolute; top: 0; right: 0; bottom: 0; left: 0; margin-right: -10px; margin-left: -10px; padding-right: 10px; padding-left: 10px; }
これにより、テキストエディターが複数行の編集を一度にサポートする開発者の生活が大幅に簡素化されます。
空のスペースのスマートな使用
インデントと同様に、ルール間の空のスペースを正しく使用することにより、開発者に多くの情報を提供できます。
使用：
- 関連するルールセット間の1つの空白行。
- 無関係なルールセット間の2つの空白行。
- セクション間の5つの空白行。
例：
.foo {} .foo__bar {} .foo--baz {} .bar {} .bar__baz {} .bar__foo {}
規則の間に空の行がないことは決して起こりません。 以下の例は間違っています。これを行うべきではありません。
.foo {} .foo__bar {} .foo--baz {}
HTML
HTMLとCSSの密接な関係を考えると、私にとっては、マークアップに関するいくつかの点は言うまでもありません。
コードが引用符なしで機能する場合でも、属性は常に引用符で囲みます。 引用符付きの形式はほとんどの開発者にとって最も一般的であり、この形式を使用すると多くのエラーを回避できます。
このコードは機能します：
<div class=box>
ただし、次のコードを使用することをお勧めします。
<div class="box">
属性に複数の値を書き込む場合、これらの値を2つのスペースで区切ります。
<div class="foo bar">
複数のクラスが相互に関連している場合、それらを括弧で囲む方法を検討してください。
<div class="[ box box--highlight ] [ bio bio--long ]">
これは厳密な推奨事項ではなく、プロジェクトでテストしていますが、この方法には多くの利点があります。 詳細については、記事
「マークアップで関連クラスをグループ化する」を参照してください。
スタイルシートと同様に、マークアップで空のスペースを使用することもできます。 たとえば、コンテンツの重要なセクションを5つの空白行で区切らないでください。
<header class="page-head"> ... </header> <main class="page-content"> ... </main> <footer class="page-foot"> ... </footer>
マークアップの独立しているが密接に関連する部分を1つの空白行で分離します。
<ul class="primary-nav"> <li class="primary-nav__item"> <a href="/" class="primary-nav__link">Home</a> </li> <li class="primary-nav__item primary-nav__trigger"> <a href="/about" class="primary-nav__link">About</a> <ul class="primary-nav__sub-nav"> <li><a href="/about/products">Products</a></li> <li><a href="/about/company">Company</a></li> </ul> </li> <li class="primary-nav__item"> <a href="/contact" class="primary-nav__link">Contact</a> </li> </ul>
この方法により、コードの可読性が向上し、一部のテキストエディター（Vimなど）でマークアップのそのような部分を簡単に操作できるようになります。
さらなる研究のための資料
続き：
CSSガイドライン、パート2。コードのコメント