コーディング規約とは？プログラマが守るべきルールとどのように付き合うべきか
コーディング規約とは、プログラムや情報システムを作る時に、プログラマたちが守るよう決められたルールのことです。
コーディング規約がカバーする範囲は、プログラムがどう作られるべきかということです。
コーディング規約の大きな目的は「保守性」「品質」の確保です。コーディング規約のありなしと、コーディング規約がしっかりと守られているかは、プログラムの保守性・品質にとってとても大切なことなのです。
ただ、コーディング規約にも良し悪しや理想と現実との乖離が残念ながらあります。また、実際には理不尽なものもあったりして、「こんなものを守っていられるか!!」と感じつつも作業している人は多いでしょう。
この記事では、コーディング規約について、どういうことが決められているのか、どういう観点で必要なのかを、プログラミングの初心者やプロジェクトに初めて参加するような方向けに分かりやすくお伝えします。
１．コーディング規約はプログラマが守るべきルール
コーディング規約(coding conventions)とは、プログラムや情報システムを作るプログラマが守る、「プログラムはどう作られるべきか」というルールです。チームやプロジェクト、会社などで決められています。
コーディング規約は、プログラムや情報システムを作る作業のより広い範囲をカバーする、プロジェクト標準や開発標準と呼ばれるルールの一部でもありますが、それらと境目があいまいな部分もあります。
なお、コーディング規約はコーディングスタイル(coding style)と区別しないで扱われることがあります。でも、この記事ではコーディング規約とコーディングスタイルは違うものとして扱いたいと思います。
関連記事
１-１．コーディング規約で決めるルール
コーディング規約で決められているルールはいろいろとある中で、多くのチームやプロジェクトで共通しているのは以下のものです。これらのルールがあることで、プログラムを作る作業がスムーズに進むのです。
- コーディングスタイル(改行、空白、名前などのルール)
- プログラム(画面、バッチ、帳票、APIなど)の標準的な作り方
- プログラムを作る上での推奨事項、禁止事項
- その他、プログラムを作る時のルール全般(レビューの仕方やプログラムの管理方法など)
１-２．コーディング規約はプログラムの保守性と品質を高める
コーディング規約はプログラムの「保守性(maintainability)」と「品質(quality)」を高めます。プログラムには可読性(readability)も大事なのですが、可読性は保守性や品質を高めるためにも必要なものです。
ここで保守性や品質という言葉は少々抽象的に感じられますが、おおよそ以下のようなことです。プログラムを作る時にコーディング規約があると、これらのことが実現できるようにもなるのです。
保守性
- プログラムを誰でも理解できる
- プログラムのバグを誰でも発見できて、修正できる
- プログラムへの機能追加を誰でも行える
- ずっと前に書かれたプログラムでも、すぐ内容を理解できる
- プログラマがプロジェクトに参加しやすくなる
品質
- バグが少ないプログラムを誰でも作れる
- プログラムを上手くいくことが分かっている方法で作れる
- コーディング規約が守られているかのレビューが行われる→ミスを複数の目で発見できる
- コーディング規約を守ることで、プログラマ自身の知識やスキルが強化される
１-３．保守性はチームでプログラミングするためにも必要
先程の一覧には「誰でも」という言葉が多いですよね。コーディング規約で保守性を大事にしているのは、プログラムを作ってメンテナンスする作業は、複数の、大勢の人が関わる「チーム作業」だからでもあります。
プログラムの保守性が大事なのは、プログラムは一回作ってそれで終わり…ではないからです。プログラムを作るのは人ですが、作った人とメンテナンスをする人が違うのはごく普通のことでもあるのです。
そして、プログラムの作り方は一つだけではありません。プログラマの数だけプログラムの作られ方があるとも言えます。でも、他のプログラマが作ったプログラムを読むこと、理解することは実はかなり大変です。
コーディング規約があれば、どのプログラマが作っても、全て同じような作られ方のプログラムにできるのです。ということは、赤の他人でもプログラムの理解やメンテナンスがしやすくなるかも…と思えませんか?
１-４．コーディング規約はコーディングスタイルを含む
コーディング規約は、コーディングスタイルをその中に含みつつ、より高く広いレベルで、特定のチームやプロジェクトにおいて、プログラマがプログラムをどう「作るべきか」の標準を決めたものでもあります。
コーディングスタイルは、プログラムがどう「表現されるべきか」を決めたものです。人により解釈は違いますが、何かのプログラミング言語で一般的な書き方や、好まれる書き方の「スタイル」をまとめたものです。
具体的には、コーディングスタイルはプログラムでの改行位置や空白の数、字下げ、括弧のつけ方、変数や関数の名前などのルールであり、プログラミング言語や、下手をするとプログラマごとにも違うものなのです。
２．コーディング規約で決められるルール
ここでは、コーディング規約についてもう少し具体的に触れていきましょう。
なお、この章を読む時に意識していただきたいのは、どのルールにも、多人数でプログラムを作る時に出るであろう問題をなるべく少なくしたい…という観点が含まれていることです。
２-１．コーディングスタイル
コーディング規約でコーディングスタイルを明確にすることで、誰が作ったプログラムでも見た目のレベルを同じようにします。これは、プログラムの読みやすさにもつながるものです。
例えば、以下のJavaプログラムはまったく同じもので、プログラムを動かすコンピュータにとっては違いがありません。でも、これらが同じものだとは、見た目からはすぐ判断できませんよね。私には無理です。
class TestMain {
public static void main(String[] args) {
System.out.println("Hello, world.");
}
}class TestMain {public
static void main(String[]
args) {System.out
.println("Hello, world."
);}}ここまで極端でなくても、改行や括弧の位置、空白の数などは、プログラマごとに好みが違います。そして、このような見た目が違うプログラムをたくさん読まなければならない時には頭がとても疲れてしまいます。
この他にも、プログラム中での変数名や関数名などのルールが違っていると、プログラムをすらっと読めません。ですから、個人の好みや主義は少し横に置いて、コーディングスタイルで見た目を同じにするのです。
２-１-１．例
コーディングスタイルでは、以下のことを決めたりします。いずれもプログラマなら一家言やこだわりを持っているものなので、ルールできっちり決めないとプログラム全体でバラバラになってしまいます。
- コメントの書き方：1行コメントと複数行コメントの使い分け、コメントへ記述すべき内容など
- インデントの付け方：インデントは水平タブか空白か、インデントの桁は何桁かなど
- 変数名の付け方：スネークケースかキャメルケースか、ハンガリアン記法を使うかなど
- 関数・メソッド名の付け方：スネークケースかキャメルケースか、引数の順番と個数の制限など
- プログラムファイルやクラス名の付け方
- 一行当たりの最大桁数や、関数・メソッド当たりの行数は何行までか
- ファイル単位の行数は何行までとするか
- 空白の配置ルール：プログラム中の空白はどういうルールでどこに何個置くか
- 括弧の配置ルール：プログラムの中で、()や{}などの括弧類をどう配置するか
- 改行位置のルール：プログラム中ではどの場所で改行をするか
- 空行のルール：どういう場所に空行を何行入れるべきか
- 変数の宣言場所、関数・メソッドがファイル内に出現する順番をどうするかなど
- 省略できる括弧を書くか書かないか
- プログラム中のネストは何段まで許容するか
重要なのは、使っているプログラミング言語で一般的なルールになるべく沿うことです。一般的なスタイルからあまりに離れていると、「なんだこれは?」とそればかり気になってしまうのがプログラマです。
２-２．プログラムの作り方
プログラムの作り方をコーディング規約であらかじめ決めることで、同じことは同じようにやるという、一見当たり前のことが初めて実現できるのです。これはルールをあらかじめ決めておかないと、実は難しいのです。
例えば、今はある程度以上に実用的なプログラムを作る時は、大体は何かのフレームワークを使います。フレームワークとは、出来合いの部品のようなもので、フレームワークの上に画面や帳票などを作るのです。
そのフレームワークの使い方がプログラム全体で同じにできていないと、同じような機能を作るのに、プログラマによりやり方が違うことになりかねません。すると、プログラムがお互いにわかりづらくなるのです。
２-２-１．例
ここでは、標準的な機能の作り方を決めることが多いと思います。例えば以下のようなものが考えられて、これらはプログラムのスタイルというよりも作り方と呼ぶ方がしっくりくるようなものです。
- 使用するプログラミング言語と仕様のバージョン
- プログラムを作るのに使うフレームワークやライブラリの種類とバージョン
- 画面/バッチ/帳票などを作る時の標準的なプログラムや作成すべきファイルの構成
- 画面遷移や帳票を出力する時などの標準的なやり方
- データベースやシステム外部のAPIへの標準的なアクセスの仕方
- プログラム中で用いる共通処理の作り方や、呼び出し方のルール
- プログラム上で参照するパラメータの管理の仕方
- プログラム上で表示するメッセージの管理の仕方
- プログラムを管理する際の名前空間などのルール
- エラー発生時の呼び出し元への伝え方、呼び出し元でのエラー処理の仕方
- いろいろな局面でのエラーチェックの仕方、エラー発生時の処理継続/中断ルール
- システム間連携をする時のデータフォーマット、手順など
これらがはっきり決められていないと、プログラマがそれぞれの処理を自分で勝手に作り始めてしまいます。そうなってしまうと、プログラム全体は大混乱に陥ってしまうのです。
２-３．プログラムを作る上での推奨事項、禁止事項
コーディング規約で推奨事項・禁止事項として事前に明確にしておくべきものがあります。こうすることで、プログラムにプログラマの知識や経験の差による違いがなるべく出ないようにするのです。
残念ながら、プログラマの知識や経験、実力には「差」があります。その差のせいでプログラムにも差が出ますし、最悪は上級者が作ったプログラムを中級者・初級者が全然理解できない…ということも起きます。
プログラムを作る上では定石やノウハウがたくさんあります。また、プログラミング言語のいろいろな機能やライブラリも、みんながぜひ使うべきものはありますし、中には上級者向けの難しいものもあります。
そして、逆にこんなプログラムの作り方をするとバグになる可能性が高い、というノウハウもたくさんあるのです。でも、それらは実際に痛い目を見た人が身に着ける知識でもあり、知らない人は全然知りません。
２-３-１．例
ここでは、より効率的・品質の高いプログラムを作るために使うべきテクニックや、逆にこれはやってはいけないということを明確にしていきます。
- プログラミング言語上の機能は何をどこまで使用可能とするか(習熟度に差があると想定されるもの)
- プログラミング言語上の仕様上にある、古い・新しい機能の使用可否
- プログラム上でよくある処理を行う時の共通ルール、テンプレート
- デザインパターンを使う場合は、どういうケースでどのパターンを使うのか
- 複数データを扱う時は、配列を使うのか、コレクション型を中心に使うのか
- 事前調整なしで使用できる演算子はどの種類までとするか
- 避けるべきアンチパターンと、アンチパターンに陥りかけている時の対応方法
- マジックナンバーやマジックストリングなどのハードコーディングの禁止
- 例外通知メカニズムの想定外の使い方の禁止
これらは一例にすぎません。経験を積んだプログラマはこれらの良し悪しや使うべき理由、使わないべき理由を理解していますが、経験が浅いプログラマは適切な判断ができず自己流となってしまいます。
２-４．その他のルール
プログラムそのものの他にも、プログラムを多人数で作る時には決めておくべきルールがあります。
これらはコーディング規約の中に入らない場合もありますが、いずれにせよプログラムを作る作業をスムーズに進めるために、事前に決めておくべきものであることには変わりません。
２-４-１．例
これらはごく一部ですが、決まっていないと作業の進捗に影響が出るようなものもあるのです。プログラムを作る作業そのものというよりも、プログラムの周辺にある作業のルールという方が良いでしょう。
- プログラムを作った後の査閲・承認のルール(それぞれができる権限を持つ人はだれか)
- プログラムをレビューする時の手順、レビュー指摘対応を確認する時のルール
- プログラムをバージョン管理システムに登録したり、内容を更新する時のルール
- バージョン管理システム上でのタグ付けやブランチ管理のルール
- プログラムをビルドしてテスト環境にリリースする時のルール
- プログラムのバグを見つけた時の報告ルールや作業ルール
- 単体テストや結合テストなどでバグが発見された時の報告ルールや作業ルール
- プログラムに付随するドキュメント類の作成・更新ルール
３．意味のあるコーディング規約はどんなものか
コーディング規約を定めているプロジェクトはとても多いです。会社で標準として決まっていることも普通です。でも、誰からも相手にされず、空気のような存在のコーディング規約も実際多いのです。
ここでは、どんなコーディング規約ならプログラマの支持を集めて使われるのか、というポイントを簡単にお伝えします。もしあなたの目の前にあるコーディング規約がこれらを満たさないなら、要注意ですよ。
３-１．理由が明確なもの
なんと言っても、なぜそのルールがあるのかという「理由」が明確になっていることが大事です。ルールだからと何でも杓子定規に決める人は、コーディング規約がある理由を勘違いしているのかもしれません。
コーディング規約を守ることの意義にプログラマが納得してもらえなければ、守ってもらえず有名無実になります。なぜそのルールがあるのかを説明するのは、コーディング規約を決めた人たちの義務なのです。
よいコーディング規約であれば、プログラマとしてのスキルアップができ、視野も広がります。また、プログラマの前向きな協力が得られれば、もっといいコーディング規約にレベルアップさせることもできるのです。
３-２．使うプログラミング言語・フレームワークに合ったもの
プログラムは何かのプログラミング言語で作ります。また、今はフレームワークを使うことが当たり前です。それらは種類ごとに使い方が違うので、コーディング規約もそれにきちんと合わせなければなりません。
よくありがちなのは、コーディング規約を決める人の知識や経験が追い付いていないことです。COBOLや古いC言語などなら有効かもしれないルールを、JavaやJavaScriptなどに無理矢理適用したりもします。
確かに、プログラムの作り方にはプログラミング言語の垣根を超えた、共通するベストプラクティスはあります。でも、プログラミング言語の個性を無視した適用はできないのです。その辺はきちんと考えたいものです。
３-３．自動的にチェックや適用ができるもの
コーディング規約に則ったプログラムを作る時に、プログラマが行うべき作業が無駄に増えると、そのコーディング規約は守られません。逆に、自動や簡単にできるものなら守ってもらえる可能性はグンと高まります。
例えば、プログラムのスタイルを手で直さなければならないなら、プログラム本体を作っている時間よりも、下手をするとスタイルを直している時間の方が多くなるかもしれません。それでは本末転倒です。
ですから、コーディング規約に則ったプログラムにする作業が、自動的あるいは簡単にできるといいでしょう。コーディングスタイルに合わせる作業はボタンひとつで出来るようにしておく…などの工夫が必要です。
３-４．常に見直しがされているもの
コーディング規約は生き物です。運用しながら常に見直しをしたり、プロジェクトの現状に合わせて変えていくものです。硬直化した古いコーディング規約は、その効果を十分に発揮できず、むしろ邪魔になります。
また、プロジェクトが終わった時の振り返りで、あまり効果が見られなかったルールはその内容を見直して次へつなげるべきなのです。その見直しで、次のプロジェクトは上手く回るようになるかもしれません。
それに、コーディング規約はプログラマが使うものだからこそ、プログラマの仕事がよく分かっている人によって見直されなければなりません。また、見直しをするメンバーに現役プログラマがいることも大事でしょう。
３-５．時には例外も認めるもの
コーディング規約は参加する全てのプログラマが守るべきルールです。でも、時には守らないことを認める必要もあるのです。そのくらいの柔軟さは、コーディング規約を運用する側にも求められます。
プログラムの性能が十分に出ないなど、コーディング規約を守っているとそもそもプログラムとして実現しなければならない要件が満たせないケースもあります。そういう場合は、限定的に逸脱を認めるべきです。
ただ、それは最後の手段だということは意識しておきましょう。コーディング規約を守るメリットと守るデメリットを天秤にかけて、守らない方がこの場合は得なのだという判断が都度なされるべきなのです。
３-６．世間一般の流れに追随できているもの
今のコーディング規約が、世間一般で普通とされる開発方法と比べて違いがあるなら、積極的に追いつく姿勢も必要です。最近はコーディング規約を公開する人達も増えてきたので、参考にできるものはあります。
プログラミングのベストプラクティスは時代と共に移り変わっています。世間一般ではずっと生産性の高いやり方が広まっているのに、コーディング規約が古いせいでそれらを活用できないなら、不幸としか言えません。
ただ、往々にして外部の状況や世間での当り前は、自分から積極的に情報を得ようとしなければ分からないものだったりもするのです。その意味でも、プログラマとしてのアンテナは高くしておく必要がありますね。
４．さいごに
コーディング規約について知っておくべきことをざっと説明してきましたが、いかがでしたでしょうか?
コーディング規約は、プログラマの自由を縛ることで規律を得るものです。その規律の中からプログラマが得られるものは必ずあります。ルールだからと思考停止せずに、そのルールがある理由を考えてみませんか?
悪法もまた法なりとも言いますが、コーディング規約は本来はプログラマのためにあるものです。プログラマが幸せになれないコーディング規約は、害悪でしかありませんので、常に改善の声を上げるべきです。
また、コーディング規約は常に変化するものです。新しいプログラミング言語や方法論が出る度に、それに適応していくものです。そういう前向きな姿勢で、コーディング規約と向き合っていただきたいと思います。
関連記事 関連記事
コメント