コード規約。プログラムを書くルール。
これは、出来るだけ緩いほうが良いと考える。
一定の基準でコードのチェックが出来る人がいること。（僕のチームの場合は僕）
という条件があるが、これさえクリアすれば緩くても大丈夫になる。
規約に沿って書かれているかどうか、第３者の目で見て、判断。
合否の基準は
プログラムの大きな流れを説明してもらい（共通の項目はこのフォルダに入っていると言うような）
プログラムとページを見て、何をやっているかがスムーズに分かり、規約どおりになっていればOK。
同じプログラムが２回以上出てきた部分は徹底的に修正。
分からないポイントはコメントを添えていってもらう。
というもの。
そもそもコーディング規約というのは、
プログラムの読みやすさ、管理のしやすさの為に存在していて
よくルールとして強制されるが、中規模以上でも無い限りそのメリットは少ない。
なぜなら、直接話しが出来るくらいの、少人数で回している場合、
コーディング規約を定め、全員に浸透させている時間で作業が進んでしまうから。
コーディング規約を設ける事に異論はないが、
メリット、デメリットをしっかり理解した上で使うべきだと思う。
メリットは
管理のしやすさ
品質の一定化（良くも悪くも）
これは規約を厳しくすればするほど、顕著になっていく。
よくあるコーディング規約に置かれている焦点は「安定」「安全」
コーディング規約に乗って書いてあれば、一定の品質は出せるという「保証」がある。
ただ、裏を返せば一定以上の品質は出ない。
プロジェクト一つという事に焦点を置けば、コーディング規約がきっちりしていると言うのは良いかもしれない。
ただ、プログラムを組む「人」はそれほど変わるものではない。
何度も同じコーディング規約を使い仕事をしていれば、
人は段々と「コーディング規約を守るプログラム」に寄っていく。
「コーディング規約を守るべき」という考え方は思考を停止させる。
最初からコーディング規約ありきのプログラムを書いていた人は
まっさらな状態からのプログラムを書くことは難しいだろう。
そう考え
僕の場合、焦点に置いたのは「改善」と「人」
良いコードと言うのは、ブラッシュアップされてはじめて生まれる。
なので、最初から素晴らしいプログラムというのは無い。
自由に組んだ中からドンドン形になっていくので、
最初から型にはめた時点で「多くの可能性」を失ってしまう。
いつもこう言っていた。
「自由に創っていい。ただし、より良いものにすること。時間をかけてもいいから、品質の高いプログラムを作ること。」
品質の高いプログラムは「バグが少なく、修正や機能追加が早く出来るプログラム」
ルールを求めず、良い物にしていく姿勢にした。
改善という焦点を置いた時にいい意味で人にも影響がでていった。
