職場にコーディング規約を設けた

目次

• 手順
• 所感
• 疑問点
• まとめ

弊社、今までコーディング規約がなかったことでよりどりみどりなコードがとっ散らかっている。綺麗。しかも管理ページが異常に多く、それら全てが多種多様な個性を放っている。素敵。

コーディング規約を制定するとコードを書く際の心理的負荷に繋がりそうな反面、読む際の心理的負荷は一定は取り除かれるような気がする。弊社は定着率が高くないため、だったら後々の人たちが読んだり修正したりする際の心理的負荷が低い方が良さそうだなということで制定を検討。

前任に「制定しなかった理由はあったか、すべきでない理由はあるか」訊いてみたところ「しない理由はない」との後押しをもらったけどだったら僕なんかよりあなたがしてくれたらよかったのに！という想いが溢れた。

手順

僕は優れたエンジニアでないし経験値も全くないので、とにかく規約に関する情報をネットや本で漁りに漁った。とりわけ CSS はものすごく散らかってるので、設計的なところは意識しなければならなそう。

また、僕自身が特に綺麗なコードを書けているわけではないので、そこらへんもブラッシュアップしていかないといけない。せっかくの機会なので名著と名高いリーダブルコードを読んだ。

「今後ももしかすると数年、数十年、この規約に沿われてコーディングされるのかもしれない」と思うと規約の制定というのは小心者の僕には荷が重い作業ではあった。ただいろいろな情報を頼りにし、それらを弊社の現環境と給与レンジで集まりそうな人材のレベルに沿ってそうなものをなんとか一通り制定。

所感

業務用システムの開発において、システムの開発者はそのシステムの使われる業務に関して一番詳しくあるべきだ。でないと、機能面での見落としや拡張性の不足、ユーザビリティの低下など招きかねない。コーディング規約にも似たものを感じる。現行のコードやよく使用される表現、環境などを熟知してなければならない。

僕も入社半年と少しが経ち、それなりに知るところも多くなっていたのでちょうどいい機会だったのかもしれない。

疑問点

• CSS のプロパティのソートに関してはやや迷った。どうするのがベストなんだろう。まぁ CSScomb という便利なプラグインがあるのでソートはそいつに一任し、そこまで意識しなくてもいいのかもしれない
• 見やすい/見にくいの基準というのはそもそも人によるため、制定者（僕）のエゴにならないか気になった。そこが気になってしまった時点でやや偏ってしまった気もする。ただ、この問題は『現在在籍する人材の声を適宜柔軟に反映させて規約を変化させていく』ことを前提として解消できたかなとも思う

まとめ

頑張った