もうコーディング規約を作るのはやめよう

はじめに

突然ですが、みなさんの会社またはチームでは、コーディング規約を作っていますか？

私の所属する会社でもコーディング規約を作っているのですが、最近になって「コーディング規約ってわざわざ作る必要はないのでは？」と思うようになりました。

誤解のないように言っておきますと、コーディング規約がいらないと言っているわけではなく、コーディング規約を「作る」という行為が不要なのでは？ということです。

主要なプログラミング言語のコーディング規約は、WEB 上で公開されています。

各プログラミング言語のコーディング規約まとめ
https://qiita.com/moaible/items/134329123074337913fb

選択肢としては、

• すでに公開されているコーディング規約を使う
• 自分たちで新しいコーディング規約を作る

のいずれかになると思いますが、私は「すでに公開されているコーディング規約を使う」べきだと考えています。

その理由を以下にまとめます。

すでに公開されているコーディング規約を使うべき理由

使うプログラミング言語の種類が増えた

もはや「Java だけできれば良い」という時代ではなくなりました。

例えば、一つの Web サービスを開発するにしても、バックエンドとフロントエンドでは別のプログラミング言語を使うのは一般的です。

さらにスマートフォンアプリにも対応するのであれば、iPhone と Android でそれぞれ別のプログラミング言語を使う必要があるかもしれません。

複数のプログラミング言語を使うということは、それだけたくさんのコーディング規約が必要になります。

そのコーディング規約、全部作りますか！？

プログラミング言語のバージョンアップが早くなった

私がプログラミングをはじめた頃、「C言語」というプログラミング言語を使っていました。

C言語は、ANSI が 1989 年に策定した「C89/C90」というバージョンが、最初のバージョンになります。

その後、1999 年の「C99」、2011 年の「C11」と 2 回改定しています。

つまり、C言語は 10 年に 1 回程度しかバージョンアップしていません。

しかし、最近よく使われているプログラミング言語を調べてみると、最近登場したプログラミング言語ほど、バージョンアップの頻度が高いことがわかります。

プログラミング言語	最初のバージョン	最新のバージョン	更新頻度
C	C89/C90（1989 年）	C11（2011 年）	2回/22年
Java	JDK 1.0（1996年）	Java SE 10（2018年）	10回/24年
C#	1.0（2002 年）	7.2（2017 年）	9回/15年
Python 3.x	3.0（2008 年）	3.6（2016 年）	6回/8年
Swift	1.0（2014 年）	4.1（2018 年）	9回/4年

それでは、プログラミング言語のバージョンアップによって増えた仕様のコーディング規約はどうするのでしょうか？

これだけバージョンアップの頻度が高いと、そのつどコーディング規約を変更していくのは、けっこう面倒くさそうです。

かと言って、「コーディング規約を変更するのが面倒くさい」という理由で、新しいバージョンを使うことが億劫になってしまうのでは本末転倒です。

オープンソースが普及した

今では、Web、モバイル、クラウド、AI、IoT といった様々な分野でオープンソースが使われるようになりました。

つまり、「自分たちが作ったコード」と「自分たち以外の人が作ったコード」を一緒に扱う時代になったということです。

「自分たちが作ったコード」と「自分たち以外の人が作ったコード」は、同じコーディング規約でコードが書かれていることが理想的ですが、実際そんなにうまくいくことはありませんよね。

標準的なコーディング規約を使っていれば、自分たちがスムーズに読めるオープンソースのコードが増えます。

これは大きなメリットではないでしょうか。

プログラミング言語が高度化した

私がプログラミングをはじめた頃は、どのプログラミング言語もシンプルでした。

例えば「C言語」には、

クラスはありません。
例外はありません。
ジェネリクスはありません。
型推論はありません。
ラムダ式はありません。
動的型付けはりません。
非同期処理はありません。

つまり、オブジェクト指向言語や関数型言語の考え方が一切ありませんでした。

最近プログラミングをはじめた人からは「逆にC言語には何があるの？」と聞かれてしまいそうですね・・・

プログラミング言語は、ここ最近の 10 〜 20 年で大きく進化し、同時に仕様も膨大になりました。

進化したプログラミング言語のコーディング規約を作るのは大変です。

その言語仕様をすべて把握し、さらに今後のバージョンアップで変更される仕様も知っておく必要があります。

コーディング規約を作る労力が大きくなってしまったことで、せっかく時間をかけてコーディング規約を作ったのに、全くメンテナンスされないため、役に立たないものになってしまったという話も聞いたことがあります・・・

さいごに

C# の言語仕様自体には
細かいコーディング規約はありませんが、
私はマイクロソフトのコーディング規約に則っています💡

もし興味がありましたらこちらからどうぞ💁‍♀️
ネタツイートにもちゃんと綺麗なコードを。
ーー
C# のコーディング規則 (C# プログラミング ガイド)https://t.co/q4MxqJyLeO

— ちょまど@プログラマ兼マンガ家 (@chomado) 2018年5月25日

このツイートで、C# の生みの親であるマイクロソフト社でさえ、標準のコーディング規約で十分だということに気づきました。

Java や C# でハンガリアン記法を使っているような時代遅れなコーディング規約もたまに見かけるので、よく検討しないままコーディング規約を作ってしまうというのも、結構ありがちなことなのかもしれませんね・・・

たかがコーディング規約と思わず、メンテナンスコストやデリットのこともよく考えて、本当にコーディング規約を作る必要があるのか、十分検討することが大切だと思います。