パスワードを忘れた? アカウント作成
13505942 journal
日記

yaegakiの日記: システムハンガリアン記法の費用対効果 12

日記 by yaegaki

C言語のレガシー・プログラマですが

 この記法のコストとして変数の型を変更した場合に、変数名を変更しなければならなくなり、変更量が多くなるという議論がある。
 しかし、型を変更したらその変数の利用箇所を全てチェックするという流儀の場合は、チェックするついでに変数名を変更すれば良いので、記法による”余分な”コストは見た目より小さいのではないか。

 レビューや(他人のコードの)デバッグでは便利なことも多い。
中級未満のプログラマのレビューだと型について指摘することもある。一見して型がわかるので、コードを読む分には楽ができる(逆にコードの編集にはそれだけ手間がかかる)
 スキルが低いほど規約で縛った方がレビューとデバッグでの可読性が高いと思っている。そういうメンバーが参画する場合は、システムハンガリアンを採用したくなるかもしれない。

 変数名が長くなるという指摘もあるが、グローバル変数の"g_"などは未だに使われているので、場合によっては冗長な変数名も有用だということだろう。長さより、見慣れているかそうでないかという要因の方が大きいのではないか(メソッド名は長いこともあるし)

 この記法に反対する主張でもっとも共感できたのは、実装を意識させるような表現を避けたいというもの。
 それと開発環境の高機能化。Visual StudioでC#で書いていると、確かにシステムハンガリアン要らないかな、とも。

 プログラマになって最初の数年間、エディタとGDBで開発していて、その現場がシステムハンガリアンだった。
 なので習い性というのはあるだろうけど、全体としてはシステムハンガリアンの費用対効果はそこまで悪くないように思うが、いかがでしょうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by wood377 (46309) on 2018年01月18日 23時12分 (#3347238) 日記

    どんな環境で作業されているか知りませんが、、
    最近のVisual Stdio だと変数名を変更すると、まとめて変更してくれるサービスまであるので、変更漏れのリスクが減ってる気がするけど、どうでしょう。
    ただ、誤記を直しても同じようにメッセージがでるのでうっかり、OKなどすると大変ですが。

    もっとも自分はエディタが書く量の方が多い気はする。

    そしてシステム全体の整合性の方が大切でしょうが。

    • by Anonymous Coward

      >変更漏れのリスクが減ってる気がする

      そもそも変更する必要がなければ(システムハンガリアンを採用しなければ)変更漏れのリスクも0ですね。

  • by Anonymous Coward on 2018年01月19日 10時51分 (#3347413)

    しかし、型を変更したらその変数の利用箇所を全てチェックするという流儀の場合は、チェックするついでに変数名を変更すれば良いので、記法による”余分な”コストは見た目より小さいのではないか。

    『チェックするついでに変数名を変更』という、 2つの作業を一遍にやるのは思っている以上に負荷が高くミスしやすいという印象があります。チェックならチェックだけを集中してやった方が良い。

    となると、変数名の変更はチェックの前または後に一括して行うことになり、チェックの『ついで』ではない余計な作業になりますが、それをするほどのメリットがあるかどうか。

    個人的には、変数の用途が明確になっていればその変数の型は自然と決まってくると思うので、変数を使用している個々の箇所でその変数の型が分かることよりも、まず全体を通してその変数の用途が明確に分かることが重要で、その上でその用途にあった型が選択されているかをチェックするのは、その変数が宣言されている箇所の 1回だけで良いという印象です。

  • by Anonymous Coward on 2018年01月18日 19時11分 (#3347111)

    型を変更したらその変数の利用箇所を全てチェックするという流儀の場合は、チェックするついでに変数名を変更すれば良いので、記法による”余分な”コストは見た目より小さいのではないか。

    は同意できるけど、

    一見して型がわかるので、コードを読む分には楽ができる

    型と一致しない変数名がついている場合はどうでしょうか。

    int fFoo = 0;

    floatかとおもったら、実はintでした。
    と思いきや、実はboolの代用でintを使用していて、0か1しか代入してはいけない、とか。

    • by Anonymous Coward on 2018年01月19日 9時00分 (#3347334)

      型と一致しない変数名がついている場合はどうでしょうか。

      int fFoo = 0;

      floatかとおもったら、実はintでした。

      規約で縛るので、型宣言の箇所でコードレビューにはねられるし、
      型宣言と初期値設定が離れていたとしてもfloatに0(int)を代入する時点ではねられるのでは?

      実はboolの代用でintを使用していて、0か1しか代入してはいけない

      同様にbool引数に渡す箇所ではねられたり、気の利いたレビュワーなら0や1との比較しかしていない時点で型変更するよう提案するかも?

      親コメント
      • by Anonymous Coward

        自分たちでコントロールできるソースならレビューでチェックできるけど、
        外部のソース(デバイスドライバとか)だとそうもいかない。

        # int⇒float代入では暗黙の型変換があるので警告はでてもエラーにはならないんじゃ?
        # boolは型自体がないという罠

        • by Anonymous Coward

          boolはC99から導入されたのを忘れてた。
          だからといって自分の環境で使えるかは別問題

        • by Anonymous Coward

          # int⇒float代入では暗黙の型変換があるので警告はでてもエラーにはならないんじゃ?

          文章が継続しているので、コンパイラではなくレビュワーによってはねられるということです。

          boolは型自体がないという罠

          システムハンガリアン記法の場合、処理系に型が用意されているかどうかとは別に命名しませんか?
          極端な話、動的型付き言語の場合システムハンガリアン記法が使えなくなってしまいます。

    • by Anonymous Coward

      レビューのときはコメントも削除すべきとかいう話もあるよね。
      デバッグやレビューのときは、なんでも疑ってかかるものかと。

      基本的に型というのはあまりに重要なので、メモがないと忘れるとか
      ありえないです。と激しく思いたい。

  • by Anonymous Coward on 2018年01月19日 1時20分 (#3347269)

    > この記法のコストとして変数の型を変更した場合に、変数名を変更しなければならなくなり、変更量が多くなるという議論がある。
     
    この主張は古すぎると思います

    clang/llvmなどが登場してから
    リファクタリングツールの性能が大幅に向上しています(rtags とか)

    今時 emacs や vi でさえ変数名は自動かつ正確に置換できますよ

    • by Anonymous Coward

      自動かつ正確に置換できる代わりに
      >型を変更したらその変数の利用箇所を全てチェックするという流儀
      に合わなくなるのでは。

      • by Anonymous Coward

        差分は git で抽出できるし
        型チェックはコンパイラの仕事

        どこを切り出しても思想が古いと思います

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...