システムハンガリアンってPHPでは有効じゃね？
1 ：nobodyさん：
システムハンガリアンって評判悪いじゃん。
たしかにC++みたいに型が違う値を代入しようとしたら
速攻でエラー吐くコンパイラにかけるんなら意味ないかと思うけど、
PHPみたいに元の型が何であろうが無視して新しい型にしてくれちゃう言語は、
ひるがえって『単なる型名を変数名につける』ってのが有効じゃないかと思うんだ。
PHPにおいてはアプリケーションハンガリアンよりシステムハンガリアンのほうがいい気がしてる。
ハンガリアンに限らず、PHPの柔軟すぎる型変換に適した命名規約を考えてくれ。
たしかにC++みたいに型が違う値を代入しようとしたら
速攻でエラー吐くコンパイラにかけるんなら意味ないかと思うけど、
PHPみたいに元の型が何であろうが無視して新しい型にしてくれちゃう言語は、
ひるがえって『単なる型名を変数名につける』ってのが有効じゃないかと思うんだ。
PHPにおいてはアプリケーションハンガリアンよりシステムハンガリアンのほうがいい気がしてる。
ハンガリアンに限らず、PHPの柔軟すぎる型変換に適した命名規約を考えてくれ。
|
|
|
そもそも、ハンガリアンが嫌われているのは
変数に実際に入れる型がいろいろ変わるからなわけだが。
>>1はバグ回避のために違う型を入れないようにするためと
いっているのだと思うが、間違った型を入れるとか言う以前に
ソフトウェアの性質上、型は変わるものなんだよ。
（変数に最初に想定していた型以外のものを入れることになる）
時代の流れとともに16bit変数は32bit変数に変わるし、
32bitポインタは64bitポインタに変わるし、
オブジェクト指向言語なら、型は継承され新しい型になる。
PHPのような柔軟な言語だからこそ、なおさらハンガリアンは必要ない。
それにハンガリアン（変数の頭に型を入れる）を使うまでもなく
変数名そのものが型をあらわしている。flagならtrue/falseだし、priceなら数値だろう。
変数に実際に入れる型がいろいろ変わるからなわけだが。
>>1はバグ回避のために違う型を入れないようにするためと
いっているのだと思うが、間違った型を入れるとか言う以前に
ソフトウェアの性質上、型は変わるものなんだよ。
（変数に最初に想定していた型以外のものを入れることになる）
時代の流れとともに16bit変数は32bit変数に変わるし、
32bitポインタは64bitポインタに変わるし、
オブジェクト指向言語なら、型は継承され新しい型になる。
PHPのような柔軟な言語だからこそ、なおさらハンガリアンは必要ない。
それにハンガリアン（変数の頭に型を入れる）を使うまでもなく
変数名そのものが型をあらわしている。flagならtrue/falseだし、priceなら数値だろう。
4 ：nobodyさん：2009/03/17(火) 20:44:05 ID:8mZIbPB9
常識の範囲内ならどうでもいい。
つまりは、priceがlongからItemPriceに変わるというように
型が変わることがあるってこった。
それは避けられないからハンガリアンはよくない。
つまりは、priceがlongからItemPriceに変わるというように
型が変わることがあるってこった。
それは避けられないからハンガリアンはよくない。
クラスでゲッターやセッター使ってれば
タイプヒンティングも使えるし、型よりも値の範囲を絞って
例外を飛ばせるから全く問題ない。
一度処理に入ったら長い処理が行われるのではなくて
1回毎のシンプルな処理をセッションやクッキー使ってどうにか
継続させるのがWebアプリだから、ユーザー側のデータは
1回毎に改変が無いか毎回チェックする事になるし、型があってもなくても関係ない。
タイプヒンティングも使えるし、型よりも値の範囲を絞って
例外を飛ばせるから全く問題ない。
一度処理に入ったら長い処理が行われるのではなくて
1回毎のシンプルな処理をセッションやクッキー使ってどうにか
継続させるのがWebアプリだから、ユーザー側のデータは
1回毎に改変が無いか毎回チェックする事になるし、型があってもなくても関係ない。
必死だなｗ
モンゴリアン乙
ジャンガリアンハムスターが有効と読み間違えた。