目次
- スピーカー紹介
- ぶっちゃけ！コーディング規約どうしてる？
- コーディング規約の管理方法について
- コーディング規約の盛り上がりポイント！
- まとめ
スピーカー紹介
はじめに、今回コーディング規約についてお話ししてくれた主なスピーカーの紹介をします。
toshiyaさん
- 株式会社博報堂アイ・スタジオ
- テクニカルディレクター（toshiyaさんが書かれたテクニカルディレクターに関する記事がすごいです。詳しくはこちら→https://frontendclub.org/blog/what-is-technical-director/）
- 私の大先輩
satoさん
- 株式会社FLAT
- 代表
coppeさん
- 某ソーシャルゲームを開発するサービス会社
- フロントエンドエンジニア
- 新米パパ
ぶっちゃけ！コーディング規約どうしてる？
ここではスピーカーさんそれぞれが所属している会社でのコーディング規約の実情についてお話ししてくださいました！
toshiyaさん
僕の会社では、得意先の要望に合わせて開発を進めていくことがほとんどです。得意先の環境に納品したり、得意先によって要件がバラバラなことが多く、コーディングに関する明確な規約はないですね。
ただやはりコーディング規約は意識していて、ESlint（イーエスリント）をはじめとしたLinter（リンター）や、Prettier（プリティア）といったCode Formatterは導入しています。
命名規則についても明確なコーディング規約はないのですが、会社の文化的にメンバー間の繋がりが密なためか、意図せずともみんなコードが似通っていて、BEMやAtomic Designの思想に基づいて命名することが多いですね。
satoさん
私の会社でもドキュメントとして作成された規約というよりはLinterやFormatterに頼ることが多いですね。主にHTMLにはMarkuplint、CSSにはStylelint、JavaScriptにはESlintといったLinterを導入しています。
ただ簡単なドキュメントもあり、簡単にではありますが、画像やクラスの命名規則について統一しています。具体的には「単語を省略しない」「名詞と修飾詞で命名する」ということを定めています。
コッペさん
僕の場合は、とにかくプロジェクトの息が長いし、サービスの規模も大きい。エンジニアの出入りが激しい現状もあるからコーディング規約は必須ですね。コーディング規約があることで、新しくプロジェクトに入った人でもなぜ過去のコードがそう書かれているのかがわかるようになっています。逆に規約を破って実装すると、どこかでバグが起こるなんてこともありますね。
コーディング規約が改定されるときもありますが、それは「ユーザーに明確なメリットがあるか」という基準で判断されることが多いです。エンジニア側の書きやすさや流派では判断されないですね。
ここまで、それぞれの会社でのコーディング規約の実情について聞きましたが、コーディング規約がより必要とされる現場とはどんな現場なのでしょうか。
コッペさん曰く、「同じもの多くの人で入れ替わり作るということではないか」とのことでした。
確かに、私は新卒で、主にLPを制作することが多いですが、分担をしたとしても一つのプロジェクトに関わる人数は2〜3人なので、コーディング規約がなくても互いに察してコードを揃えられているような気がします。
また、toshiyaさんは、大きなサイトでは開発に1年以上かかることもあるそうですが、人が入れ替わることはあまりないため、それほどコーディング規約が定められていないくても気にならないのかも、と仰っていました。
コーディング規約の管理方法について
toshiyaさん
僕の会社ではGitLabを使用していて、wikiやReadmeにコーディング規約を書いていく文化があります。僕自身、以前コーディング規約を作成する際のベースのセットを作ったことがあり、それを元にコーディング規約を書いている人も多いですね。
satoさん
私の会社ではNotion（ノーション）を使ってコーディング規約を管理しています。Readmeもありますが、それとは別に規約を作って管理をしています。案件ごとにコーディング規約を決めることもあります。また、私の会社はウェブアプリもWebサイトも開発するので、案件ごとにコーディング規約があったりなかったりすることもあるのですが、Notionはとても管理しやすいですよ。
コッペさん
僕はRedmineを使っているので、そこのwikiに書いてますね。規約自体はチームのメンバーで管理されてます。会社全体で明確なコーディング規約が決まっているわけではないけど、他の案件たちにも共通してる規約はありますね。僕の会社の場合はコーディング規約は必要ですが、最大の目的は事故を起こさないことなので、また少し他社さんとは異なっているかもしれませんが。
お話を聞いて、会社によってコーディング規約の管理方法はバラバラではありますが、プロジェクトを管理するシステム上のwikiに規約を書くことが多い印象を受けました。
そして、コーディング規約といってもその目的は一つではないこともわかりました。
コッペさんの会社では、コーディング規約は必須なものだとおっしゃっていましたが、あくまでコーディング規約を定義する最大の目的は「事故を起こさないこと」だそうです。
私はコーディング規約というと、「コードに統一性を持たせる」という目的が主なるものだと思っていました。
コーディング規約はやったほうがいいからやるのではなく、プロジェクトの目的に沿ってより良いアウトプットを実現するためにコーディング規約を活用していくべきだと思いました。
コーディング規約の盛り上がりポイント！
今回のトークイベントはスピーカー以外の皆さんも気軽に参加できるイベントとして開催し、多くに方がコメントをしてくれたりDiscordのステージ（発言ができる場所）に上がってくれた方もいました！
皆さんの会社でもやはりコーディング規約はホットな話題なようで、会社で検討中だったり、意識しようとしているという方が多くいました。
とくに今回盛り上がったのは、画像やクラス命名時の「連番」、そして「BEM」です。
まず、画像やクラス命名時の「連番」については、その可否に関する意見が熱く交わされました。
連番賛成派からは、「実装がしやすくなる」という意見が多く、連番反対派の意見としては、「画像を番号にしてしまうと、内容がわからなくなる」ことや、「更新などで番号がズレたときの気持ち悪さ」が挙げられました。
ちなみに私は連番反対派です。
次に、「BEM」に関しては、皆さんの多くがBEMの思想に基づいて命名していることがわかりました。
どこまで「BEMに従うべきなのか」、「BEMはわかりやすいのか」といった話題に多くの意見が挙がりました。
私はどうしてもBEMというとSassの入れ子にCSSを書いていくイメージとの繋がりが強かったのですが、皆さんのお話を聞いて、BEMの思想に沿って命名をすることと、Sassで入れ子にスタイルを書いていくことは全くイコールではないことがわかりました。
BEMを採用するメリットとして、もちろんSassの入れ子で書いていくことでの安全性も挙がりましたが、他には、外部の会社に依頼する際に、すでに広く認知されているBEMをコーディング規約を採用することで、依頼する側もされる側も理解がしやすいという利点も挙がりました。
やはり私のようにBEM＝Sassのイメージを持っている方が多いのか、入れ子でスタイルを書くために検索をしても該当してくれないことというデメリットが挙がりましたが、一部ではBEMに沿って命名しても、スタイルは入れ子にしないという方がいらっしゃいました。
まとめ
よく「コーディング規約って結局なんなの？」という意見を聞きますが、私は今回のトークイベントを通して、コーディング規約に明確な定義は必要ないのではないかと思いました。
もちろん、LinterやFormatterでコードを正確なものにしたり、命名規則を定めてコードを統一したりという基本の型のようなものはありますが、会社や案件の目的に合わせて、必要と考えられるルールをコーディング規約として独自に定めていくことで、よりそれぞれの強みを生かした開発ができるようになるのではないかと思いました。
そのように考えると、やはりコーディング規約はどんな案件においてもあったほうがいいものだと思います。規模にかかわらず、コーディング規約を定めることがより良いアウトプットにつながると思うからです。
フロントエンドクラブには、今回のイベント中にも話題に挙がっていたHTMLのLinterであるMarkuplintの開発者であるゆうてんさんがいらっしゃったり、そのほかにもそれぞれの方面に精通された方々が多数参加してくださっています。
なんでも聞きたいことがあれば答えてくれる、なんでも話したいことがあれば自由に話せる、そんなコミュニティがフロントエンドクラブです。
ぜひ気軽にDiscordに参加して、たくさん社外の同僚を見つけていただけたら幸いです！
来月もトークイベントを開催予定ですので、皆さんの参加をお待ちしております！
.png)
