アカウント名:
パスワード:
＞X座標を保持する変数にはpx、重さを保持する変数にはkg
用にそれぞれ別の型を宣言してやればいいんですよ。
>そうすれば、pxA + kgX という式は
コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。
おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。
しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
ハンガリアン記法が（snip）それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
笑わせる。「px」とかのわけのわからない一文字化略記が今時の「読みやすい」？笑う。ちゃんと略さないで書けっての。
と、いうことは、略されてさえいないのであれば、prefix はアリだと言うこと? column か row かの区別も型を設けて対応すべきという議論があったけれども、 prefix が「column」「row」と略されずに記されれば文句はないと言うこと?
別に prefix でも postfix でもどっちでもいいよ。名前にそれを含めることを「必要」と考えるか「あった方がいい」という程度に捉えるか、別の手段を採ってでも「不要」とすべきと考えるか、という話。そんだけのことのためにわざわざ型を宣言するのが理想というのはまさに「別の手段を採ってでも「不要」とすべき」という考え方な訳でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
ハンガリアン記法とか (スコア:0)
Re: (スコア:3, 参考になる)
char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
Re: (スコア:0, すばらしい洞察)
同意しない。だって、そういう目的なら、それ用の型を準備して使えばいいわけで。
暗黙に決めた名前ルールでどうにかしようなんて馬鹿げてて、型でシステマティックに解決するべきです。Javaのような部類の言語（静的型付言語）ならそれができるよね。
けっきょく、ハンガリアン記法なんてものは、静的に型を明示できない言語で型名を変数名に入れているだけだよね。しかもアドホックに。
Re: (スコア:0)
例えば、X座標を保持する変数にはpx、重さを保持する変数にはkgというプリフィックスを付けましょうということです。
そうすれば、pxA + kgX という式は誤りである可能性が非常に高いということが字面だけでわかります。
これは型でどうこうできるものではないのは理解いただけると思います。
(むろん言語のほうでどうにかすべきで、curlではなんとかしていますが)
いや、存じてるでしょ (スコア:0)
＞X座標を保持する変数にはpx、重さを保持する変数にはkg
用にそれぞれ別の型を宣言してやればいいんですよ。
>そうすれば、pxA + kgX という式は
コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。
Re: (スコア:2)
おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。
しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
むらちより/あい/をこめて。
Re: (スコア:0)
笑わせる。「px」とかのわけのわからない一文字化略記が今時の「読みやすい」？笑う。ちゃんと略さないで書けっての。
Re: (スコア:1)
と、いうことは、略されてさえいないのであれば、prefix はアリだと言うこと? column か row かの区別も型を設けて対応すべきという議論があったけれども、 prefix が「column」「row」と略されずに記されれば文句はないと言うこと?
むらちより/あい/をこめて。
Re: (スコア:0)
Re:いや、存じてるでしょ (スコア:1)
別に prefix でも postfix でもどっちでもいいよ。名前にそれを含めることを「必要」と考えるか「あった方がいい」という程度に捉えるか、別の手段を採ってでも「不要」とすべきと考えるか、という話。そんだけのことのためにわざわざ型を宣言するのが理想というのはまさに「別の手段を採ってでも「不要」とすべき」という考え方な訳でしょ。
むらちより/あい/をこめて。
Re:いや、存じてるでしょ (スコア:1)
職業プログラマでない私が言うのもなんですが、基本的に貴殿の意見に同意します。目的は関係者にとって扱いやすい名前をつけることであり、型や意味を明示することは目的ではなく、手段です。ハンガリアン記法は手段の1つであり、常に万能であるわけではありません。1つのローカルにある変数が数個しかないのに、それにハンガリアン記法を使うのは馬鹿げています。一方、数十個の変数を1つのローカルで定義しないといけないのであれば、アプリケーションハンガリアン記法は有効でしょう。
その辺の事情はプログラミング言語やスタイルによって変わってきます。手続き型のスタイルであれば、ローカル内で定義する変数が多くなるので、アプリケーションハンガリアン記法が必要になるでしょう。一方、関数型やオブジェクト指向のスタイルであれば、関数やクラス内の変数が減るので、アプリケーションハンガリアン記法は冗長になるだけです。
私の場合、最近はSchemeとExcelのマクロ、過去にはJavaとObjective-Cを使っていましたが、アプリケーションハンガリアン記法を使うのはExcelのマクロの場合だけです。他の言語の場合、便利なクラスが既にあったり、クラスや関数を定義するので、ローカルで定義しないといけない変数が少なく、略語や1つの単語で命名してコメントを書き加えておく方が、後でずっと読みやすいです。
その代わり、関数名やクラス名、定数は冗長にしてあります。これは比較的グローバルに使い回しますし、アプリケーションハンガリアン記法を使わないのは、そのために分類して略語を決めるのが難しく、後で見るときも、意味が分かりにくいからです。引数と戻り値と機能を名前に適切に持ち込むためには冗長になっても仕方のないことです。
最近の事情からすれば、システムハンガリアン記法はおろか、アプリケーションハンガリアン記法でさえ、批判の的になることは不思議なことではない気がします。
以上、趣味のプログラマの感想。
Re: (スコア:0)
Conclusion Do not use qualifiers when not needed, even if they seem valuable.