１０のコーディングルール

以前、コードの１０戒と題して、犬の１０戒をまねしたコーディングルールを掲載しました。
しかし、若干カジュアルすぎるため仕事に適用するには文体を改修する必要があるかもしれません。

長いコーディング標準は、読むのも守るのもメンテするのも大変です。

なので、短いけど守ってほしい事と理由を犬の10戒の真似をしてまとめてみました。

そこで今回は、これを少しフォーマルなものにしてみました。

1.識別子（名前）は分かりやすいものにすること。	
	参画するメンバーにより理解してもらうために分かりやすい名前にすること。
	メソッド名等が文章になってもかまわない。
	何をしようとしているのかを明示すること。
	全ての識別子はその存在理由が明確である必要がある。
	また、その存在理由以外の目的で利用しないこと。

2.”共通"とか"common"といった名前を利用しないこと。	
	共通で利用するメソッドや定数やクラスも、必ず存在理由がある。
	その役割にあった場所に配置すること。

３.事前条件、事後条件を利用すること。	
	メソッドの処理に入る前に引数がとりえる範囲を事前条件として指定し、範囲外であれば例外を飛ばして排除すること。
	そうすることで処理中で考えなくてはいけない範囲を狭く出来る。

４．スコープは最小にすること。	
	複数の問題が同時に存在していると、ミスリードしてバグを誘発する可能性が高くなる。
	変数のスコープだけではなく、処理、問題等全てのスコープを最小にすること。
	
５．「将来のため」のコードを残さないこと。	
	不必要なコードを｢将来のため」といった理由で作りこまないこと。
	必要になってから作ったコードは使われるが、
	「将来のため」に作ったコードは使うかもしれないし、使わないかもしれない。
	
6.作るときにチューニングをしないこと。	
	チューニングは非機能要求にそった計測後、足りていない部分においてのみ行う事。
	コードの調和の取れた構成をできるだけ崩さないようにするため。
	
7.レビューを行うこと。	
	コードは必ずレビューをすること。
	また、レビューにおいて指摘された点は速やかに修正すること。
	複数の視点で見たコードはより分かりやすくなるため。
	
8.テストをすること。	
	コードは思いどおりには動かない。
	自分が思ったとおりにコードを書いているかテストして確認すること。
	そして思い通りに動かないときは、まず自分を疑うこと。

9.バージョン管理は構成管理ツールに任せること。
	コードをコメントにして残さないこと。
	修正履歴をコメントで残さないこと。
	その全てを構成管理ツールに任せること。

10.保守で修正する前に、必要な範囲の構成について理解すること。	
	修正する箇所だけではなく、その周辺の構成に理解したうえで、その秩序を乱さないように修正すること。