読者です 読者をやめる 読者になる 読者になる

奇特なブログ

「殊勝に値する行いや心掛け」を意味する、奇特な人になる為のブログです

貴方はレガシープログラマ?

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

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

1. 使われるローカル変数をすべてメソッドの最初に宣言する。
2. ローカル変数の宣言時に空文字("")や新しいオブジェクト(new Xxx())で初期化する。その後にすぐ別の値をセットする。
ここは、2つセットにします。
で、どちらとも、「どっちかといえば」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の方が多かったですね。
でも、じゃあレガシーが「絶対に」ダメなのかというと、別にそんな事は無いと思います。
まあ、それぞれに「良い所」と「悪い所」があるので、
臨機応変に適材適所で使い分ければ良いのではないでしょうか。