Zenn
🥞

【全30項目】コーディング時のルールや思想（HTML/CSS/Sass/JSなど）

2023/07/27に公開2件
CSS
HTML
JavaScript
tech

宣伝💡

この記事の内容の超大容量版がこちらの本になります。興味がある方は是非チェックしてみてください。

https://zenn.dev/dadada/books/5d9352710d35a0

Web業界に新卒で入ってから7年と数ヶ月が経ちました。私はデザインからフロントエンド全般が守備範囲です（Next.jsを使った軽めのWeb開発くらいまで）。

最近ようやく自分の中での「コーディングの手法やルール」が固まってきたので、言語化してこの記事で解説していこうと思います。

はじめに

まず最初にこの記事の方針や前提をいくつか書いておきます。

  • 用語や知識の詳しい解説はしていないので、分からない内容が出てきたら調べながら記事を読んでいただくとより理解しやすいと思います
  • 実務を数年経験していないと理解できない部分があるかもしれないです（完全初学者向けではなく、初・中級者向け）
  • あくまで自分の中での手法やルールであり、全ての実装者・会社・プロジェクトなどに当てはまるわけではありません（もちろん私も、全てのプロジェクトでここに書いた全てのルールや手法を取り入れているわけではなく、必要に応じて取捨選択やカスタマイズをしています）。

コーディングの手法やルールはこのような順番で解説していきます。

  1. 作業環境
  2. 実装を始める前に
  3. ディレクトリ構成と画像まわり
  4. HTMLでマークアップ
  5. CSSでスタイリング
  6. Sassの運用ルール
  7. JavaScriptの実装ルール
  8. PHPで効率化

作業環境

作業環境をしっかりと整えることで、実作業の時間が大幅に短くなります。作業環境があまり整っていない方は、まずはここに時間をかけて作業環境を整備することをおすすめします。

VSCodeを使う

よほどな理由がない限り、テキストエディタはVSCodeを使うべきです。作業効率が上がる拡張機能が豊富で動作も軽量です。Emmetやスニペットを使いこなせば倍近く作業が早くなることもあります。

おすすめの拡張機能や設定を紹介する記事を過去に書いたので是非読んでみてください。

https://zenn.dev/necscat/articles/d0946fec7f84be

LinterとPrettierを使う（構文チェック&自動整形）

ESLint, Stylelint, Markuplint, Prettierを使うことで、構文チェックや保存時の自動整形を行ってくれます。

複数人で開発をする際にバラつきやすい書き方も細かくルールで縛れるので、コードの品質も上がります。

https://wemo.tech/3307

CSSプロパティの順番は自動で並び替える

CSSやSassのプロパティの順番はある程度ルールを事前に決め、その順番通りに書きます。ルールに従って書くのが面倒くさくても、触りたいプロパティをすぐ見つけられるので結果的に作業効率が上がると私は思っています。

その順番はStylelintのプラグインで自動で並び替えることができるので、最近はそれを使っています。

https://github.com/stormwarning/stylelint-config-recess-order

StylelintとESLintの環境構築方法は、Next.jsの記事ですがこちらの記事が参考になると思います。Next.js部分以外を実行すれば自動整形などの環境を作れるはずです。

https://zenn.dev/necscat/articles/435db2f1dbbb29

実装を始める前に

手を動かす前に最初にやるべきことがいくつかあるので、それを紹介していきます。

仕様書やデザインデータの確認

最初に仕様書やデザインデータの確認をしっかりと行います。確認観点をいくつか挙げてみました。

  • 作業ボリューム（何ページ・何テンプレートあるか）
  • コーディングルールの有無
  • 使用されている色やフォントのバリエーション
  • アニメーションの有無や難易度（ホバーやスクロール時のアニメーション）
  • デザインの再現度（ピクセルパーフェクトなのかどうか）

不明点やスキル的に不安な部分があれば、できるだけ最初のうちに相談するといいでしょう。

また、本番環境やリリース方法の確認も可能であればしておきます。このあたりは作業を始める前というよりは、プロジェクト開始時点で聞いておきたいですね。

  • 本番のURLやURL構造（ドメイン直下になるのか、ディレクトリを切って配置されるのか、など）
  • リリース方法
  • 納品形式
  • 対応範囲（リリースのみなのか、DNSの移行などインフラ周りの作業も行うのか、など）
  • 既存ページの改修の場合、既存データのバックアップはどうするのか

READMEを書く

READMEは必ず書きます。適当に書くのではなく、そのプロジェクトについて必要な情報をしっかりと書くことで将来必ず感謝することになります。

私がいつも書いているのは以下のような情報です。

  • クライアント名
  • プロジェクト名
  • 各種環境情報（本番環境、開発環境など）
  • 各種資料のURL
  • 環境構築方法（動作確認済みのバージョンも明記する）
  • リリース方法
  • 注意点など
README.mdの例
# 株式会社○○ オウンドメディア△△ WodPress構築

## 環境情報

### 本番
https://hoge.com

### 開発
https://dev.hoge.com
- ID: `id`
- Password: `password`

## 各種資料
- リリース手順：https://...
- 仕様書：https://...

## 環境構築方法
・
・
・
※ Node.js`v18.15.0`にて動作確認済み

https://zenn.dev/sutamac/articles/5a262f0096176a

ディレクトリ構成と画像まわり

ディレクトリ構成をしっかりと整備することで、作業しやすくなってミスも減ります。また、画像まわりはサイトパフォーマンスに大きく影響を与えるので正しい対応を心がけましょう。

ディレクトリ構成

静的なページを実装する場合はこのようなディレクトリ構成にしています。

ディレクトリ構成の例
.
├── _src/
│   ├── js/
│   └── sass/
├── public/
│   ├── assets/
│   │   ├── css/
│   │   ├── img/
│   │   └── js/
│   └── index.html
├── package.json
├── README.md
└── webpack.config.js

_srcの中のファイルがWebpackでコンパイルされ、public/assets/に出力されます。

実際に本番環境にアップするファイルはpublic/の中のファイルのみになります。なので、ローカルサーバーの起点はpublic/にします。

このように本番にアップするファイル専用のディレクトリを作ることで、本番に不要なファイルがアップされることがなくなり、さらに一目で本番にアップするファイルが分かるようになります。

画像の書き出し

画像を書き出す時に意識するポイントをいくつか挙げてみました。これらのルールに従って書き出します。

  • 書き出した画像は圧縮する
  • 写真ならjpg、透過やベタ塗りならpng、ベクターならsvgのように適切な拡張子で書き出す
  • SVGはアウトライン化し、不要な情報は削除する
  • 連続するアイコンの大きさが違う場合、自分で正方形の透明な背景を作り同じ大きさにして書き出す
  • レティーナディスプレイを考慮して2倍のサイズで書き出す
  • 画像の名前は分かりやすく付ける（デザインデータのレイヤー名などのままにしない）
  • 画像名にマジックナンバーは極力使わない（item-1.jpg、bg-2.pngなど）

画像のディレクトリ構成

public/assets/img/以下のディレクトリ構成は以下のようにしています。

ディレクトリ構成の例
public/assets/img/
├── _common/ ・・・ 共通画像
│   ├── favicon/ ・・・ ファビコン系
│   ├── logo/ ・・・ ロゴ系
│   └── icon/ ・・・ アイコン系（この中で更にsns/などでディレクトリを切ることもある）
├── index/ ・・・ トップページの画像をまとめるフォルダ
│   ├── mv/ ・・・ メインビジュアルの画像フォルダ
│   └── company/ ・・・ 会社概要の画像フォルダ
├── service/ ・・・ サービスページの画像をまとめるフォルダ
│   ├── ...
・   ・
・   ・
・   ・

public/assets/img/直下には共通ファイル用の_common/と、各ページの名前で作ったフォルダがあります。

_common/の中では、役割ごとにいくつかのフォルダを作っています。

各ページのフォルダでは、セクションごとにさらにフォルダを作り、その中に画像を配置します。

このようにしっかりとフォルダ分けすることで、使いたい画像をすぐ見つけられるようにしています。

HTMLでマークアップ

マークアップは見た目以外にも考慮するべきポイントがいくつもあります。また、運用時のことを見越して実装するのも重要です。

今どきのHTMLやCSSを使う際は必ずCan I useを確認する

ブラウザは日々進化し続け、その度に便利なHTMLやCSSが追加されています。しかし、新しい技術が全てのブラウザで使えるわけではありません。

IEのサポート終了により数多くの技術が使えるようになりましたが、第二のIEと呼ばれているのがSafariです。他のブラウザではサポートされている技術もSafariだと使えないケースもちらほらあります。

なので、新しい技術を使う際はCan I useを必ず確認するようにしましょう。

https://caniuse.com/

サイトパフォーマンスを常に意識する

サイトの読み込み速度は1秒増えるごとに離脱率が数十パーセントも上がると言われています。なので、サイトの高速化はとても重要です。

画像やファイルの読み込み方、画像まわりの扱い、HTMLパースやサーバーへのリクエストに関する知識など、意識するべきポイントはたくさんあります。

コーダーが対応できる高速化についての記事があるので、興味がある方は読んでみてください。

https://zenn.dev/necscat/articles/cdd4c17d52f1bc

https://twitter.com/dai_webp/status/1669268965548494848?s=20

SEOを常に意識する

「綺麗なHTMLを書けばSEO対策になる」という考え方は間違っていると私は思っています。以下3点について解説した記事を書いたので興味がある方は読んでみてください。

  • そもそもSEO対策とは
  • 何故正しいHTMLでコーディングをしてもSEO対策にならないのか
  • それでも正しいHTMLでコーディングをする理由

https://zenn.dev/dadada/articles/f24228dfb8b87d

コアウェブバイタルを常に意識する

コアウェブバイタルはGoogleがSEO評価に影響を与えると名言しているので、3つの指標を常に意識してコーディングを行います。

  • Largest Contentful Paint（LCP）：サイトの読み込みスピード
  • First Input Delay（FID）：サイトの応答性
  • Cumulative Layout Shift（CLS）: サイトの視覚要素安定性

https://liginc.co.jp/556930

アクセシビリティに優れたタグを使う

HTML Living Standard には日々新しいタグが追加されており、中にはアクセシビリティに優れたタグも数多くあります。

アコーディオンを実装するなら<details>と<summary>を、モーダルなら<dialog>を使うといいでしょう。

https://ics.media/entry/220901/

https://ics.media/entry/220620/

アクセシビリティに関しては、こちらの記事も参考になるので是非読んでみてください。

https://haniwaman.com/wcag-html/

クラス名の付け方・考え方

クラス名の付け方や考え方を自分の中でしっかりと定めておくことで、クラス名に悩むことが少なくなり、その結果マークアップ速度が早くなります。

命名規則の統一

CSS設計を取り入れるなら、全てのクラス名を命名規則通りにします。1箇所でもルールを破ってはいけません。

また、単語の区切り方のルールも全ての箇所で統一します。

.prodact-list // ハイフン
.prodact_list // アンダーバー
.prodactList // キャメル
デザインに左右される名称にしない

左右に画像とテキストがあるレイアウトの場合、.leftや.rightを使いたくなりますが、もしデザインが修正されて左右逆になったらクラス名も修正しなければいけません。また、画面幅が小さくなったら左右から上下のレイアウトになる場合、その時に.leftや.rightだと違和感があります。

このような場合は、.img, .textのように具体的な名前にするのがいいでしょう。

色に関する命名は抽象的にする

サイトのメインカラーが赤の場合、その色のクラス名は.redにしたくなりますが、メインカラーが青に変わったら.redは修正する必要があります。

このような場合は、.main-colorや.primary-colorなど抽象的なクラス名にするといいでしょう。

難しい単語は使わない

難しい単語を使うと、その時は理解できていても少し経ったら意味を忘れてしまいます。複数メンバーで開発しているのであれば、メンバーの理解度も様々です。

難しい単語はできるだけ使わず、他に候補がないか考えてみることも重要です。

時にはローマ字読みも許容する

専門用語や固有名詞の場合、英語に変換すると冗長になったり、全く理解できなくなることがあるので、あえてローマ字にするほうがいいケースもあります。

<a>, <img>, <span> が最後の子要素の場合、クラス名を付けないことを許容する

私がよく使うBEMの思想は「全ての要素にクラス名を付ける」です。しかし、これらのタグは保守運用時や修正などで変わることが限りなく少ないので、クラス名を付けなくても問題ないと思っています。

CSSでスタイリング

CSSをキレイに書かないとどんどんカオス化して、修正するのが困難になってしまいます。なので、運用時に修正しても崩れない、さらに修正しやすいCSSを書くコツをここでは解説していきます。

詳細度はできるだけ同じにする

CSSが適用される優先度は、クラスやIDなどセレクタの種類によって変わります。

https://zenn.dev/yend724/articles/20221218-pgvxke7xs8svn4nn

基本的にはクラスセレクタのみを使い、クラスは1つのみでスタイルを記述します。タグを使ったりクラスを複数使って入れ子にしたりすると、詳細度の点数が場所によってバラバラになり、最終的に!important祭りになってしまいます。

詳細度を統一することで、上に書いたほうが弱く、下に書いたほうが強く、という分かりやすい構造にできます。

Bud...
p { ... }
.element h3 { ... }
.card a:hover { ... }
Good!
.element { ... }
.element__block { ... }
.link:hover { ... }

共通パーツにはmarginやwidthを指定しない

サイト全体で使い回すパーツには、余白や大きさ（widthとheight）は指定しないようにします。

使い回すということは、前後の要素との余白は場所によって変わります。大きさも親要素の100%になるときもあれば、固定値になる場合もあります。

なので、共通パーツ自体にはこれらのスタイルは指定せず、呼び出す場所の親要素でスタイルを制御します。

Bad...
// <button class="button">...</button>

.button {
  font-size: 20px;
  background: red;
  margin: 20px auto;
  width: 300px;
}
Good!
// <div class="search-button">
//   <button class="button">...</button>
// </div>

.button {
  font-size: 20px;
  background: red;
}
.search-button {
  margin: 20px auto;
  width: 300px;
}

コンテンツが変わっても崩れないようにする

テキストや画像は運用時に変わる可能性が高い部分です。特にCMSを導入している場合、開発者の思想通りにデータが入力されるとは限りません。

なので、テキストや画像は変わるという前提でスタイリングする必要があります。

テキストの場合、文字数が増減しても崩れないようにします。

text-overflowを使って特定行数以上は丸め込んで…にする（図の真ん中）、要素の大きさは固定値にせず文字数に応じて大きさが変わるようにする（図の右）、のように実装します。

画像の場合、縦横比や大きさが変わっても崩れないようにします。

縦横比や大きさがバラバラでも崩れないようにするには、object-fitやaspect-rateを使います。

.thumb img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  aspect-ratio: 4 / 3;
}

marginの向きは片方に統一する

ページ内でmargin-topとmargin-bottomが混在しているとマージンの相殺が起きたりして、思うように余白が取れないことがあります。なので、marginの向きは上下どちらかに統一するようにします。

iframeにはmax-width:100%を付けておく

記事詳細ページなどに、リリース当初はiframeの外部埋め込みコンテンツが無くても、運用時に追加されることはよくあります（ブログなどではありがちです）。

iframeには基本的にwidthがインラインスタイルで定義されているので、画面幅が小さくなった時にコンテンツ幅からはみ出してしまうことがあります。CMS系のサイトの場合、このようなレイアウト崩れに気づかずそのまま記事を公開していた...なんてこともよくあります。

このようなことを防ぐために、リリース当初はiframeが無くても保険としてmax-width: 100%を指定するようにしています。

.post-content iframe {
  max-width: 100%;
}

ブレイクポイントは有名所を真似する

ブレイクポイントの指定が無い時は有名なフレームワークを真似します。私がよく参考にしているのはBootstrapとTailwindです。

また、ブレイクポイントの数値は変数化しておくことで保守性が高まります。

scss
$breackpoint_sm: 640px;
$breackpoint_md: 768px;
$breackpoint_lg: 1024px;
$breackpoint_xl: 1280px;

remは使わない

remを使うと、ブラウザの文字サイズ設定や拡大縮小率に応じて、サイト上の文字サイズも変わるのでアクセシビリティ的には良いことです。

しかし、remの理解度は人によって様々です。正しく理解している人もいれば、間違った理解をしている人も数多くいます。

また、フォントサイズはremにするとして、他の余白や幅の単位はremにする？しない？などルールを統一して、メンバー間でそれを守るのも難しいです。初期開発時にはルールを守れていても、運用時に崩れることも多々あります。私はこれまでにそのようなプロジェクトを何度も見てきました。

「remは使わない」と書きましたが、メンバー全員が正しく理解をしていて、ルールもしっかりと守れるような体制であれば全然使って大丈夫だと思っています。

https://shibajuku.net/font-size-still-relative/
https://webdou.net/font-rem/
https://qiita.com/NagayamaToshiaki/items/77e929d855d052863a85

Sassの運用ルール

Sassは使いこなせば強力な味方になる反面、人によって書き方や知識がバラバラなのでカオス化する可能性もあります。自由になんでもできるからこそ、しっかりとしたルールを設けることが重要です。

SCSS記法を使う

SASS記法ではなく、SCSS記法にする理由は3つあります。

  • プロパティの自動並び替えができる（環境構築編で解説した内容です）
  • 書き方に馴染みがあるので、他メンバーの学習コストが低い
  • 既存のCSSをそのままSassに移管できる

正直なところ、SCSS記法にする理由の9割は「プロパティの自動並び替え」ができるからです。これまではプロパティの順番を意識しながらコードを書いていたので、このプラグインを導入して自動化することで圧倒的に楽になりました。さらに、メンバー間の書き方の統一もできるので可読性や保守性も高まります。

{}を使わないインデントベースのSASS記法は個人的には大好きなのですが、この書き方は馴染みが無いと結構苦労するみたいです。なので、少なくともチームで開発する時はSCSS記法のほうがいいのかなと思っています。

使い回す値は変数化する

ブレイクポイントの数値、メインカラーなどの頻出色、固定ヘッダーの高さ、画像フォルダのパス、一部分のみで使うfont-familyなど、使い回す可能性がある値は変数化することで修正に強い設計になります。

変数の例
// ヘッダーの高さ
$header_h_lg: 70px;
$header_h_sm: 64px;

// ブレイクポイント
$breackpoint_sm: 640px;
$breackpoint_md: 768px;
$breackpoint_lg: 1024px;
$breackpoint_xl: 1280px;

// 画像パス
$path_img: '../img/';

// 色
$color_primary: #f00;
$color_secondary: #00f;

&__でクラス名を省略するのは禁止

アンパサンド（&）を使ってクラス名を省略するのは禁止にしています。よくTwitterで議論になる問題ですね。

.element {
  &__block { ... }
}

この書き方が楽なのは分かりますが、楽以外にメリットが無く、それ以上に「クラス名で該当するSassファイルを検索できない」という大きなデメリットがあります。

触りたいSassファイルを探すために、HTML上のクラス名をコピーしてファイルを横断して検索をしても、&__でクラス名を省略をしていたら検索にヒットしません。

仮にBEMの.block__elementのような書き方をしていたら、.block部分で検索をかければファイル自体は見つかると思います。その後、そのファイル内で__elementで検索をかければ該当の行も見つかりますが正直二度手間です。また、以下のように書かれていたら見つけるのがより困難です。

.list {
  &__item {
    &Title { ... }
    &Body { ... }
    &Thumb { ... }
  }
}

// CSSは .list__itemTitle { ... } のようにコンパイルされる

この場合、__itemTitleで検索をかけてもヒットしません。&の使い方によっては、編集したい該当箇所を見つけるのに時間がかかってしまいます。

自分で書いたコードなら最初は特に困らないと思いますが、何ヶ月か経ったら当時の書き方なんて忘れています。ましてや、複数人のプロジェクトなどで他人が書いたコードの場合、なおさら見つけにくいし複雑に感じるはずです。

いつ誰が見ても分かりやすいコードにするためにも、&でクラス名を省略するのは辞めたほうがいいと私は思っています。

メディアクエリはネストしてmixinで書く

メディアクエリはmixinで定義して、引数で画面幅を指定できるようにしておきます。

mixin.scss
@mixin min-screen($breakPoint) {
  @media (min-width: $breakPoint) {
    @content;
  }
}

変数専用のファイルでは、ブレイクポイントを定義しておきます。

variables.scss
$breackpoint_sm: 640px;
$breackpoint_md: 768px;
$breackpoint_lg: 1024px;
$breackpoint_xl: 1280px;

実際にメディアクエリを使う際は、先程のmixinを呼び出して、引数にブレイクポイントの変数を指定します。こうすることで、最小限のコードで変更に強いメディアクエリになります。

呼び出し先
.block {
  width: 200px;
  @include min-screen($breackpoint_md) {
    width: 100%;
  }
}

JavaScriptの実装ルール

DOMツリーの構築が完了したら実行する

JavaScriptのファイルはサイトパフォーマンスの観点から、<head>でdefer属性を付けて読み込ませます。なので、DOMツリーの構築が終わったタイミングで処理が実行されるように、addEventListener()のDOMContentLoadedイベントを使います（こうしないと要素が取得できないことがあるため）。

window.addEventListener('DOMContentLoaded', (event) => {
  // 処理
});

https://www.javadrive.jp/javascript/event/index15.html

要素を取得する時はクラスセレクタを利用しない

JavaScriptで要素を取得する時はクラスではなく、idかカスタムデータ属性を使います。

https://into-the-program.com/dataset/

クラス名は修正や運用時に変わる可能性が高いので、それによってエラーが起きる可能性があります。なので、クラスはスタイルのためだけに使い、要素の取得はidかカスタムデータ属性を使います（スタイルと要素取得のセレクタを完全に分離する）。

idは接頭辞にjs-を付けることで、JavaScriptで使われていることが明確になります。カスタムデータ属性はJavaScriptが絡む場所でしか使わないので、わざわざdata-js-○○のようにしなくてもいいかなと思っています。

同じ値のidはひとつしか使えないので、取得する要素がひとつの場合はidを、複数の場合はカスタムデータ属性を使います。

要素を取得する例
document.querySelector('.foo'); // Bad...
document.querySelector('#js-foo'); // Good!
document.querySelectorAll('[data-foo]'); // Good!

画面幅が小さい端末は表示倍率を縮小する

昨今のスマホデザインは375px〜400px付近で作られることが多く、この数値のまま実装すると、画面幅が小さい端末（320pxなど）ではレイアウトが崩れる確率が高いです。

なので、スマホデザインの画面幅数値以下の時は、meta viewportで表示倍率を縮小させます。

const adjustViewport = (triggerWindowWidth = 370) => {
  const metaViewport = document.querySelector('meta[name="viewport"]');
  const viewportValue =
    window.outerWidth < triggerWindowWidth
      ? `width=${triggerWindowWidth}, user-scalable=no, target-densitydpi=device-dpi`
      : 'width=device-width, initial-scale=1';
  metaViewport.setAttribute('content', viewportValue);
};

window.addEventListener('DOMContentLoaded', () => {
  adjustViewport(); // 引数に画面幅の数値を与えると、その値が画面幅が縮小される起点になる
});

どのような挙動になるかは、LIGさんの記事を読めばイメージできると思います。

https://liginc.co.jp/451892

PHPで効率化

共通パーツはファイルを切り分ける

ヘッダー、フッター、メタタグ系はほぼ全てのページで同じものを読み込ませるので、複数ページのサイトの場合は共通パーツを別ファイル化して、それを読み込ませるような構造にします（WordPressのような構造を普通のサイトにも取り入れるイメージです）。

index.php
<?php include(__dir__ . '/module/header.php'); ?>

<div class="l-index"> ... </div>

<?php include(__dir__ . '/module/footer.php'); ?>
module/header.php
<?php include(__DIR__ . '/_config.php'); ?>

<!DOCTYPE html>
<html lang="ja">
  <head>
    <?php include(__dir__ . '/head.php'); ?>
  </head>
  <body>
    <div class="l-wrapper">
      <header class="l-header" id="js-header"> ... </header>
      <div class="l-main">
module/footer.php
      </div> <!-- / .l-main -->
      <footer class="l-footer"> ... </footer>
    </div> <!-- / .l-wrapper -->
  </body>
</html>

繰り返し系のコンテンツは繰り返し文を使う

繰り返し系のコンテンツ（リストやブログ記事一覧など）は、PHPのforやforeachを使って実装します。こうすることで、クラス名や構造を変える時の修正範囲は一箇所のみになり、コンテンツの増減も直感的に行えるようになります。

以下のようにHTMLだけで書くと、クラス名を変える時は繰り返すコンテンツの数だけ修正が必要で、記事を増やす時はどの部分を修正してどの部分は修正しなくていいのかが分かりにくいです。

HTMLだけで書いたブログ記事の一覧
<a href="path/to/link/1..." class="article">
  <h3 class="article__title">クラウドコンピューティングの進化</h3>
  <img class="article__thumb" src="path/to/img/1..." alt="">
</a>
<a href="path/to/link/2..." class="article">
  <h3 class="article__title">IoTの最先端 スマートシティとは</h3>
  <img class="article__thumb" src="path/to/img/2..." alt="">
</a>
<a href="path/to/link/3..." class="article">
  <h3 class="article__title">5Gネットワークのパフォーマンス解析</h3>
  <img class="article__thumb" src="path/to/img/3..." alt="">
</a>

PHPの連想配列とforeachを使うことで、修正は楽になり、コンテンツを増やす時の修正範囲も直感的になります。

foreach文を使ったブログ記事の一覧
<?php
  $data_article = [
    [
      'title' => 'クラウドコンピューティングの進化',
      'href' => 'path/to/link/1...',
      'img_src' => 'path/to/img/1...',
    ],
    [
      'title' => 'IoTの最先端 スマートシティとは',
      'href' => 'path/to/link/2...',
      'img_src' => 'path/to/img/2...',
    ],
    [
      'title' => '5Gネットワークのパフォーマンス解析',
      'href' => 'path/to/link/3...',
      'img_src' => 'path/to/img/3...',
    ],
  ];
  foreach ($data_article as $article) :
?>
  <a class="article" href="<?php echo $article['href']; ?>">
    <h3 class="article__title"><?php echo $article['title']; ?></h3>
    <img class="article__thumb" src="<?php echo $article['img_src']; ?>" alt="">
  </a>
<?php endforeach; ?>

おわり

最初にも書きましたが、ここで紹介した内容はあくまで私個人の手法やルールであり、また、全てのプロジェクトに取り入れているわけではないです。必要に応じてルールを変えたり柔軟に対応しています。

ここで紹介した内容がひとつでも参考になって、皆さんのコードや開発環境が良くなってくれれば嬉しいです。

今回は長くなりすぎないように30に絞って紹介しましたが、紹介したいことや書きたいことは倍以上あります。それはまた他のどこかで紹介できたらと思います。

Discussion

マイコ78マイコ78

dadadaさんはじめまして！コーダー目指して2年目の40代です。
こちらの記事すごく気に入りましてdadadaフォルダを作りブクマしました。
1年前では決して理解できなかったことで有益なことがたくさん学べて感謝いたします。
今・HTMLでマークアップ　のところまで熟読いたしました。
特に
「仕様書やデザインデータの確認」
「画像のディレクトリ構成」
「サイトパフォーマンスを常に意識する」
をこれからより注意していきたいです。
ありがとうございます！！

月槻ツキ月槻ツキ

プロジェクト対応の中でのあるあるがきれいにまとめられてすごく勉強になりました。
共感も数多くありました。
１点だけBEMの「&__でクラス名を省略するのは禁止」に関して、私も検索にヒットしないというデメリットは認識しつつもそちらを重要視していませんでした。BEM記法なのでクラス名が長くなると各セクションごとの役割を目で追うのが大変で、こちらこそデメリットと考えています。またそれほど深度が高くなるとコンポーネントの切り出しタイミングだと考えているので、その時の移行も簡単です。どうしてもクラス名をフルで見たい時はdevtool側で代用できますので、素直にSCSSの省略の恩恵を受けてもいいかな～と考えていました。意見の押し付けでなく、また違った視点だなぁと思ったために書き込みさせていただきました。
素敵な記事をありがとうございます。