プログラミング標準なんていらない

プログラミング標準というものがありました．趣旨はこのようなものでした．

この標準に従い，みんなが同じようなプログラムを作る．そうすることで，プログラムの品質が安定し，他の人が作ったプログラムも理解しやすくなる．

この趣旨に沿って，変数名のつけ方や字下げのカラム数，括弧の位置や空白のつけ方まで事細かに決まっていました．

結論から言います．変数名のつけ方や字下げのカラム数，括弧の位置や空白のつけ方まで事細かに決めたプログラミング標準は何の役にも立ちません．役に立たないどころか，害しかありません．プログラミング標準があるばかりに，プログラムの品質は向上せず，他の人が作ったプログラムは理解できません．みんなが同じように「作った本人すら理解できない」プログラムを作ります．＃「向上しない」を「安定」と言うのなら安定はします．

このように考える理由を以下に述べます．

私の周りにあった「品質が安定し，他の人が見ても理解しやすいプログラム」はこんなものでした．

変数名も字下げのカラム数も括弧の位置も空白のつけ方も全てプログラミング標準通り．しかし，機能分割もモジュール設計も何もしていない，１ファイルに数千ステップ押し込んだ巨大なプログラム．

変数名も字下げのカラム数も括弧の位置も空白のつけ方も全てプログラミング標準通り．しかし，字下げに字下げを重ねた結果エディタの右端（左端ではない）をまるでヘビのようにのたうちまわるプログラム．

プログラミング標準に「１ファイル内のステップ数の制限」や「字下げの回数の制限」を盛り込むと「品質が安定し，他の人が見ても理解しやすいプログラム」はこのようになります．

変数名も字下げも括弧の位置も空白のつけ方も「１ファイルのステップ数」も全てプログラミング標準通り．しかし，機能分割もモジュール設計も何もしていない，１ファイルに入るステップ数になったら何の脈絡もなく別ファイルになったプログラム．

変数名も字下げも括弧の位置も空白のつけ方も「字下げの回数」も全てプログラミング標準通り．しかし，字下げの回数が制限に達したら，途中から何の脈絡もなく別プロシージャになっているプログラム．

こういうプログラムは全て「プログラミング標準に沿ったわかりやすいプログラム」という評価をもらっていました．

逆に，それ以外が全てプログラミング標準通りでも，機能分割やモジュール設計を行ったプログラムは「プログラミング標準に沿っていないわかりにくいプログラム」という評価でした．

この評価の基準はこのようなものです．

プログラミング標準に載っている「規則だけ」を守ったプログラムはわかりやすい．プログラミング標準に載っていない，機能分割やモジュール設計という「余計なこと」を行ったプログラムはわかりにくい．

プログラムのわかりやすさは，変数名のつけ方や字下げのカラム数や括弧の位置や空白のつけ方や１ファイルのステップ数や字下げの回数に拠るのではなく，プログラムの対象となった問題の把握方法や，解決方法，機能分割やモジュール設計に拠ります．しかし，問題の把握方法や，解決方法，機能分割やモジュール設計はプログラミング標準にはありません．状況に依存するので標準で一意に決めることは難しいのです．

プログラミング標準とは「プログラムを作る上で文書としやすいところのみを抜き出したもの」に過ぎません．プログラムの本当のわかりやすさは，プログラミング標準には載っていないところにあるのです．

しかし，いつの間にか「プログラミング標準に載っていないことはやってはいけない」と本末転倒な状況に陥ります．以下のような過程でこの状態は発生します．

プログラミング標準に則ればわかりやすいプログラムができる
プログラミング標準にないことをやったプログラムはわかりにくい
プログラミング標準は守らなくてはならない
プログラミング標準に載っていないことはやってはいけない

これでは，プログラミング標準はわかりやすいプログラムを作る上での障害にしかなりません．

プログラミング標準に載っていないからやってはだめ，そんな理由でプログラミングを制限してはなりません．作者が責任を持って，自分が考える理解しやすいプログラミングをすべきです．そして，プログラミング標準に載っているからそれに従った，そんな理由でプログラムを作るのも止めにしなくてはなりません．「どうしてこうやっているんですか？」そういう質問に自分の意見をはっきりと言えるようにならなくてはなりません．それが，「品質を安定させ，他の人が作ったプログラムを理解しやすくする」道です．