変数タイプの省略形を変数名の前に付けますか？ （ハンガリー語表記）
私の現在の仕事では、コーディングのガイドラインはありません。誰もが彼が望む方法でほとんどコーディングします。会社が小さいので、それは結構です。
しかし、最近1人の新しい男が常にハンガリー表記法を使用することを提案しました。これまで、ハンガリーの表記法を使用していた人もいましたが、使用しなかった人もいます。ご存知のように、それはエンジニアリング会社であるため、アルゴリズムが適切である限り、コーディングスタイルは重要ではありません。
個人的には、これらの小さなタイプの省略形は冗長であると感じています。よく考えられた名前は通常同じメッセージを伝えます。 （さらに、ほとんどのコードは、boolやfloatのような概念が存在しない一部の奇妙なDSPで実行する必要があります）。
では、ハンガリー記法についてどう思いますか？使用しますか？どうして？
ほとんどの人が「ハンガリー記法」と言うとき、彼らは実際には「 Systems Hungarian 」について話している。
システムハンガリー語は完全に役に立たないので、避ける必要があります。名前に変数のtypeをエンコードする必要はありません。ただし、システムハンガリー語は、実際にはオリジナル、「本当の」ハンガリー語、アプリハンガリー語の誤解です。
Apps Hungarianでは、変数名の「タイプ」をエンコードするのではなく、変数の「種類」をエンコードします。したがって、nWidthではなく、pxWidthまたはemWidth（それぞれ「ピクセル単位の幅」または「ems単位の幅」）です。 strNameではなくsNameまたはusName（それぞれ「安全な名前」または「安全でない名前」-ユーザーからの入力を受け入れるときに便利：安全でない文字列）。
個人的に、私は通常どちらも気にしません。値の「種類」を明示的に変換することを行わない限り（たとえば、pxArea = emWidth * emHeightのような間違いを犯すため、過去に「px」と「em」の接頭辞を使用しました）。
Joelの記事「 Making Wrong Code Look Wrong 」も参照してください。
pronounYou verbShould adverbNever verbUse adjectiveHungarian nounNotation、prepositionIt verbMakes collectivenounEverything adverbSo relativeBloody adjectiveHard infinitiveTo verbRead。
まず：
ご存知のように、それはエンジニアリング会社であるため、アルゴリズムが適切である限り、コーディングスタイルは重要ではありません。
会社に関係なく、コーディングスタイルは重要です。はい、アルゴリズムhaveは適切ですが、コードmustは、元の開発者だけでなくすべての人が保守できる必要があります。スタイル要素を含むコーディング標準を持つことは、それを達成するための何らかの方法になります。すべてのコードのスタイルが同じである必要はないと言っているわけではありません。逆に生産性は低下しますが、ある程度の一貫性が必要です。
ハンガリー語表記に移ります。
IntelliSenseタイプの動作をサポートする最新のIDEを使用しているため、名前に変数のタイプを含める必要はありません。この情報は、他の方法で利用できます。さらに悪いことに将来、変数の型を変更する必要がある場合、コードが読みにくくなる可能性があります。
使用しないでください。これは冗長であり、コードを読みにくくします。
（システム）ハンガリー語表記法に関する多くの議論は、仕事の分野に依存します。私は以前「無理」の側に非常にしっかりといましたが、組み込み開発に使用される会社で数年間働いていたので、特定のアプリケーションでそれのいくつかの利点を見ることができ、それは間違いなく私に成長しました。
システムハンガリー語
私の知る限りでは、システムハンガリー語は組み込み分野でよく使用されます。 PCアプリケーションでは、コンパイラーは（例えば）文字列、整数、浮動小数点値の違いに関連する多くの問題を扱います。深く埋め込まれたプラットフォームでは、8ビットの符号なし整数、16ビットの符号付き整数などの違いを懸念することがよくあります。コンパイラー（またはMISRAルールが適用されたlintでも）は、これらを常に認識するとは限りません。この場合、u8ReadIndex、s16ADCValueなどの変数名を使用すると便利です。
アプリハンガリー語
アプリハンガリー語には、PC/Webアプリケーションに関して明確な利点があります。たとえば、「安全でない」文字列と「安全な」文字列（つまり、ユーザーが入力した文字列と、内部リソースなどからエスケープまたは読み取られた文字列）の視覚的な違いを提供します。 ）。コンパイラーはこの違いを認識していません。
ポイントは何ですか？
（システムまたはアプリ）ハンガリー語の使用は、間違ったコードが間違っているように見えるを作成することです。
安全でない文字列をエスケープせずに安全な文字列に直接コピーする場合、Apps Hungarianを使用すると正しく表示されません。
符号付き整数と符号なし整数を乗算している場合、コンパイラーは（多くの場合、黙って）符号付き整数を（可能性のある）符号なし整数に昇格させ、おそらくエラーが発生します。システムハンガリー語はこれを間違ったように見せます。
これらの状況の両方で（アプリ/システム）ハンガリー語表記は、変数の型への参照が少なくなるため、正式なコードレビューを迅速化する傾向があります。
全体
全体として、私の意見は、最も重要なことは、コーディング標準があるということです。 Systems Hungarian、Apps Hungarianのどちらを使用するか、どちらも使用しないかは、インデントの種類の選択などと同様に、個人またはグループの好みの問題です。ただし、同じ好みに取り組む開発チーム全体には明確な利点があります。
ハンガリー語表記法の目的は、他の方法では型システムでエンコードできない情報を識別子にエンコードすることです。私の意見では、この情報がエンコードされるのに十分に重要である場合、適切にチェックできる型システムでエンコードされるのに十分に重要であるということです。そして、情報が重要ではない場合、なぜソースコードを混乱させたいのでしょうか。
または、より簡潔に言うと、型情報は型システムに属しています。 （注：static型システムである必要はありません。型エラーをキャッチする限り、私は気にしませんwhenキャッチします。）
他のいくつかの回答では、ハンガリー記法の許容される使用法として測定単位について言及しました。 （ハンガリー記法についての議論でいつも出てくるように思われるので、NASA火星気候オービターについて誰も言及していなかったことにちょっと驚いています）。
F＃の簡単な例を次に示します。
[<Measure>] type m
[<Measure>] type ft
let someLength = 48.15<m>
let someOtherLength = 16.2342<ft>
someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.
ほら、ママ、ハンガリー人じゃない！
ここでタイプの代わりにハンガリー表記法を使用するがあった場合、それは私に少し助けにはなりません：
let mSomeLength = 48.15
let ftSomeOtherLength = 16.2342
mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842
コンパイラーはそれをそのまま通過させました。私は今humanに依存して、本質的に型エラーを見つけています。これは型チェッカーの目的ではありませんか？
さらに、 Frinkプログラミング言語 を使用します。
someLength = 48.15m
someOtherLength = 16.2342ft
someLength + someOtherLength
// 53.09818416 m (length)
// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992
// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15
// ... or a fundmentalist Christian who refuses to use units invented
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006
要約すると、私はハンガリー記法が好きではありません。絶対に使用しないでください。
そうは言っても、ハンガリー記法を使うのは良い考えだと思います。待って、何？
はい！この特定のケースで、あなたは言及しました：
さらに、ほとんどのコードは、boolやfloatのような概念がとにかく存在しないいくつかの奇妙なDSPで実行する必要があります。
しかし、それが正確に唯一の賢明な使用例forハンガリー語表記です！
PS：私は心からフリンクを見ることをお勧めします。そのマニュアルには、これまでで最も素晴らしいおならジョークのいくつかが含まれています。それはかなりクールな言語でもあります:-)
嫌です！
ハンガリー語の表記やその他の表記は使用しないでください。プログラマーとして、変数名に「表記法」を使用するべきではありません。
変数に名前を付ける：
- 一般的な名前は避けてください。名前付きオブジェクト（電話料金など）を表すクラス変数の場合は、
zという名前を付けないでください。それをphoneBillまたはPhoneBillと呼びます。 具体的な名前は避けてください。追加情報なしで何かが明らかな場合は、それを含めないでください。それが文字列の文字をループするための文字列インデックス変数であり、関数MyFuncで1回だけ使用する場合、なぜこれを
MyFuncTempStringCharacterIndexと呼ぶのでしょうか？それは悲しい冗談です。Pos、またはiと呼びます。コンテキストでは、次のプログラマーはそれが何を意味するかを簡単に理解するでしょう。名前がどの程度一般的または具体的であるかを理解するときは、そのドメインが属するドメインと、他の考えられる意味のコンテキストを考慮してください。同じように使用される2つの混同されやすい類似タイプのアイテムがある狭いケースでは、その違いを示すために接頭辞または接尾辞を考え出すのは問題ありません。できるだけ短くしてください。
他の回答者が言ったように、「Apps Hungarian」を開始したのはこの狭いケースであり、ウィンドウrwTabPositionに対する相対的な測定とドキュメントrdTabPositionに対する相対的な測定を区別します。ただし、ドキュメントに関連してすべてを行うアプリケーションでは、余分な情報を追加しないでください。実際、実際に新しい型を作成する JörgW Mittagのアイデア を使用しないのはなぜですか？そうすれば、混乱する可能性はありません。
ほとんどすべての領域で、意味密度が最小限の要素を追加すると、全体的な意味と理解のしやすさが低下します。これが Ben Franklinの1つの例 です。そして別の例：英語で私たちの言葉を品詞で飾ることができます。もっと詳しい情報ですね。英語の初心者が混乱した場合、それは彼らにとって本当に役立つかもしれませんね？これを読んで、これが長期的な理解と効率的な情報の提供にどれほど役立つかを教えてください。
vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation。 prepAs nouprogrammers、prowe vrbshould advnot noveuing "nounotation" prp for proour adjvariable nounames。
adding情報によって、私はそれを完全に読むのは苦痛にしました。
表記を忘れてください。常に追加する特別なプレフィックスを忘れてください。私の意見では、ここでの唯一の実際のガイドラインは次のとおりです。
変数名はshortとして、必要に応じて意味のあるとしてください。常に明確。
オブジェクト指向言語では意味がありません-すべては、それを使用しようとしたときに明らかなタイプです。
Systems Hungarianが保証されている唯一の場所は、Cのような弱く型付けされた言語です。明示的なオブジェクトがないため、Cでは二重に重要です（構造体があります） 、ただしすべての関数は構造体の外部にあります）。 C++、Java、C＃などのより強く型付けされたものでは役に立たず、実際に事態は悪化します。コードが変更され、変数名を使用しているすべての場所を変更するよりも、タイプを変更する方がはるかに簡単です。無視される傾向があるのは、不必要な忙しい作業でもあります。
測定単位がある場合は、それを名前にエンコードすると役立つ場合がありますが、最終的には余分なノイズになる可能性もあります。たとえば、コードで使用するさまざまなものの標準測定単位を宣言します。たとえば、グラデーションまたは度、メートルまたはフィート、フレームまたはミリ秒を使用していますか？コードの標準が設定されると、1つの測定単位を読み取るたびに、常にコードの標準測定単位に常に変換されます。
私のアドバイス：現在の問題点から始めて、コードのその部分に適した標準を選択します。コーディング標準を過剰に指定すると逆効果になります。変数名とフィールド名が何を表しているかを詳しく説明することには多くの価値があり、ほとんどの場合、概念から型を安全に推測できます。
識別子の目的は、そのタイプよりも重要です。プログラムで識別子にわかりやすい名前を使用する場合、ハンガリー語の表記法を使用する必要はありません。 isConnectedは常にboolConnectedより読みやすく、理解しやすいです。
私がC++プログラマだった頃はハンガリー語を使っていましたが、それは素晴らしいことでした。宣言を検索しなくても、変数のタイプ（BSTR、CString、LPCTSTR、char *など）を確認できます。当時は、次のようにして宣言を検索します。
- ctrl-home
- ctrl-F
- 変数名
- 入る
だからそれはかなり重要でした。しかし、2000年頃のどこかで、いくつかのことが起こりました。
- エディターは、変数の型をツールチップとして表示するのに十分インテリジェントになった
- 編集者には「宣言に戻る」ショートカットがあり、すばやく戻ることができました
- C++はあまり使用されておらず、他のほとんどの言語では変数型が少なくなっています。たとえば、C＃では、
lastNameがSystem.String、文字列クラスが1つしかないため。
私はハンガリー語から切り替える最後の一人でした、そして今私が古いソースコードを読んだとき、それは実際に私を困らせます。
私はハンガリー語の表記法が嫌いです。変数名を区切るよりもアンダースコアを使用することを好みます。
その上で、変数名の先頭に次のように最初の文字として型を置くと、次のようになります。float fvelocity; vect vDirection;文字列** ppszWord;
オートコンプリートはそれらすべてをソートし、必要なものを見つけるのが困難になり、人々はより良いと思うものを使用する傾向があり、もはや表記ではありません。
変数を非常に説明的にする必要がある場合は、ThingsLikeThatを記述します。これは、スペースを節約し、キャップがあるという事実により、変数が読みやすくなるためです。
私が通常行うことは、メソッドとクラスに最初の文字を大文字、変数名を小文字にし、変数名をアンダースコアにして名前を付けることです（最後の1つが便利だと思います）。
真剣に私は人々にそれらのルールを気にかけることを好む：関連するスペースでコンマ、算術、中括弧を使う：
void f(int a, char b);
int a = b + 4 / (3 + 4);
1行あたり80文字以下、またはAT MOST 90文字。関数には複数行の引数を使用するか、長いif：
if
(
checkthat(a, b) == checkthis(b, d) &&
checkthat(d, b) == checkthis(v, d)
)
ほとんどの人に同意する、それは古いスタイルです。
最新のIDEでは、変数にすばやくカーソルを合わせるとタイプが表示されます。