yaegakiの日記: システムハンガリアン記法の費用対効果 12
C言語のレガシー・プログラマですが
この記法のコストとして変数の型を変更した場合に、変数名を変更しなければならなくなり、変更量が多くなるという議論がある。
しかし、型を変更したらその変数の利用箇所を全てチェックするという流儀の場合は、チェックするついでに変数名を変更すれば良いので、記法による”余分な”コストは見た目より小さいのではないか。
レビューや(他人のコードの)デバッグでは便利なことも多い。
中級未満のプログラマのレビューだと型について指摘することもある。一見して型がわかるので、コードを読む分には楽ができる(逆にコードの編集にはそれだけ手間がかかる)
スキルが低いほど規約で縛った方がレビューとデバッグでの可読性が高いと思っている。そういうメンバーが参画する場合は、システムハンガリアンを採用したくなるかもしれない。
変数名が長くなるという指摘もあるが、グローバル変数の"g_"などは未だに使われているので、場合によっては冗長な変数名も有用だということだろう。長さより、見慣れているかそうでないかという要因の方が大きいのではないか(メソッド名は長いこともあるし)
この記法に反対する主張でもっとも共感できたのは、実装を意識させるような表現を避けたいというもの。
それと開発環境の高機能化。Visual StudioでC#で書いていると、確かにシステムハンガリアン要らないかな、とも。
プログラマになって最初の数年間、エディタとGDBで開発していて、その現場がシステムハンガリアンだった。
なので習い性というのはあるだろうけど、全体としてはシステムハンガリアンの費用対効果はそこまで悪くないように思うが、いかがでしょうか。
最近は、、 (スコア:1)
どんな環境で作業されているか知りませんが、、
最近のVisual Stdio だと変数名を変更すると、まとめて変更してくれるサービスまであるので、変更漏れのリスクが減ってる気がするけど、どうでしょう。
ただ、誤記を直しても同じようにメッセージがでるのでうっかり、OKなどすると大変ですが。
もっとも自分はエディタが書く量の方が多い気はする。
そしてシステム全体の整合性の方が大切でしょうが。
Re: (スコア:0)
>変更漏れのリスクが減ってる気がする
そもそも変更する必要がなければ(システムハンガリアンを採用しなければ)変更漏れのリスクも0ですね。
変数(名)に重要なのは型よりも用途 (スコア:1)
『チェックするついでに変数名を変更』という、 2つの作業を一遍にやるのは思っている以上に負荷が高くミスしやすいという印象があります。チェックならチェックだけを集中してやった方が良い。
となると、変数名の変更はチェックの前または後に一括して行うことになり、チェックの『ついで』ではない余計な作業になりますが、それをするほどのメリットがあるかどうか。
個人的には、変数の用途が明確になっていればその変数の型は自然と決まってくると思うので、変数を使用している個々の箇所でその変数の型が分かることよりも、まず全体を通してその変数の用途が明確に分かることが重要で、その上でその用途にあった型が選択されているかをチェックするのは、その変数が宣言されている箇所の 1回だけで良いという印象です。
型はわからないよ (スコア:0)
型を変更したらその変数の利用箇所を全てチェックするという流儀の場合は、チェックするついでに変数名を変更すれば良いので、記法による”余分な”コストは見た目より小さいのではないか。
は同意できるけど、
一見して型がわかるので、コードを読む分には楽ができる
型と一致しない変数名がついている場合はどうでしょうか。
int fFoo = 0;
floatかとおもったら、実はintでした。
と思いきや、実はboolの代用でintを使用していて、0か1しか代入してはいけない、とか。
Re:型はわからないよ (スコア:1)
型と一致しない変数名がついている場合はどうでしょうか。
int fFoo = 0;
floatかとおもったら、実はintでした。
規約で縛るので、型宣言の箇所でコードレビューにはねられるし、
型宣言と初期値設定が離れていたとしてもfloatに0(int)を代入する時点ではねられるのでは?
実はboolの代用でintを使用していて、0か1しか代入してはいけない
同様にbool引数に渡す箇所ではねられたり、気の利いたレビュワーなら0や1との比較しかしていない時点で型変更するよう提案するかも?
Re: (スコア:0)
自分たちでコントロールできるソースならレビューでチェックできるけど、
外部のソース(デバイスドライバとか)だとそうもいかない。
# int⇒float代入では暗黙の型変換があるので警告はでてもエラーにはならないんじゃ?
# boolは型自体がないという罠
Re: (スコア:0)
boolはC99から導入されたのを忘れてた。
だからといって自分の環境で使えるかは別問題
Re: (スコア:0)
# int⇒float代入では暗黙の型変換があるので警告はでてもエラーにはならないんじゃ?
文章が継続しているので、コンパイラではなくレビュワーによってはねられるということです。
boolは型自体がないという罠
システムハンガリアン記法の場合、処理系に型が用意されているかどうかとは別に命名しませんか?
極端な話、動的型付き言語の場合システムハンガリアン記法が使えなくなってしまいます。
Re: (スコア:0)
レビューのときはコメントも削除すべきとかいう話もあるよね。
デバッグやレビューのときは、なんでも疑ってかかるものかと。
基本的に型というのはあまりに重要なので、メモがないと忘れるとか
ありえないです。と激しく思いたい。
少し主張が古いのでは? (スコア:0)
> この記法のコストとして変数の型を変更した場合に、変数名を変更しなければならなくなり、変更量が多くなるという議論がある。
この主張は古すぎると思います
clang/llvmなどが登場してから
リファクタリングツールの性能が大幅に向上しています(rtags とか)
今時 emacs や vi でさえ変数名は自動かつ正確に置換できますよ
Re: (スコア:0)
自動かつ正確に置換できる代わりに
>型を変更したらその変数の利用箇所を全てチェックするという流儀
に合わなくなるのでは。
Re: (スコア:0)
差分は git で抽出できるし
型チェックはコンパイラの仕事
どこを切り出しても思想が古いと思います