トップページ - 翻訳ドキュメント - ハンガリアン記法 by Doug Klunder
原文:http://www.byteshift.de/msg/hungarian-notation-doug-klunder
原文との対訳として読みたい方へ:このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
訳注※:上記リンク先のHTML文書には、さらに大元の非HTML文書が存在しているようです。そこからHTMLへの変換時に体裁の崩れている部分があるようで、推測で加筆/修正しています。そんな中でも大きく修正した部分(主にコードサンプル)には、「訳注※」としてコメントと原文とを記述しています。
Troff version at unlser1.unl.csi.cuny.edu Troff バージョンはこちら unlser1.unl.csi.cuny.edu
Bill Campbell and Joel Spolsky (joelonsoftware.com) state to have be informed personally by Doug Klunder that this text is in the "public domain" - see copyright info. I claim no rights to my HTML version (byteshift webdesign/info@byteshift.de), yet a backlink would be appreciated, should you want to mirror this page. 本稿が "パブリックドメイン(public domain)" であることを、Bill Cmpbell と Joel Spolsky (joelonsoftware.com) は Doug Klunder から直接知らされたことを明記しておく - 著作権 情報 を参照してほしい。私はこの HTML バージョンの権利を主張しない。しかしながらこのページをミラーしたいと望むなら、リンクをお願いしたい。
This document describes a set of naming conventions used by the IEMIS project in development of the software. The initial naming conventions where taken from a NAMING CONVENTIONS document authored by Doug Klunder at MicroSoft. These conventions commonly go by the name "Hungarian," referring both to the nationality of their original developer, Charles Simonyi, and also to the fact that to an uninitiated programmer they are somewhat confusing. Once you have gained familiarity with Hungarian, however, we believe that you will find that the clarity of code is enhanced. For convenience, this memo first describes how to use Hungarian, and then describes why it is useful; the general approach is from a programming viewpoint, rather than a mathematical one. この文書は、IEMIS のソフトウェア開発において使用されている命名規則に付いて説明する。NAMING CONVENTIONS 文書に由来する最初の命名規則は、マイクロソフトの Doug Klunder により書かれた。これらの規則は一般に "ハンガリアン記法(Hungarian)" という名で知られている。その名前は元もとの作成者である Charles Simonyi の国籍を表し、また同時に初心者プログラマをやや混乱させる元となっている。しかしながらひとたびハンガリアン記法に慣れ親しめば、コードの明確性が高まることに気付くだろう。簡便性のために、この文書はまずハンガリアン記法の使用法から説明し、次にそれが有益である理由を説明する。全体的なアプローチはプログラミングの視点から見たものであり、数学的な視点からのものではない。
Hungarian is largely language independent; it is equally applicable to a microprocessor assembly language and to a fourth-generation database application language (and has been used in both). However, there is a little flavor of C, in that arrays and pointers to arrays are not clearly distinguished. While this may sound confusing, in practice there is little ambiguity. ハンガリアン記法は大部分が言語から独立している。マイクロプロセッサのアセンブリ言語にも、第 4 世代のデータベースアプリケーション言語にも、等しく適用できる(そして実際にその両方で使用されている)。しかしながら多少 C 言語向けの要素が存在し、配列と配列へのポインタとが明確に区別されない。これは混乱しそうに思えるかもしれないが、実際にはあいまいさはほとんどない。
< prefix > < base type > < qualifier >
The most common type of identifier is a variable name. All variable names are composed of three elements: prefixes, base type, and qualifier. (These are also referred to as constructors, tag, and qualifier). Not all elements are present in all variable names; the only part that is always present is the base type. This type should not be confused with the types supported directly by the programming language; most types are application specific. For example, an 1b1 type could refer to a structure containing symbol information; a co could be a value specifying a color. もっとも一般的な種類の識別子は、変数名である。あらゆる変数名は 3 つ要素、接頭辞・基本型・限定子から構成される(これらは、コンストラクタ・タグ・限定子とも言及される)。常に与えられるのは基本型だけであり、すべての変数名にすべての要素が与えられるわけではない。ここで言う「型」をプログラミング言語が直接サポートする型と混同するべきではない。大部分の型はアプリケーションに固有である。例えば、型 lbl はシンボル情報を含む構造体を参照するかもしれないし、co は色(color)を表す値かもしれない。
Type that are not defined must be added As the above examples indicate, tags should be short (typically two or three letters) and somewhat mnemonic. Because of the brevity, the mnemonic value will be useful only as a reminder to someone who knows the application, and has been told what the basic types are; the name will not be sufficient to inform (by itself) a casual viewer what is being referred to. For example, a co could just as easily refer to a geometric coordinate, or to a commanding officer. Within the context of a given application, however, a co would always have a specific meaning; all co's would refer to the same type of object, and all references to such an object would use the term co. 未定義の型は前述の例のような形で追加されなければならず、タグは短く(一般には 2 文字か 3 文字)、多少覚えやすいものであるべきである。この短さのため、ニーモニックはアプリケーションを知る人にとってのリマインダとしてのみ使用され、それらの基本型が何であるかを表す。その名前は(それ自体では)、臨時の閲覧者にそれが何を表しているかを知らせるには不十分だろう。例えば co は幾何学座標(geometric coordinate)を表しているのかもしれないし、艦長(commanding officier)を表しているのかもしれない。しかしながらある特定のアプリケーションの枠内においては、co は一貫して固有の意味を持ち、すべての co が同じオブジェクトの型を参照し、その種のオブジェクトへのすべての参照は co を使用するだろう。
One should resist the natural first impulse to use a short descriptive generic English term as a type name. This is almost always a mistake. One should not preempt the most useful English phrases for the provincial purposes of any given version of a given program. Chances are that the same generic term could be equally applicable to many more types in the same program. How will we know which is the one with the pretty "logical" name, and which have the more arbitrary variants typically obtained by omitting various vowels or by other disfigurement? Also, in communicating with other programmers, how do we distinguish the generic use of the common term from the reserved technical usage? In practice, it seems best to use some abbreviated or form of the generic term, or perhaps an acronym. In speech, the tag may be spelled out, or a pronounceable nickname may be used. In time, the exact derivation of the tag may be forgotten, but its meaning will still be clear. 短く説明的で一般的な英語の用語を型名として使用するという自然な衝動は、抑えるべきである。大抵の場合それは間違いである。ある特定のプログラムの任意の特定のバージョンの狭い目的のために、一般的すぎる英語のフレーズを先取りするべきではない。そのような一般的用語は、同じプログラム内のさらに多くの別の型にも適用可能かもしれない。私たちは、どちらがより "論理的な(logical)" 名前であるかや、どちらがより独断的な(一般に様々な母音を省略するなどの変形によって得られる)変化形であるかを、どのようにして判断すればよいだろうか? また、別のプログラマとやりとりするとき、予約済みの技術用語と一般的な用語とを、どのようにして区別すればよいのだろうか? 実際問題として、一般的用語、またはその省略形か接頭語かを使用するのが最善と思える。会話の中ではタグを省略しないか、ニックネームを使用してよい。時がたつにつれてタグの正確な由来は忘れられるかもしれないが、その意味は明確さを保ち続けるだろう。
As is probably obvious from the above, it is essential that all tags used in a given application be clearly documented. This is extremely useful in helping a new programmer learn the code; it not only enables him (or her) to decode the otherwise cryptic names, but it also serves to describe the underlying concepts of the program, since the data types tend to determine how the program works. It is also worth pointing out that this is not nearly as onerous as it sounds; while there may be tens of thousands of variables in a program, the number of types is likely to be quite small. 上記の内容から明らかかもしれないが、特定のアプリケーション内で使用されるすべてのタグを明確に文書化することが必要不可欠である。これは新しいプログラマがコードを理解する際に非常に役に立つ。彼(または彼女)が暗号的な名前を解読できるようになるだけでなく、そのプログラムの基礎をなす概念の説明を提供する(データ型はプログラムがどのように動作するかを決定する傾向があるためである)。これは思ったほど煩わしいことではないことも指摘しておく。プログラム内には何万もの変数が存在するかもしれないが、それに比べれば型の数は極めて少ない。
Although most types are particular to a given application, there are a few standard ones that appear in many different ones; synonyms for these types should never be used: 大部分の型は特定のアプリケーションに特有なものになるが、多くの異なるアプリケーションに現れる標準的な型も少数だが存在する。そのような型の類義語は決して使用するべきではない:
There are some more types that appear in many applications; they should only be used for the most generic purposes: 多くのアプリケーションに現れる型がさらにいくつか存在する。これらはもっとも一般的な目的にためにのみ使用されるべきである:
There a few types that are used widely within the applications group, but may not be applicable to others: アプリケーショングループ内で広く使用される小数の型が存在するが、他には適用できないだろう:
Base types are not by themselves sufficient to fully describe the type of a variable, since variables often refer to more complex items. The more complex items are always derived from some combination of simple items, with a few operations. For example, there may be a pointer to an lbl, or an array of them, or a count of co's. These operations are represented in Hungarian by prefixes; the combination of the prefixes and base type represent the complete type of an entity. Note that a type may consist of multiple prefixes in addition to the base type (e.g., a pointer to a count of co's); the prefixes are read right to left, with each prefix applying to the remainder of the type (see examples below). The term constructor is used because a new type is constructed from the combination of the operation and the base type. 基本型だけでは変数の種類を完全に説明するのに不十分である。変数はしばしば、より複雑な項目を表すためである。通常そのようなより複雑な項目は、少数の働きを持つ単純な項目の組み合わせから導き出される。例えば lbl へのポインタ、それらの配列、co のカウントなどがあり得る。ハンガリアン記法においてこれらの操作は接頭辞により表され、その接頭辞と基本型とにより実体の完全な型を表す。型は基本型に加えて複数の接頭辞から構成されてもよいことに注意してほしい(例えば co のカウントへのポインタ)。接頭辞は右から左に読み、それぞれの接頭辞は型の残りの部分に適用される(後述の例を参照)。操作と基本型との組み合わせから新しい型が構築されるため、コンストラクタという用語が使用される。
In theory, new prefixes can be created, just as new types are routinely created for each application. In practice, very few new prefixes have been created over the years, as the set that already exists is rather comprehensive for operations likely to be applied to types. Prefixes that have been added tend to deal with the specifics of machine architecture, and are variations on existing prefixes (i.e., different flavors of pointers). Once can go overboard in refusing to create a new prefix, however; some new concepts really are logically expressed as prefixes, not types. A couple of examples of incorrect usage in the list below derived from the reluctance to create a new prefix. 理論上は新しい接頭辞を生成できる。それぞれのアプリケーションのために日常的に新しい型が生成されるのと同じである。既存の集合は型に適用されそうな操作をかなり広範囲に網羅しているため、実際のところここ数年で新しく登録された接頭辞はごく少数である。追加された接頭辞は、マシンアーキテクチャに固有のものを扱い、既存の接頭辞のバリエーション(つまりポインタの異なる特徴)である傾向がある。新しい接頭辞を作るのを拒否するために一度外に出ることができるが、一部の新しい概念は型ではなく接頭辞として論理的に表現される。後述のリスト内の誤った使用法の例のいくつかは、新しい接頭辞を作成することへの不本意に由来したものである。
The standard prefixes are: 標準的な接頭辞は以下の通り:
Since the prefixes and base types both appear in lower case, with no separating punctuation, ambiguity can arise. Is pfc a tag of its own (e.g., for a private first class), or is it a pointer to an fc? Such questions can be answered only if one is familiar with the specific types used in a program. To avoid problems like this it is often wise to avoid creating base type names that begin with any of the common prefixes. In practice, ambiguity does not seem to be a problem. The idea of additional punctuation to remove the ambiguity has been shown to be impractical. 接頭辞と基本型とは共に小文字であり区切りがないため、不明確さが生じる。pfc はただのタグ(例えば上等兵(private first class))だろうか? それとも fc へのポインタだろうか? このような質問は、その人がプログラム内で使用される特有の型に精通している場合にのみ答えられる。この種の問題を避けるために、一般的な接頭辞と同じ文字から始まる基本型名を生成するのを避けるのが、しばしば賢明である。実際問題としては、不明確さが問題となるようには思えない。不明確さを取り除くために区切りを追加するという考え方は、非実用的であることが明らかとなっている。
The following list contains both common and rarer usages: 以下のリストは、一般的な使用法とまれな使用法とを含む:
While the prefixes and base type are sufficient to fully specify the type of a variable, this may not be sufficient to distinguish the variable. If there are two variables of the same type within the same context, further specification is required to disambiguate. This is done with qualifiers. A qualifier is a short descriptive word (or facsimile; good English is not required) that indicates what the variable is used for. In some cases, multiple words may be used. Some distinctive punctuation should be used to separate the qualifier from the type; in C and other languages that support it, this is done by making the first letter of the qualifier upper-case. (If multiple words are used, the first letter of each should be upper-case; the remainder of the name, both type and qualifier always lower-case. There is one special case to watch out for; defined constants specifying the size of a type are often of the form cbFOO or cwFOO, where foo is the type. Strictly speaking only the F in FOO should be capitalized, but the incorrect usage is fairly common.) 接頭辞と基本型とは変数の型を完全に表すのに十分である一方、変数を区別するには十分ではないだろう。同じコンテキスト内に同じ型の二つの変数があるとき、あいまいさをなくすためには更なる指定が必要である。これは限定子で実現される。限定子は短い説明的な単語(または模写で、正しい英語である必要はない)であり、その変数が何に使用されるかを表す。場合によっては複数の単語を使用してもよい。型と限定子とを区切るために、何らかの区切りを使用するべきである。C やそれをサポートする他の言語では、限定子の最初の 1 文字を大文字にし、型と限定子の名前の残りを常に小文字にすることで実現される。(複数の単語を使用する場合、各単語の最初の文字を大文字にし、型と限定子の名前の残りを常に小文字にするべきである。注意するべき特別なケースがひとつある。型のサイズを表す定数の定義は、しばしば cbFOO または cwFOO となる(foo が型である)。厳密に言えば FOO の中の F のみを大文字にするべきだが、この間違った使用法が極めて一般的になっている。)
Exactly what constitutes a naming context is language specific; within C the contexts are individual blocks (compound statements), procedures, data structures (for naming fields), or the entire program (globals). As a matter of good programming style, it is not recommended that hiding of names be used; this means that any context should be considered to include all of its subcontexts. (In other words, don't give a local the same name as a global.) If there is no conflict within a given context (only one variable of a given type), it is not necessary to use a qualifier; the type alone serves to identify the variable. In small contexts (data structures or small procedures), a qualifier should not be used except in case of conflict; in larger contexts it is often a good idea to use a qualifier even when not necessary, since later modification of the code may make it necessary. In cases of ambiguity, one of the varibles may be left with no qualifier; this should only be done if it is clearly more important than the other variables of the same type (no qualifier implies primary usage). 名前付けコンテキストを構成するものが厳密に何であるかは、言語に固有のものとなる。C 言語では、コンテキストは個々のブロック(複合文)、手続き、データ構造(名前を持つフィールドのため)、プログラム全体(グローバル)である。優れたプログラミングスタイルとして、名前の隠蔽は推奨されない。つまり、任意のコンテキストはそのすべてのサブコンテキストを含むと考えるべきであることを意味する。(言い換えると、グローバルと同じ名前をローカルに与えるべきではない。) ある特定のコンテキスト内で衝突がなければ(ある型の変数がひとつだけなら)、限定子を使う必要はなく、型だけで変数を表す。小さいコンテキスト(データ構造または小さい手続き)内では、衝突する場合を除いて限定子を使用するべきではない。より大きいコンテキストでは、後のコードの修正がそれを必要とするため、必要でなくとも限定子を使用するべきである。あいまいな場合、変数のひとつを限定子なしのまま残してもよいが、これはその変数が同じ型の他の変数に比べて明らかに重要な場合にのみ行われるべきである(どんな限定子も主な用法を暗示しない)。
Since many uses of variables fall into the same basic categories, there are several standard qualifiers. If applicable, one of these should be used, since they specify meaning with no chance of confusion. In the case of multiple word qualifiers, the order of the words is not crucial, and should be chosen for clarity; if one of the words is a standard qualifier, it should probably come last (unfortunately, this suggestion is by no means uniformly followed). The standard qualifiers are: 多くの変数の使用法は同じ基本的なカテゴリーに分類されるため、いくつかの標準的な限定子が存在する。混乱なく意味を表せるように、適用可能であれば、これらのひとつを使用するべきである。複数の単語による限定子の場合、単語の順序は重要ではなく、明確性のために選択されるべきである。単語のひとつが標準限定子であれば、それを最後に置いたほうがよい(残念ながらこの提案は、決して一様に従うものではない)。標準限定子は以下の通り:
for(ich=ichFirst; ich<=ichLast; ich++)
for (cp=cpFirst,cpLim=cpFirst+dcp; cp<cpLim; cp++)
for(pch=pchMin; pch<pchMac; pch++)
訳注※:上記のコードサンプルは原文では以下のようになっています。 for(pch=pchMin; pch)
for (pch=pchMin; pch<=pchMost; pch++)
Note that the above qualifiers have a strict relationship: 上記の限定子は、以下のような厳密な関係を持つことに注意してほしい:
Min<=Mic<=First<=Last<=Most<Lim<=Mac<=Max
envSav=envMem; if (SetJmp(&envMem)) ... envMem=envSav; rwSav=rwAct; for (rwAct=rwFirst; rwAct<=rwLast; rwAct++) ... rwAct=rwSav;
訳注※:上記のコードサンプルは原文では以下のようになっています。 envSav=envMem; if (SetJmp(&envMem)) envMem=envSav; rwSav=rwAct; for (rwAct=rwFirst; rwAct<=rwLast; rwAct++) rwAct=rwSav;
When possible, structure members are named the same way variables are. Since the context is small (only the structure), conflicts are less likely, and qualifiers are often neither needed nor used. If the language does not support separate contexts for each structure (e.g., masm), the structure name is appended to the member as a qualifier. Thus, the following declarations are equivalent (the one on the left is for C, the one on the right for masm): 可能であれば、構造体メンバーは変数と同じ方法で命名されるべきである。コンテキストが小さい(構造体のみである)ため、衝突はそれほど起こりそうになく、限定子はしばしば不要であり、使用されない。各構造体のコンテキストの分離を言語がサポートしない場合(例えば masm の場合)、限定子として構造体名をメンバーに付加する。したがって、以下の宣言は等価である(左側は C 言語向け、右側は masm 向け):
typedef struct FOO struc { char *pch; pchFoo dw ? int w; wFoo dw ? char rgch[10]; rgchFoo db 10 dup (?) } FOO;
訳注※:上記のコードサンプルは原文では以下のようになっています。 typedef struct FOO struc { pchFoo dw ? char *pch; wFoo dw ? int w; rgchFoo db 10 dup(?) } FOO;
In some cases, one type is a special instance of another type. When this is the case, the special instance names should consist of the base instance name plus a character. For example, in Word there is a base type of CHR (character run); special instances are CHRF (formula character run), CHRT (tab character run), and CHRV (vanished character run). 場合によっては、ある型が別の型の特化インスタンスである。その場合、その特化インスタンスの名前は、基本インスタンスに 1 文字を加えて構成されるべきである。例えば、Word 内に CHR (character run)の基本型が存在する場合の特化インスタンスは、CHRF (formula character run)、CHRT (tab character run)、CHRV (vanished character run)などとなる。
Unfortunately, the simple rules used for variable names do not work as well for procedures. Whereas the type of a variable is always quite important, specifying how that variable may be used, the important part of a procedure is typically what it does; this is especially true for procedures that don't return a value. In addition, the context for procedures is usually the entire program, so there is more chance for conflict. To handle these issues, a few modifications are made to the simple rules: 残念ながら、変数名に使用される単純な規則は手続きではうまく機能しない。変数の型はその変数がどのように使用されるかを特定することで常に非常に重要である一方、手続きにおいて重要な部分は、それが何をするのかである。これは特に値を返さない手続きにあてはまる。さらに、手続きのコンテキストは通常プログラム全体であるため、衝突の可能性もより高くなる。これらの問題を扱うために、単純な規則に少し変更を加える:
Macros should be handled exactly the same way as procedures; for historical reasons, you may find some macros that do not follow the correct rules (e.g., min, bltbyte). マクロは手続きとまったく同じ方法で扱われるべきである。歴史的な理由により、正しい規則に従わないマクロを見つけることがあるかもしれない(例えば min、bltbyte)。
Labels can be considered to be a variant on procedures; they are after all effectively identifiers specifying a chunk of code. Within C, they are named similarly to procedures; they obviously neither return a value nor take parameters, so no types are specified. The first letter is upper case, and the name itself is just a few words specifying the condition that causes the label to be reached (either by falling through, or via a goto). Since the context of a label is limited to its procedure, these can be pretty generic terms; typical examples are GotErr, OutOfMem, LoopDone. ラベルは手続きの変化形であると考えられる。結局のところ、ラベルはコードのかたまりを特定する識別子である。C 言語の場合、その名前は手続きに似ており、値を返さず引数も取らないため、型は特定されない。最初の文字は大文字であり、名前自身はそのラベルに到達する条件(条件不成立か、goto によってか)を表す小数の単語だけである。ラベルのコンテキストはその手続き内に限られるため、ごく一般的な名前を採用することができる。典型的な例は、GotErr、OutOfMem、LoopDone などである。
Within assembly, labels are somewhat trickier. First off, there are many more labels used. Second, depending on the assembler, all labels may have global (or at least filewide) context. To deal with these constraints, the rules may be modified somewhat. For labels that are inserted solely because of assembler constraints (i.e., jumps corresponding to high level control flow constructs), temporary labels should be used. If the assembler supports true temporary labels (valid only within the current procedure, or up to the next global label), they should be used, in ascending numeric order. If true temporary labels are not available, the most common convention is to use the initials of the procedure, followed by a number, in ascending order. Of course, gaps should be left between numbers to facilitate later modification (initially setting to multiples of 10 works well). This is far from perfect, and can create conflicts between procedures that have the same initials; some people prefer to give all labels, temporary or not, full English names for clarity. For labels that correspond to true C labels, C conventions can be used; to avoid conflict, it is often useful to prefix with the procedure initials. アセンブリ言語の場合、ラベルは少々扱いにくい。第一に、ずっと多くのラベルが使用される。第二に、アセンブラによってはすべてのラベルがグローバル(または少なくともファイル全体)のコンテキストを持つ可能性がある。これらの制約を扱うために、規則をいくらか変更してよい。アセンブラの制約だけのために挿入されるラベル(つまり上位レベルの制御フロー構造)の場合、一時ラベルを使用するべきである。アセンブラが本当の一時ラベル(現在の手続き内のみ、または次のグローバルラベルまで有効)をサポートする場合、それを番号順に使用するべきである。本当の一時ラベルを利用できない場合、もっとも一般的な習慣は、その手続きの頭文字に続けて昇順の番号を使用することである。当然ながら、後の修正を手助けするために、各数字の間には間隔を空けておくべきである(初期値としては 10 の倍数がよいだろう)。これは完璧にはほど遠く、同じ頭文字を持つ手続き間での衝突を生じうる。一部の人々は明確性のために、すべてのラベル(一時ラベルであろうとなかろうと)に完全な英語名を与えることを好む。真の C 言語のラベルに対応するラベルの場合、C 言語の慣例を使用できる。衝突を避けるために、手続きの頭文字を前に置くのがしばしば好都合である。
As much as possible, defined constants should look just like variables of the same type. For many types, defined constants will exist for the Nil, Max, Min, and/or Last values. The program text will read exactly as if they are variables. There are three common exceptions, all originating in the mists of time, and unlikely to change soon. NULL is defined to be 0, and is used with all pointer types; TRUE and FALSE are defined to be 1 and 0, and are used with f types (correct Hungarian, practiced by some projects uses fTrue and fFalse instead of TRUE and FALSE). 定義済み定数は出来るだけ同じ型の変数と同じように見えるべきである。多くの型に対して Nil・Max・Min・Last のための定義済み定数値が存在するだろう。プログラムは、それらが変数であるかのように読めるだろう。長い年月の間に考え出され、すぐに変更されそうにない三つの一般的な例外がある。NULL は 0 と定義されるべきであり、すべてのポインタ型と共に使用される。TRUE および FALSE は 1 および 0 と定義されるべきであり、型 f と共に使用される(一部のプロジェクトによって実践される正しいハンガリアン記法では、TRUE および FALSE の代わりに fTrue および fFalse が使用される)。
There are often types for which each value is a defined constant; these are essentially equivalent to enumeration types supported by some languages (including some variations of C). These are typically types used for table-drive algorithms, for specifying options to a procedure, or specifying possible return values. Note that these types are in fact separate types; they are not all examples of the same type, nor are they values for the w type. Since they are special purpose (you can't pass an option for procedure x to procedure y with any meaning), they must be a new type. You can of course use your own method to name these types; it is often convenient to just use the initials of the procedure that takes or returns the type (watching out for conflicts). since they are type quantities, the type must be present in the names; possible values for colors are not RED, BLUE, YELLOW, GREEN, BLACK, etc., but rather could be coRed, coBlue, coYellow, coGreen, coBlack, etc. しばしば、各値が定義済み定数である型が存在する。これらは基本的に、一部の言語でサポートされる列挙型(いくつかの C 言語の変化形を含む)に等しい。一般にこれらはテーブル駆動のアルゴリズムのために使用され、手続きへのオプションを指定したり、可能な戻り値を特定したりする。これらの型が実際には個別の型であることに注意してほしい。それらはすべて同じ型の例であるとは限らず、また型 w のための値でもない。それらは特殊用途である(どのような方法でも、手続き x のためのオプションを手続き y に渡すことはできない)ため、それらは新しい型でなければならない。もちろん、これらの型を命名するために独自の方法を使用することもできる。その型を受け取るか返すかする手続きの頭文字を(衝突に注意しながら)使用するのが、しばしば好都合である。これらは型量子(type quantities)であるため、その型は名前によって表されなければならない。色(colors)のために取り得る値は、RED、BLUE、YELLOW、GREEN、BLACK などではなく、coRed、coBlue、coYellow、coGreen、coBlack などとなる。
Each structure is almost by definition its own type, and should be names as a type (two or three letters with some possible mnemonic value). By convention in C, the entire type name is capitalized in the definition of the type. The same rules apply to unions. Many of the projects find it convenient to include typedef's for each structure type; this means that the word struct is not included in declarations, and allows the redefinition of the type to an array, or even a simple type, without having to change all the declarations. Typedef's may also be suitable for non-structure types, particularly any that are not simple int's. 各構造体の大部分は定義上それ自身の型であり、型としての名前(2 文字または 3 文字に、いくつかのニーモニック値を伴なう)であるべきである。C 言語における慣例によって、型の定義において型名全体がキャピタライズされる。ユニオン(union)にも同じ規則が適用される。多くのプロジェクトが、各構造体のための typedef による型定義を含めるのが好都合であることを見出している。これは struct という単語を定義に含めないことを意味し、すべての定義を変更することなく、型を配列または単純な型へ再定義することを可能にする。typedef は、特に単純な int ではない非構造体の型にも適用可能だろう。
Before adopting a set of conventions, there are always two questions that must be answered: 規約を適用する前に、答えなければならない二つの質問がある:
The two questions are actually very closely related; answering the first will usually give an answer to the second, since knowing the goals allows one to see how closely a solution will meet the goals. For naming conventions, many of the goals are well-known, if not often formalized; most good programmers already attempt to meet the goals in a variety of ways. この二つの質問は実際には密接に関連している。目標を知ることで解決策がどれだけ綿密に目標を達成するするかを知ることができるため、通常、最初の質問の答えが第二の質問への答えになるだろう。命名規約の場合、形式化されていないとしても目標の多くはよく知られており、優れたプログラマはすでに様々な方法でその目標を達成しようと試みている。
An important need in naming objects in a program is the ability to remember what the name is, so that when the objects used, the programmer can quickly determine the name (which is the only way it can be used). Traditionally, this need has been met by using descriptive names for variables; for a given programmer working continually on a given program this is usually adequate. Problems arise, however, when a different programmer works on the project, or when the same programmer returns after a hiatus. What was once descriptive now has to be relearned. Hungarian helps somewhat in this respect, though it is not complete. The first part of a variable name can always be determined with no effort (it is the type), and if it is a standard use, the qualifier can also be determined (since it is one of the standard qualifiers). Non-standard qualifiers and procedure names can not be immediately determined; however, the situation is certainly no worse than the traditional situation, since the qualifier or procedure name has as much descriptive value as a traditional name. Furthermore, since there are fewer names that must be remembered (since one need not remember the standard ones), it is easier to remember them. プログラム内のオブジェクトを命名する際に重要な要求は、その名前が何であるかを思い出させる能力であり、それによりオブジェクトが使用されるとき、プログラマはその名前をすばやく判断できる(これがそれを使用できる唯一の方法である)。伝統的にこの必要性は、変数に説明的な名前を使用することで達成されてきた。ある特定のプログラムに関してある特定のプログラマが続けて作業する場合、一般にこれは適切である。しかしながら、そのプロジェクトで別のプログラマが作業する場合や、同じプログラマが休みのあとに戻ってきた場合に問題が起こる。説明的につけられた名前を再び学習しなければならない。完全ではないが、ハンガリアン記法はこの点で多少の手助けとなる。変数の最初の部分は常に労力なく判断できる(それは型である)上、もしそれが標準的な使用法であれば、限定子も決定する(標準限定子のひとつであるため)。非標準の限定子と手続き名とは、すぐに判断することができない。しかしながら、この限定子および手続きの名前は伝統的な名前よりも説明的な値を持つため、その状況は伝統的な状況よりもひどいものではない。さらに、覚えなければならない名前がより少なくなる(標準的な名前を覚える必要がない)ため、思い出すのはより簡単である。
At least as important as being able to go from an object to a name (the mnemonic value) is the ability to go from a name to an object (the suggestive value). This is most important when reading code written by someone else; this affects almost all programs today, either because multiple people are working on them, or because they are outgrowths of earlier programs. Again, the traditional approach has been to use names descriptive in some manner; Hungarian again improves the situation somewhat. For the relatively small cost of learning the types used in a given program, a reader gains a much better understanding of what the program does, since the types used in a statement often help determine the meaning of the statement. This is enhanced even more by the use of standard qualifiers; again, the non-standard qualifiers are at least as clear as the traditional names. オブジェクトから名前にたどり着けること(記憶を助ける値)と少なくとも同じくらいに重要なことは、名前からオブジェクトにたどり着けること(示唆的な値)である。これは他人の書いたコードを読む場合にもっとも重要なことである。プログラムに関して複数の人が作業しているため、またはそれが過去のプログラムの副産物であるため、これは今日のほとんどすべてのプログラムに影響する。さらに、伝統的なアプローチは何らかの方法で説明的な名前を使用してきたが、ハンガリアン記法はその状況を多少なりとも改善する。ステートメント内で使用される型はしばしばそのステートメントの意味を判断する手助けとなるため、ある特定のプログラム内で使用される型を学習するという比較的小さいコストで、読み手はそのプログラムが何をするのかをよりよく理解することができる。これは標準限定子の使用によりさらに高められる。一方で非標準の限定子は、少なくとも伝統的な名前と同程度には明確である。
Partially an aesthetic idea ("the code looks better"), this is also an important concept for the readability of code. Just as Americans often have an extremely difficult job following the action of Russian novels, since the same character goes by many different names, a programmer will have a difficult time understanding code in which the same object is referred to in unrelated ways. Similarly, it is confusing to find the same name referring to unrelated objects. This is a serious problem in traditional contexts, since English is a rich enough language to have many terms that roughly describe the same concept, and also terms that can describe multiple concepts. This problem is exacerbated when programmers resolve name conflicts by use of abbreviations, variant spellings, or homonyms; all of these methods are prone to accidental misuse, through typographical errors or simple failure to understand subtle differences. Hungarian resolves this problem by the use of detailed rules; since all names are created using the same rules, they are consistent in usage. ある程度は感性の問題("コードがきれいに見える(the code looks better)")だが、これもコードの信頼性のための重要な概念である。アメリカ人がロシアの小説の筋を追うは、同じキャラクターが多くの異なる名前で通っているため多くの場合非常に困難な作業であるように、同じオブジェクトが関係のない方法で参照されるコードを理解するのにプログラマは苦労するだろう。同様に、同じ名前が無関係なオブジェクトを参照していることが分かると混乱する。英語は同じ概念を大雑把に説明する多くの用語と複数の概念を説明できる用語とを持つ十分に豊かな言語であるため、これは伝統的な状況において深刻な問題である。プログラマが略語や異なるスペルや同音異義語を使用して名前の衝突を解決すると、この問題は悪化する。これらの方法はすべて、微妙に異なって理解される誤字や単純な間違いにより、思いがけない誤用を招く傾向がある。ハンガリアン記法は詳細な規則を使用することでこの問題を解決する。すべての名前が同じ規則を使用して生成されるため、それらの用法が一貫しているためである。
It is desirable to minimize the amount of time spent on determining names; in a sense this is wasted time, since getting the "right" name doesn't improve the program's efficiency or functionality. Since the traditional naming methods rely on good descriptions to meet the above goals, a programmer has to spend a goodly amount of time to in fact invent good descriptions; speedy name decisions are likely to result in unmnemonic, unsuggestive, or inconsistent names. In Hungarian, on the other hand, only a few name the same names, everyone's code will be similar, and therefore easy to read and modify. Traditional naming schemes are extremely unlikely to reach this goal, since English has far too many ambiguities to expect different individuals to describe things in identical terms. It would be naive to expect that Hungarian will cause all programmers to write code identically, or even to use identical names. The names are likely to be much more similar, however, since they are composed using the same rules, with the same types and standard qualifiers. 名前を決定するのに費やす時間を最小化するのが望ましい。"正しい(right)" 名前を得ることがそのプログラムの効率や機能性を改善するわけではないため、ある意味でそれは時間の無駄である。上記の目標を達成するのに伝統的な命名方法は優れた説明に依存するため、プログラマは優れた説明を発明するために多くの時間を費やさなければならない。拙速な名前の決定は、記憶を助けず、示唆的でなく、また一貫性のない名前を生じる可能性がある。一方でハンガリアン記法では、ごく少数が同じ名前を挙げるため、誰のコードでも似たようなものになり、したがって読みやすく、修正しやすいものとなる。異なる個人が同一の用語でものごとを説明すると期待するには英語はあいまいすぎるため、伝統的な命名方法はこの目標にまったく到達しそうにない。ハンガリアン記法によりすべてのプログラマが同一のコードを書くだろうと期待したり、同一の名前を使用すると期待したりするのは認識が甘いだろう。しかしながら、それらの名前は同じ型と標準限定子とを用いて同じ規則を使用して組み立てられるため、より似たものになるだろう。
Hungarian is a useful set of rules used to determine the names used in a program. There is no denying that it takes a little time to become familiar with it; true enlightenment comes only with effort. We strongly believe the results are worth the effort. The Applications Development group has been using Hungarian since its inception in 1981, and people at Xerox PARC were using it even earlier. The consistent use of Hungarian makes the programmer's job easier; it is both easier to write in Hungarian (there are fewer superfluous choices to make) and easier to read and modify existing code. The set of conventions is sufficient to deal with most current situations by itself; it has also proven adaptable to changes in the programming environment. Perhaps the best testimonial for Hungarian is the fact that a number of programmers have continued to use Hungarian even after leaving the jobs in which they encountered it; they have felt that the advantages were great enough to warrant the effort necessary to promote its use elsewhere. We hope that you will feel this way as well, once you become familiar with Hungarian's usage. ハンガリアン記法は、プログラム内で使用される名前を決定するために使用される実用的な規則である。ハンガリアン記法に精通するのに少しばかり時間が掛かることは否定できない。真の啓蒙は努力と共にのみある。これに努力の価値があることを私たちは強く信じている。アプリケーション開発グループは 1981 年の始めからハンガリアン記法を使用してきた。また Xerox PARC は、さらに以前から使用していた。ハンガリアン記法の一貫した使用はプログラマの仕事を簡単にする。ハンガリアン記法で書くことも簡単(為すべき余分な選択肢は少ない)であり、既存のコードを読んだり修正したりするのも簡単になる。この規約は、それ自体で現状の大部分を扱うのに十分である。プログラミング環境の変化に適応できることも証明されている。ハンガリアン記法に対する最大の証明は、多くのプログラマが、たずさわった仕事を離れた後でもハンガリアン記法を使い続けているという事実である。彼らは別の場所でハンガリアン記法の使用を勧めるのに必要な努力を正当化するに十分な利点を感じたのである。ハンガリアン記法の使用法に精通すれば、あなたも同じような気持ちになることを私たちは願っている。
Date Action 09/04/87 Original (DBK) 09/15/87 Moved to word; added some rarer types and pre- fixes and cleaned up other definitions in response to feedback. (DBK) 01/18/88 Added v type, sh prefix, and explanation of ha and 1 as prefixes applied to p for huge and far pointers. Also clarified use of From in pro- cedure names. (DBK) 04/10/90 Moved to nroff, changed references to OSAC to IEMIS (WKC)
Date: Fri, 20 Sep 91 15:12:53 -0700 From: sgihbtn!billc@uunet.UU.NET (Bill Campbell) Message-Id: <9109202212.AA04579@shared> To: uunet!umiacs.UMD.EDU!dalamb@uunet.UU.NET Subject: Re: Hungarian Notation References ... I have just talked with Doug Klunder at Microsoft. He says that publication of his paper is perfectly okay, they have not copyrighted it. It is, of course, their preference that the document be respresented as his/MS's work. From: "Joel Spolsky" <spolsky@fogcreek.com> To: <info@byteshift.de> Sent: Thursday, May 12, 2005 12:57 AM Subject: RE: joelonsoftware.com/articles/Wrong.html - Hungarian Notation/D. Klunder: link to clean HTML version ... Also I have heard personally from Doug Klunder himself that this file is in the "public domain".