コーディング規約は制作会社であれば作っていると思いますが、その目的は「保守性」と「品質」の確保することです。コーディング規約があると、ファイルの格納場所やインデント・コメントの書き方、クラス名の付け方などがほぼ同じになり、誰か別の人が作業するとなったときも、すぐに内容を理解して作業に取り掛かることができますし、書き方も同じなのでその後のメンテナンス性も保たれていきます。

ただし、最初に作ったコーディング規約が何年も更新していないのであれば、情報が古く逆に邪魔になってしまうこともあるので、定期的に見直しをする必要があります。

今回は年末ということもあり、ハズムのコーディング規約を見直そうということになったので、そのときの項目の一部をまとめてみました。

目的の明示

目的としては上にも書いたように「保守性」と「品質」の確保ですが、具体的に何するの？とか、それらを守ることで何が良いのか等を書いていきます。

コーディングに限らずですが、なぜそれを守る必要があるのかというのを知っているのと知らないのでは意識・行動がかわってくると思うので、目的は明確にすることが望ましいと思います。

ディレクトリ構成

ファイルを保存するフォルダの階層構造や名前を決めておくと、画像がどこにあるかを探す手間が省け、ミスも減ります。
共通で使用するファイルなども、ひと目で分かるような名前や他のファイルとは別にして管理をすると楽になります。

命名規則

コーディング時のIDやクラス、変数名や関数名、他には各ファイルの名前等の命名規則を決めておくと、探すのも楽だし名前をつけるときに悩まなくなります。名前をつけるときはその名前から何の要素なのか、何のファイルなのかがすぐに分かるように明確な名前をつけると良いです。

規約に関しては公開している企業もあるので検索してみてください。

コーディングスタイル

これはインデントとかコメント、括弧の位置や内容等を決めます。ソースコードを見たときにインデントがバラバラだったりすると見辛いですし、タグの閉じ忘れや予期せぬエラーの原因になったりします。

最近ではSassを使用しているので、Sassの書き方や変数名なども含めて追記しています。

禁止事項を決める

やってはいけない書き方やほとんど使われていなくなっているもの等を書きます。絶対禁止という訳ではなく、場合によっては例外的に使用することも想定しておきます。これもただ禁止するのではなく理由も書いておきます。

最後に

何度も言いますが、コーディング規約は「保守性」と「品質」の確保することを目的としています。しかし、ガチガチに固めてしまうとできることもできなくなってしまったり、逆にコーディングが大変になり生産性が落ちてしまう、ということもあるかもしれません。また情報が古いままだと新しい技術や環境に対応できなくなるので、定期的な見直しが必要になります。

コーディング規約は必要最低限の部分で考えつつ、細かい部分はプロジェクト毎に決めていき、負担を減らしつつ作業の効率アップになるようなものを作っていきましょう。