イー・エルダーが考えるコーディング規約とビジネス進化論【2025年3月】

イー・エルダーが考えるコーディング規約とビジネス進化論【2025年3月】

コーディング規約

コーディング規約 メニュー

• コーディング規約
• ソースコードは英文
• コメントは必ず書く
• コーディング規約とビジネス進化論
• 命名規約
  • プリミティブ型の接頭辞

コーディング規約が必要な理由は、既にご存知の方がほとんどだと思うが、だれもが好きなようにコーディングしてしまうと、可読性が極めて低い、読めないソースコードが出来上がってしまうからだ。

あらかじめルールを決めておくことで、可読性を担保できる。

特に、変数そのもの、変数の接頭辞は規約を作っておくことで、その変数が何を表しているか、どのプリミティブ型か、一目瞭然になる。

大昔、VBで変数に日本語（2バイト）を使ったアホがいたが、こういうアホや、for文のカウンターに、i、j、k、などはよく使用するが、i1、i2、i3・・・・のようなマジで読めないソースコードを書くアホを駆逐する為にコーディング規約は重要だ。

※個人的には、カウンターはcntI、cntJ、cntKのような接頭辞を付ける方が好きだが、これはソースが好きか醤油が好きか？という議論になると思う。

業務アプリなどでは変数そのものを規定する事も多い。「契約 contract」「検査 inspection」「予算 budget」「支払 payment」「委託事業 project」「補助事業 grant」など予め単語と変数名を決めておくことで可読性を担保できる。

「契約 keiyaku」「検査 kensa」「予算 yosan」「支払 shiharai」「委託事業 itaku」「補助事業 hojo」のようなローマ字での記述も馴染みがあるし、命名規約に定義しておけば可読性は上がるので、ローマ字記述でも良い。

※ローマ字記述がダメというプロジェクトも散見するが、意味不明な英単語を付けられるよりは、ローマ字記述の方が可読性は確実に高いので無理に英語を使用する必要はない。重要な事は可読性を第一に考える事で、英語にこだわって可読性を損ねるのは愚の骨頂だ。

ソースコードは英文

プログラムは英語そのものだ。if、for、switch、do while、public、private、add、get、set、put、trim、claer、remove、などなど。

クラス、メソッド、プロパティ、変数、それぞれ正しい英語表記で命名すれば、英文としてきちんと読めるようになる。

英語圏の人（英語ができる人）にとっては単なる文章なので、普通に読めて当然だ。

問題は英語ができない日本人で、英語ができない日本人にとって、forも、ifも、switchも、すべてコマンドとして認識しており、クラス、メソッド、プロパティ、変数もそれぞれ、単なるコード（バーコードようなもの）化してしまう。

その結果、作成されたソースコードは全く読めないものが出来上がる。

UNIXのソースコードを読んだことがある人は、おおよそソースコードは読み物であると理解している。可読性は高くはないけどね。

※困るのが、英語を普通に読み書きできるが、アホで英語のできない日本人を考慮しないプログラマーだ。彼らは思いつくままソースコードを書いた結果、英語のできない日本人には読めないソースコードになる事があるので、嫌がるが規約で縛りつけるしかない。

日本語しかできないコーダーはとても多いので、コーディング規約、命名規約で縛りつけて、可読性を担保する事が重要だ。

コメントは必ず書く

どのようなクラス、メソッド、プロパティにもコメントは必ず書く必要がある。コメントの記述ルールもコーディング規約で細かく定義する必要がある。

「コメントの始まり、機能、引数、戻り値、コメントの終わり」など、記述方法をキッチリ決める必要がる。

特に「javadoc」や「サードパーティー」のドキュメント出力ツールを使用する場合は、100％使用するツールに沿って記述する必要があり、例外は許してはいけない。

日本語しかできないコーダーは、コメントに関しては従順な有能なコメントを書くのだが、ここで問題なのは、英語ができる有能なプログラマーで、彼らはソースコードそのものが文章なので、コメントなど必要ないという考えを持っている人も多い。

彼らのように有能なプログラマーだけなら、複雑な機能以外コメントを書かないという選択もあるかもしれないが、多くはソースコードは単なるコードそのものにしか見えないコーダーなので、読む人の事を考えないプログラマーは無能だと思い、ここでも規約で縛りつけよう。

そもそも、コメントとは補足と考えているプログラマーもいるが（特に英語ができるプログラマー）、コメントは設計書の一部と考えるべきである。

ソースコードの中に書くコメントは確かに補足だが、クラス、メソッド、プロパティの最初に「機能、引数、戻り値」などを書くコメントは設計書の一部である。

設計書の役割は、後々、仕様変更などのメンテナンスで必須になるので、コメントはソースコードと同様に重要だ。設計書とソースコードが一致しないなど言語道断なのである。

コーディング規約とビジネス進化論（大恐竜時代とGAFAMのビジネス進化論 恐竜たちの教訓）

大恐竜時代と呼ばれる壮大な時代が地球に存在した。地球はまさに恐竜たちの天下だった。

全長約12メートル、体重6～8トンの屈強なフィジカル、最大時速40キロで走る脚力、立体視が可能な発達した視覚、遠方まで嗅ぎ取る嗅覚、獲物をかみ砕く強靭な顎と最大30センチに及ぶ鋭い歯を武器に、ティラノサウルスは食物連鎖の頂点に君臨に君臨した。

最強の捕食者であるティラノサウルスの姿は、現代における「Microsoft」「Google」や「Amazon」、GAFAMを彷彿とさせる。

GAFAMも「OSとオフィスソフト」「検索エンジン」「モバイルアプリケーション」「クラウドサービス」「イーコマース」などの市場を支配し、圧倒的な競争力を誇る。

GAFAMは強大な技術力と資金、圧倒的なブランド力を武器に、他社の追随を許さず、敵対的買収を繰り返し支配力をさらに拡大し続ける。

命名規約

プログラムの製造（開発）における命名規約は、可読性を担保するために必須の規約だ。

たとえばJavaの場合、変数がプリミティブの場合、変数の前に接頭辞をつける。

プリミティブ型の接頭辞

メソッドやクラスの機能を表す接頭辞

メソッドやクラスの機能を表す接頭辞をつける。

よく使う英単語

よく使う英単語。

おすすめ記事

	コーディング規約 コーディング規約が必要な理由は、だれもが好きなようにコーディングしてしまうと、可読性が極めて低い、読めないソースコードが出来上がってしまうからだ。 大昔、VBで変数に日本語（2バイト）を使ったアホがいたが、こういうアホや、for文のカウンターに、i、j、k、などはよく使用するが、i1、i2、i3・・・・のようなマジで読めないソースコードを書くアホを駆逐する為にコーディング規約は重要だ・・・  続きを見る
	ソースコードは英文 プログラムは英語そのものだ。if、for、switch、do while、public、private、add、get、set、put、trim、claer、remove、などなど。 問題は英語ができない日本人で、英語ができない日本人にとって、forも、ifも、switchも、すべてコマンドとして認識しており、クラス、メソッド、プロパティ、変数もそれぞれ、単なるコード（バーコードようなもの）化してしまう・・・  続きを見る
	コメントは必ず書く どのようなクラス、メソッド、プロパティにもコメントは必ず書く必要がある。コメントの記述ルールもコーディング規約で細かく定義する必要がある。 コメントとは補足と考えているプログラマーもいるが（特に英語ができるプログラマー）、コメントは設計書の一部と考えるべきである・・・  続きを見る
	命名規約 プログラムの製造（開発）における命名規約は、可読性を担保するために必須の規約だ。 たとえば、変数がプリミティブの場合、変数の前に接頭辞をつける・・・  続きを見る