1

それは良い習慣か悪い習慣か？私の友人は、一般的に言えば、最近ではほとんどの言語で良い習慣とは見なされていませんが、fortran ではそうではないことを聞いたと思ったと言っていました。これは本当ですか？それが本当なら、なぜですか？

4

3 に答える 3

6

Fortran で 30 年以上のプログラミングを行ってきましたが、ハンガリー語の表記法を使用している人に出会ったことはありません。あなたの友人は、名前の最初の文字に応じて変数を暗黙的に型指定する Fortran の長年の (そして現在は推奨されていない) 機能を混乱させているかもしれません。しかし、それは、現在ハンガリー記法と呼ばれるものが広く知られるようになるよりもずっと前のことです。

Fortran を書く際にハンガリー記法を採用するのが良いアイデアであるかどうか、または採用するのが良いかどうかというより一般的な問題について、私は David に同意します。 . Fortran は確かにそれを必要としません。変数 (およびその他の) 名は、多くのプログラミング言語と非常によく似た規則に従います。

于 2012-05-13T21:40:34.897 に答える
5

システムハンガリー語

システム ハンガリアン表記法は、基本的に変数名に型情報を追加するため、使用している値の型がわかり、値を誤った方法で使用する可能性が低くなります。型安全性により、変数を誤って使用/アクセスする可能性が大幅に減少するため、これは現代の強く型付けされた言語では疑わしい利点です。

ただし、それほど強く型付けされていない言語の場合、この種の情報を含めることは、プログラマーが扱っているデータを常に認識できるようになるため、有益な場合があります。

HN の最大の批判 (強く型付けされた言語での利点が限られていることに加えて) は、使用される型プレフィックスが非常にあいまいで紛らわしい変数名になる可能性があることです。保守性を損なう可能性があるコードの明快さ (または少なくとも、規則の専門家であるためにのみ読み取り可能なコードを作成する)。

他の誰かの命名規則に合わせてコードを生成する必要がある場合、選択の余地はほとんどありませんが、管理できる場合は、変数名の作成とのバランスを取りながら、ニーズにより適した、賢明で明確で単純な命名規則を定義できます。情報が豊富で混乱を招きます。たとえば、動詞と名詞の両方として使用できる単語の混同を避けるために、ブール変数にIsOpenではなくの形式で名前を付けることが 1 つの方法です。Openまた、ブール値を整数または浮動小数点式に混在させている場合も簡単に確認できます。このアプローチは直観的にも機能するため、プログラマーがコードを読んで理解するために特別な知識は必要ありません。

ハンガリー語のアプリ

最初のコメントに応えて、別の形式のハンガリー語表記 (Apps Hungarian) があります。より詳細な説明については Wikipedia を参照してください。ただし、基本的には、変数の使用法または目的に関する情報を、変数のタイプではなく名前に関連付けます。

強く型付けされた言語では、これははるかに有用なアプローチであり、検討する価値があります - または少なくとも (IMHO) 概念上。選択された接頭辞は、かなり複雑で友好的でない傾向があることがよくあります（たとえばrw、row私の考えでは、実用的な利益なしに接頭辞を難読化するだけではありません）。また、多くの例はかなり無意味だと思います (たとえばstr、変数が文字列であることを示すことは、多くの言語では冗長です。文字列は 1 つの形式でしか表現されないことが多いためです。また、変数の名前が適切に付けられている場合 ("Data" ではなく "UserName") ) それが文字列であることは明らかです)。

現代のオルタナティブ

私の意見/経験では、通常重要なことは、変数間のいくつかの重要な違いを明確にすることです (たとえば、メンバー、ポインター、揮発性、および定数を互いにまったく異なる方法で扱う必要があります。メンバーとパラメーターを混同したり、配列に間違ったインデックスを付けたりするなど)。インデックス変数は壊滅的なものになる可能性があり、最新のコンパイラはこれらの間違いから私たちを守るためにほとんど何もしません)。リストと文字列の違いは、賢明で記述的な変数名が使用されている場合、通常は明らかです。型安全な言語は、これらの型が混在しているかどうかを教えてくれるため、これらの場合には接頭辞は必要ありません。これは、このスタックオーバーフローの質問に対する私の回答で説明されている、私自身の非常に単純なプレフィックスアプローチにつながりました。

この投稿が、プレフィックスが有益かどうかを判断する際の参考になれば幸いです。最終的に、適用するプレフィックス スキームは、あなたとあなたのチームにとって有益であると信じている (または証明できる) ものである必要があります。他の誰かのスキームに従うだけではなく、プレフィックスがどのように、そしてなぜ役立つかを考え、それを採用または破棄する前に客観的に評価してください。

于 2012-05-13T21:41:14.787 に答える
2

それは、言語よりも開発環境とチームの標準に大きく依存します。たまたま Fortran を使用しているが、コード分析とナビゲーションを備えた優れた IDE を使用している場合、おそらくハンガリー語表記は必要ありません。

自問すべき本当の質問は、「ハンガリアン記法で何が得られるか?」ということだと思います。

つまり、その価値は何ですか？古い言語を使用している場合でも、優れたコーディング プラクティスとテクニックを適用できます。ルーチンを小さく保ち、変数のスコープを小さく保つなどです。現在、私は Fortran の専門家ではないため、制限が何であるかはわかりません。しかし、私はそれが今でも当てはまると思います。

ハンガリアン記法は、限られたエディターを使用している場合 (たとえば、マウス ホバー時に変数に関する情報が表示されない場合) 、および変数の有効期間がかなり長い場合に特に役立ちます。つまり、変数の使用はその定義をはるかに超えて続きます。

はるか昔に Fortran が誕生して以来、私たちは業界として、コードの編成と開発チームでの効果的な作業について多くのことを学んできました。(チームがあなただけの場合でも...数か月以上前に書いたコードは、他の誰かが書いたものである可能性があることを忘れないでください。) これらの教訓を Fortran コードに適用できる場合があります。

有益な変数名を使用してください。ストレージは高価ではなく、モデムを介して文字を送信するのに時間がかかりません...変数の内容と意味に関する情報を伝達する場合、適度に長い変数名は受け入れられ、推奨されます。さらに、変数の使用をその定義に近づけてください。したがって、周囲のコードの追加のコンテキストにより、変数に関する名前だけでなく、より多くの情報が明らかになります。

つまり、アプリケーション全体で使用されるグローバル変数が呼び出さpriceれている場合、それを呼び出してdblPricedouble であることを示すと、変数名に有用な情報が追加されます。しかし、その有用な情報を追加するためのより有意義な方法があります。 priceそもそもスコープの広い変数の名前としては不適切であり、可能であればスコープを狭めることができるかもしれません。

于 2012-05-13T21:29:03.013 に答える