ちょっと囓っただけの素人が自分を過信して陥る三つの罠？

http://d.hatena.ne.jp/fromdusktildawn/20081026/p1
うーんと，30点．「もう少しがんばりましょう」レベル．*1

初心者が惑わされると可哀想なので，一応突っ込んどく．

1. 「変数のスコープは狭いほど良い」という迷信
2. 「同じロジックのコードを2度以上書くな」という迷信
3. 「プログラミング言語を極めるのが大切」という迷信

一つ目は大原則．特にグローバル変数は最悪だ．言語によっては避けられないこともあるが，それはコーディング規約などでカバーするしかない．
二つ目も，ほとんどの場合は大原則．未熟なプログラマーには，何故か負担が大きすぎるらしいけど．
三つ目はケースバイケース．ほとんどの場合は言語も極めてない奴の方が多く，まずは「言語を極めろ」は概ね正解．

• なんだかなぁ。「先ずは使うことを覚えろ」「次に使わないことを覚えろ」「最後に使うか使わないか選ぶことを覚えろ」で十分な気が。
• 状況によっては、と頭につければ、大抵のルールに例外は存在する。
• ブクマ欲しさにこういう事をするのか…。言ってる事は必ずしも間違いではないが、多くの「自称中級」の初級PGを誤らせる危険な有害記事。本当の中級者以上は言われなくてもそんな事もっとリアルに判ってる。
• 少なくとも1番と2番は論点をずらした詭弁だよ。
• 蛇足ですが『C言語ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ診断室』*2と､『Google Coding Style Guide』なんかを読むと参考になりますよ｡

http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/fromdusktildawn/20081026/p1

分裂さんちに書いてあるような選択をするときは、我が身の技量不足を100回くらい疑ってから、やむを得ず・・・くらいでちょうど良いと思います。

http://d.hatena.ne.jp/minekoa/20081026/1225044432

• プログラマは、悪い状況を招かない事にまず注力しなければ、いつまで経って低いレベルの妥協から抜け出せない。妥協の塊のせいで保守コストが上がり、そのせいで開発パワー不足が悪い状況を生み、また妥協…、のスパイラル。
• 抽象化を分かりやすい形に出来ていないという問題を、抽象化を悪者にして対処とするのは如何なものか

http://d.hatena.ne.jp/r-west/20081028

ロクにソースも書けない新卒が
「えー？ちょっと前にこれでも良いんだってネットで話題だったんですよ？知らないんですかぁ？」
とか言いながら得意げに適当なグローバル変数多用してコピペプログラミングしてたら、多分殴るまでは行かないまでも拳は握り締めると思う。

http://d.hatena.ne.jp/ymScott/20081029/1225284055

「プログラムは動けばいい」という意見もある．だが実際には妥協に妥協を重ねた「ストーブパイプ」は，ほとんど常に「動かないプログラム」だ．*3だからプログラマは良いコードを書くように注力せねばならず，これらの原則*4もそのために存在する．

プログラミング作法

The Elements of Java- Style (SIGS Reference Library)

お勧め本リスト：http://d.hatena.ne.jp/JavaBlack/20070522/p1

「変数のスコープは狭いほど良い」

変数でもメソッドでもクラスでも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。

変数と，メソッドやクラス或いは定数を一緒にするのは論外．
グローバル変数は最悪だということは肝に銘じておこう．グローバル変数的なクラスも同様．

実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、

オブジェクトのスコープは『可能な限り』狭い方が良い。つまり必要であれば，必要最小限の範囲まで広げるのは構わない．時にそれがプログラム全体になることもあるというだけ．*5

デフォルトの言語仕様の上に、自分が開発しようとしているアプリケーションのドメインに特化した言語仕様を載せて創り出した「拡張言語仕様」の上でプログラムを書くと生産性が大きく向上する。

これにはあまり賛成できない．

まず，実際には多くのフレームワークやライブラリを用意するだけで事足りる場合が多い．独自の言語仕様を制作するのは『車輪の再発明』でしかなく，作られた言語は一般的に普及した言語に比べより未熟で質が悪いことが多い．開発者にとってアプリのデバッグだけでなく言語のデバッグも同時に行うことは非常に大きな負担となる．なにより似て非なる二つの言語を覚えることは単なる時間の浪費だ．よほど大きなメリットがない限り，独自仕様『粗悪』言語の出番はない．*6

変数、メソッド名、クラス名は、全て識別子という概念で括られるものだ。

識別子と，変数／メソッド／クラスは別物だし，変数とメソッドとクラスはプログラミングする上でそれぞれ大きく異なるものだ．グローバル変数とグローバル定数でさえも大きく異なる．*7

あー，ひょっとしたらこの人は「囓っただけの素人」じゃなくて，単なる「スーツ(笑)」の人なのかな．ならば凄く納得．全然プログラミングを理解してないわけだ．

「同じロジックのコードを2度以上書くな」

まず第一に、将来的なプログラムパターンの変更の可能性がある。現在、複数箇所に同じようなプログラムパターンが現れたとしても、将来的には、それらは別の修正を受け、別進化していく可能性が予見されることがある。

多くの場合はこれは誤りだろう．
例外として，ありがちなのが，例えばWeb系のUI部分なんかで「見た目上のレイアウトが似ているけれど，エラー処理や画面遷移などのロジックが全然異なる」場合かな．これでさえも共通化出来る部分については，どんどん共通化していって良い．

抽象化レベルの話がある。抽象度を上げることで、共通ルーチン化はできるが、プログラムがコンパクトになるかわりに、直感的に理解しにくくなるケースがある。

抽象化し、共通ルーチン化しすぎたプログラムは、可読性が低くなり、スキルの低いプログラマに引き継ぎをしなければならなくなったときに、途方に暮れてしまうことがある。

プログラミング経験がほとんどない初心者に毛が生えた人が，このように主張する事が多い．特に抽象の取り扱いは開発者の素質に大きく依存するらしいので，素質のない人がこういう結論に至るのは驚くに値しない．自分のプログラミングテクニックの未熟さを棚に上げて，抽象に責任転嫁することがないよう注意しよう．

なにより，一番重要な点として，「共通ロジックをコピーするのは容易だが，似て非なる複数のロジックを共通化するのは時に非常に困難，或いは不可能になる」という事実を忘れてはならない．あとで分割される可能性があっても現時点で共通のコードであるならば，将来異なるロジックになる可能性が高いと確信をもって言えない限り，とりあえず共通化しておいて損はない．*8

「プログラミング言語を極めるのが大切」

単なるプログラミング言語のスキルよりもはるかに重要なスキルはたくさんある。

ここまでは同意．

結局のところ、ほとんどのコンピュータプログラムは、人間や社会のニーズや欲望を満たすために存在し、人間や社会の利害や感情の構造の組み立て（これも一種のプログラミングだ)と無縁ではいられない。

これは暴言．

他のツッコミは、あとで気が向いたらレスするかもしれないけど、概ね、レベルが低いので、いちいちレスしないかもしれない。

する必要は『全然』ないですよ．

最初に書いたように，こういう分かってない意見に素人が振り回されるのが可哀想だと思っただけだから．

*1:いつのまにかタイトルが変更されてる．現時点だと「中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント」だけど，元は「中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと思いこみがちな３つの迷信」だったかな．中身も「迷信」が全部「盲信」に置き換わってるっぽい．この変更でかなり意味が違ってくる．

*2:http://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

*3:ヘルメットも被らずにバイクで一般道を時速100km/hで信号無視して走るようなもの．今回はたまたま無傷だったとしても，次回も命がある保証などない．「事故があったけど生きてたからいいじゃない」は死にたがり屋の馬鹿のすること．「事故を起こさないよう必要な対策を講じる」のがプロの仕事．

*4:「ベストプラクティス」と言った方が分かり易いか？

*5:「可能な限り最小限 == プログラム全体」となる原因が設計ミスの場合もあるのだが．

*6:欠点の一つがドキュメントが少ない，或いは皆無なこと．ちょっとサンプルコードを参考にしたり，分からない事を調べたりすることさえできない．思い通りに動かなくても誰にも相談できない．何かあったらソースコードを全部解読するは目になるけれど，そういうコードに限ってコメントのないスパゲッティプログラムだったりするんだよね．いやあ大変だ．

*7:Javaのクラスやメソッドに関して言えば，publicとパッケージprivate以下では明らかに異なる．publicは原則として公開API扱いになるのに対し，パッケージprivate以下はパッケージ単位以下のローカルな実装として扱えるから．変数はもちろん，定数にしても可能な限りパッケージprivate以下にすべき．
実際には言語によってはJavaでいうパッケージのような機能がない場合もあるので，そういう場合はしかたない．ただしやはり同様な概念を持って，「このクラスはこのモジュール(パッケージ)の以外から使っちゃダメ」みたいなルールを決め，そのルールを徹底するのは重要．ただ人間は間違える動物だから，そういうルールがあってもやっぱり間違える人は出るんだよね．だからそういう間違いが排除できるように，環境やツールや言語が進歩してきたわけ．

*8:どこを共通化しなくて良いか分からない初心者の場合は，最初は全部共通化しておいて必要に応じてコピーしていく方が安全だ．どこが変更点か見極められるベテランの場合は必要に応じてコピーして書き換えるくらい雑作もないので，ほとんどの部分で共通化できる部分は共通化する方を選択する．