滝打ち４日目。

いや～、現場でリファクタをしようと思って色々考えていたんですけどねぇ。
以下の様なメソッドなんですけど。

function a()
{
  return ？;
}

で、このメソッドを「$class_obj->a();」みたく呼んでいるわけです。

今回、何をしたいかというと、
このメソッドa内の処理を「分岐によって、元々の処理を行うか、新しい処理を行うか」に分けたいのです。
だったら、以下の様に書けば良いのではないかと。

function a($flg = false)
{
  if (true === $flg)
  {
    // 新しく追加した処理
  }
  else
  {
    // 元々やっていた処理
    return ？;
  }
}

$class_obj->a(true);

ただ、実はこれだけだとダメなんだよなぁと思っていたら・・・これってオーバーロードだから・・・イケる！と、
ただいま、大変に「己の才能」に感動している所ですw
ソースが目の前に無いので、頭の中だけで想像してますけど、
うん、やっぱりイケるんじゃないかなぁ。
まぁ、もしイケなかったとしても、
「オーバーロードって、新人以前の時に学んだけど、使い道が無くてどうしたもんかと思っていた」
ので、少なくとも「使い道の一つ」は知ることが出来そうです。
オーバー「ライド」なら、継承でしょっちゅう使うんですけどねぇ。
といっておきつつ、「正確にはオーバーロードではないだろ」には同意です。
いや、上記の呼び出し側の例が、「引数の数が可変に見える」じゃないですか。
その辺を見て、そう感じました。

さぁ、レッツ実験であります！

今回は、以下の記事に書かれている内容を、
筆者自身に対して、一つ一つ丁寧に検証していきたいと思います。
あと、筆者の場合、JavaとPHPがメインなので、この２つの言語を中心に。

レガシープログラマかどうかを判断する10項目(11項目に変わりました)
http://d.hatena.ne.jp/JunichiIto/20110218/1297983647

1. 使われるローカル変数をすべてメソッドの最初に宣言する。
2. ローカル変数の宣言時に空文字("")や新しいオブジェクト(new Xxx())で初期化する。その後にすぐ別の値をセットする。

ここは、２つセットにします。
で、どちらとも、「どっちかといえば」Yesの方かと。
筆者の場合、言語によっても書き方が違うのですが、
Javaだと、メソッドの先頭で「String str = null」みたく、nullクリアする事が多いです。
で、それじゃあダメな場合(忘れましたが、try～catchが絡む場合だったはず)には、
上記の2の書き方で初期化ですかね。
でも、PHPだと、変数が必要になるタイミングで、宣言と同時に代入したりしてますね。
で、どっちが良いかって話なんですが。
変数の寿命を意識するなら、上記のPHPの書き方なんでしょうけど、
本当に寿命を意識するなら、「1メソッドのステップ数を短くする事も検討する」っていうのもあると思うので。
で、2に書かれている問題点は、nullクリアで解消出来る事を考えると、
「言語問わず、メソッド内で使われるローカル変数は、すべてメソッドの最初で宣言してnullクリアする」で、
基本的には良いのではないかと。
ただ、Javaの様に、プリミティブ型だとnullクリアが出来ない言語の場合は、
まあ、int型なら0で、booleanならfalse辺りで初期化するって感じでしょうか。
で、メソッドのステップ数は、可能な限り短くなる様に意識して実装すると。
とはいえ、ここまで書いておいてなんですが、
こういうのは正直、「ケースバイケース」な面も大きいと思ってまして。
例えば、「どうしても」メソッドが短くならなくて且つ、
メモリ的にタイトなコードを書かなければいけない場合なら、
メソッドの「途中で」、変数を宣言と同時に代入とかってケースもあるでしょうし。
なのでまあ、この辺は「柔軟に」考えましょうということで。

3. メソッドの戻り値がすべて成功・失敗を表す 0 か -1 になっている。

Noかなと。
return文が無いメソッドとかって、日常茶飯事ですし。
勿論、return文がある(チェック系のメソッドだとbooleanを返すとか)のもありますけど、
これは、「そのメソッド内でどんな処理をしているかによる」としか言えない気が。
まあでも基本的には、「処理に因らず、何か返した方が良い」気がしますね。
まず、例外の時には、どこで(フレームワーク側かアプリ側か)起きたかによって変えます。
アプリ側ならthrowして、フレームワーク側なら、例えばエラー画面に遷移させるとか。
次に、それ以外の場合。
まあ何か「失敗した」って「ニュアンスの時」にはfalseを返し、
成功の時にはtrueを返すって、まあ、メチャクチャ曖昧な意見ですが（苦笑）
そんな所でしょうか。

4. 複数のデータをまとめて扱う際は毎回配列を使う。配列の上限数はありえなさそうな数を指定する(1000とか)。

Javaの場合だと、「ほぼ」Noかなと。ArrayListを使う事が殆ど。
PHPだと、配列を使いますが、
連想か否かは、意識する程コードをまだ書いていないと思います。
Javaについてもう少し触れると。
基本的にはListで良いと思うんですが、
「メモリがタイトなコードを組む必要に迫られた場合」には、配列を使うかなと。
removeとかsetの処理の時に面倒にはなると思いますが、まあしょうがないということで。
あと、Listを使うにせよ配列を使うにせよ、サイズ(上限数)は意識したい所です。
勿論、インデックス越えするのは論外ですが、
「この用途で使う配列だと、このぐらいのサイズで大丈夫」な時ってありません？
あと、Listだと、ちょっと記憶が曖昧ですが、
「サイズが自動拡張」とかって・・・ああ「LazyList」でした。
まあ、標準APIでは無いですけど。

5. 基本データ型(stringやint)と配列だけでデータ構造を表現しようとする。

No。
普通にクラスを使います。
Cは、殆ど触った事が無いですけど、構造体使えば良いんじゃないです？
「難しくて分かんないから使わない」って考えは、筆者は好きじゃないですね。
勿論、可能な限りシンプルな方が良いですけど。

6. 変数の命名規則にハンガリアン記法を使う。

No。
PHPみたいな「型の無い言語」の場合、どうするんでしょうかね？
いやまあ、「どんな型のデータが入ってくるか」を意識すれば良いっていうか大事な事ではあると思いますが、
なんでしょう・・・どうもしっくりこないので、ハンガリアン記法反対で良いと思います。
とはいえ、ココ(に限らんけど)は、いずれ改めて考えてみたい所ですね。

7. クラスのフィールド変数をグローバル変数のように利用する。

No。グローバル死ねで終了ですw
いや、真面目な話、グローバルには「悪夢」しか思い出せないので（苦笑）
といっておきながら、筆者の自作フレームワークのソースには、
configクラスという、シングルトンな疑似グローバル変数が存在していますが（苦笑）
早く改修しなければ・・・

8. 配列やリストを毎回forループで処理する(例: for (int i = 0; i < array.Length; i++))。

Yesかな。
というのも、foreachは速度が遅い(Javaは間違いなかったはず)ので。
あと、ループ内の処理で、「if (i == 0)」みたいな事を書く時ってありません？
だから、インデックス変数がある方が良いです。
あと、ついでに書いておくと、
上記のarray.Lengthは、for文の「1行上に」書きますかね。
といっても、Lengthがプロパティであり、メソッドで無ければ良いのかな？ちょっと微妙な所です。
で、懸念されている終了条件の間違いは、まあ気を付けましょうではダメですかね？

9. クラスやクラスメンバの可視性を意識していない(privateメソッドがpublicになっている等)。

No。7と同様、死んでくださいw
えっと、議論の余地が無いぐらいに、当たり前というか。
「セッター内でデバッグしたい」んですよ、だから。

10. 変更履歴をコード中にコメントとして残す (ADDやDELみたいなコメントがたくさん付いている)。

No。現場では良く見ますけどね（苦笑）
ただ、TODOは書きますけど。「今後」どうするかってメモの意味合いで。

11. 変数名やメソッド名を何かと略したがる。

No。
ですが、valueを「val」とか、objectを「obj」とか、workを「wk」とか、
「省略形でも、元々の名前が明らか」な場合には、略しても良いと思います。
ただ、この辺は、開発者間によって齟齬が発生しそうなので、
基本は「省略しない」方が良いと思います。
といっても、valとobjは、さすがに大丈夫な気もしますが。

さて、結果ですが。
奥歯に挟まった様な回答もありましたが、
どっちかといえば、Noの方が多かったですね。
でも、じゃあレガシーが「絶対に」ダメなのかというと、別にそんな事は無いと思います。
まあ、それぞれに「良い所」と「悪い所」があるので、
臨機応変に適材適所で使い分ければ良いのではないでしょうか。

今回は、以下の記事を基にした内容です。

http://d.hatena.ne.jp/Lucrezia/20050928#p1

また、本文中で「VB」と書かれている箇所の大半は、
「初心者向け言語」と置き換えられると思います。
PHPとかJavaScriptとか。

「ほかの言語もちゃんと習熟した上で」VBを使ってる分には別にいいの。そこまでとやかく言うつもりはないわ。

実は、ここが最も重要だと思います。
現実問題として。
世の中には、「初心者向け言語で構築されたアプリやサイト」が溢れているのが実情である以上、
全てを廃止するのは、現実的ではないと思いますので。
じゃあ、初心者向け言語「しか」触った事がない人はどうすればよいのかって、
「学べば良い」のではないでしょうか。
非初心者向け言語と筆者は考える、C・C++・Javaのいずれかを。

言語ごとのTipsなんて方言よ。それよりも"言語によらないスキル"を覚えなさい

これは単純に、「その覚え方のほうが、応用が利いて楽」だから、
良いのではないかと筆者は思います。

あなたはオートマトン図を自分で書いたうえで「状態遷移」のプログラムが書けてかしら？ threadの「概念」が把握できてかしら？ processとの違いをきちんと実装で表現できてかしら？

筆者個人は、状態遷移はココの、convert_templateメソッド内にある通りです。
threadとprocessは、正直微妙ですが。

言語なんて、ある程度以上の熟練者なら数日あれば(あとは資料さえあれば)普通に使うことが出来てよ？

同感です。
イメージとしては、我々が会話で使う日本語や英語を話すバイリンガルに似ている気がします。
というより、プログラミング言語は日本語などの言語と比べて、
「文法が比較的似ている」ので、習得がしやすいのではないかと思います。

言語は「道具」です。
で、道具は「使い分け」ませんか？
筆者が主張したいのは、言語の優劣ではありません。
というより、優劣を語る事自体がナンセンスだと思っています。
「好み」程度であれば、まだ分かるのですが。
別にVBだって、上記リンク先のコメント欄に書いてある様に、
出番はあるのですから。
個人差はあるでしょうが、仕事で１年以上プログラミングをしている方なら、
そろそろ「触った事がない言語」を学んでみても良いのではないでしょうか。

タイトルの様にした方が良い理由は到って単純で、

仕様変更や特殊な仕様に対応する為です（苦笑）

例えば、以下のリンク先の一番下の回答にあるソースコードの場合。

finalメソッドの使いどき

以下の様に書いた方が良いのでは無いでしょうか。

---

class Framework {

    public function execute() {
      $this->a();
      $this->b();
    }
    
    protected function a() {
      // デフォルト実装
    }
 
    protected function b() {
      // デフォルト実装
    }
}

---

まず、executeメソッドにfinalは付けない方が良いと思います。
何故なら、aメソッドとbメソッドの処理「しか」行わないという「保証」が有りません。
また、aメソッドとbメソッドの処理の順序も「必ず」この順序なのでしょうか。

aとbメソッドについては、ケースバイケースかと。
そのメソッドが何をしたいのかによって、
abstractを付けたり付けなかったりするので。

とにかく、finalは止めましょう。
メソッドに限らず、当然クラスもです。
クラスにfinalを付けると、継承すら出来なくなります。
唯一の例外は、ユーティリティクラスでしょうか。

フレームワークやライブラリは「色んな人」が使います。
業務上、カスタマイズする事も多いです。
なので、「隙間の無いガッチガチ」な作りにはしないで、
「隙間が有って余裕の有る」作りにした方が良いと思います。
筆者も気をつけますので（苦笑）

Javaのフレームワークである「Struts Ver1系」を例にします。
個人的に、以下のリンク先の様なエラーを見ると、
「また、フレームワークが悪さしてる」と感じてしまうのですが。

StrutsでActionFormをネストしたときに値が送信されない － Java Solution － ＠IT

uebu: Strutsのトラブルシューティングメモ

フレームワークを使っていようがいまいがPOSTなら、
HTML内のname属性があるタグのvalue属性の値が「HTTPリクエスト」で送られ、
HTML内のname属性があるタグのvalue属性に「HTTPレスポンス」の値が入るのは、
「言語も問わず共通」なのですが。確か（笑）
フレームワーク固有のお作法(struts-config.xmlとか)を覚えるより、
他のフレームワークや他の言語でも応用が利く、
HTTPリクエストとレスポンスの仕組みを知る方が、
「何年経っても使える」と思うのはおかしな話でしょうか。

「PerlでCGIを使ったり、
フレームワークを使わないサーブレットなら経験有るけど、
Strutsは分からない」

上記全て、「HTTPのレイヤー」で見れば「同じ」なのですが。
単にフレームワークが覆い被さっているか否かの違いなのですが。

フレームワークを「使わない」。
悪さされても頭を抱え込まなくて済む事が増えますよ。