Мажар нотациясы: Айнымалы атауларының түсіндірмесі

Кіріспе

Идентификаторды атау нотациясы (компьютер ғылымдары)
Мажар нотациясы – компьютерлік бағдарламалаудағы идентификаторды атау конвенциясы, онда айнымалының немесе функцияның атауы оның мақсатын немесе түрін, немесе кейбір диалекттерде оның дерек типін көрсетеді. Алғашқы мажар нотациясы атау конвенциясында тек мақсатты немесе түрін қолданады және кейде «Apps Hungarian» деп аталады, себебі ол Microsoft Office қолданбаларын әзірлеуде Microsoft Apps бөлімінде кең таралды. Microsoft Windows бөлімі атау конвенциясын қабылдағанда, оны нақты дерек типіне негіздеді, және бұл конвенция Windows API арқылы кеңінен тарады; бұл кейде «Systems Hungarian» нотациясы деп аталады. Мажар нотациясы тілге тәуелсіз болу үшін жасалған және алғаш рет BCPL бағдарламалау тілінде қолданылды. BCPL-де машиналық сөзден басқа дерек типі болмағандықтан, тілдің өзі бағдарламашыға айнымалылардың типін есте сақтауға көмектеспейді. Мажар нотациясы бағдарламашыға әр айнымалының дерек типін нақты білу арқылы бұл мәселені шешуді мақсат етеді. Мажар нотациясында айнымалының атауы айнымалының типі немесе мақсатын білдіретін кіші әріптер тобынан басталады, содан кейін бағдарламашы таңдаған кез келген атау келеді; бұл соңғы бөлік кейде «берілген атау» деп аталады. Атаудың бірінші әрпін түр көрсеткіштерінен ажырату үшін үлкен әріппен жазуға болады (CamelCase-ті де қараңыз). Әйтпесе, бұл әріптің регистрі ауқымын көрсетеді.

Тарих

Венгриялық нотацияның түпнұсқасы 1972–1981 жылдары Xerox PARC-те жұмыс істеген, кейіннен Microsoft-тың бас архитектор болған Чарльз Симоньи жасаған. Нотацияның аты Симоньидің туған жерін еске түсіреді, сондай-ақ Энди Герцфельдтің сөзіне сүйенсек, ол бағдарламаларды «көне, түсініксіз шетел тілінде жазылғандай» көрінетін етіп жасады. Венгр халқының есімдері көптеген еуропалық есімдерден өзгеше, «кері» жазылады; әуелі тегі, содан кейін есім келеді. Мысалы, ағылшын тіліндегі «Чарльз Симоньи» есімі венгр тілінде «Симоньи Карой» болып жазылады. Сол сияқты, венгр нотациясында тип атауы «есімнен» бұрын тұрады. Smalltalk-тың ұқсас «тип соңында» атау стилі (мысалы, aPoint және lastPoint) Симоньи Xerox PARC-те жұмыс істеген кезеңде кең таралған. Симоньидің нотация туралы мақаласында сақталатын мәліметтердің «типін» көрсету үшін қолданылатын префикстер туралы айтылған. pX – басқа X типіне сілтеме; бұл өте аз семантикалық ақпаратты қамтиды. d – екі мән арасындағы айырмашылықты білдіретін префикс; мысалы, dY графиктің Y осі бойынша қашықтықты білдіруі мүмкін, ал y деп аталатын айнымалы абсолюттік орналасуы мүмкін. Бұл толығымен семантикалық сипаттама. sz – нөлдік немесе нөлмен аяқталатын жол. C тілінде бұл қандай да бір семантикалық ақпаратты қамтиды, себебі char* типіндегі айнымалы бір таңбаға, таңбалар массивіне немесе нөлмен аяқталатын жолға сілтеме жасайтыны белгісіз. w – сөзді білдіретін айнымалыны көрсетеді. Бұл дерлік ешқандай семантикалық ақпаратты қамтимайды және оны Systems Hungarian деп санауға болады. b – байтты көрсетеді, ал w-дан айырмашылығы, семантикалық ақпаратты қамтуы мүмкін, себебі C тілінде байт өлшеміне арналған жалғыз дерек типі – char, сондықтан олар кейде сандық мәндерді сақтау үшін қолданылады. Бұл префикс айнымалының таңба немесе сан ретінде қарастырылуы тиіс мәнді сақтай ма екендігі туралы түсініксіздікті жоюға көмектеседі. Нотация әрқашан бастапқы кіші әріптерді аббревиатура ретінде пайдаланады, бірақ аббревиатуралардың өзін белгілемейді. Көптеген кең таралған конвенциялар бар (төмендегі мысалдарды қараңыз), бірақ кодтың ішінде сәйкес келетін кез келген әріптер жиынтығын қолдануға болады. Apps Hungarian нотациясын пайдаланатын код кейде айнымалыларды тек олардың типі бойынша сипаттағанда Systems Hungarian элементтерін қамтуы мүмкін.

The original Hungarian notation was invented by Charles Simonyi, a programmer who worked at Xerox PARC circa 1972–1981, and who later became Chief Architect at Microsoft. The name of the notation is a reference to Simonyi's nation of origin, and also, according to Andy Hertzfeld, because it made programs "look like they were written in some inscrutable foreign language". Hungarian people's names are "reversed" compared to most other European names; the family name precedes the given name. For example, the anglicized name "Charles Simonyi" in Hungarian was originally "Simonyi Károly". In the same way, the type name precedes the "given name" in Hungarian notation. The similar Smalltalk "type last" naming style (e. g. aPoint and lastPoint) was common at Xerox PARC during Simonyi's tenure there. Simonyi's paper on the notation referred to prefixes used to indicate the "type" of information being stored. pX is a pointer to another type X; this contains very little semantic information. d is a prefix meaning difference between two values; for instance, dY might represent a distance along the Y axis of a graph, while a variable just called y might be an absolute position. This is entirely semantic in nature. sz is a null or zero terminated string. In C, this contains some semantic information because it is not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero terminated string. w marks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian. b marks a byte, which in contrast to w might have semantic information, because in C the only byte sized data type is the char, so these are sometimes used to hold numeric values. This prefix might clear ambiguity between whether the variable is holding a value that should be treated as a character or a number. While the notation always uses initial lower case letters as mnemonics, it does not prescribe the mnemonics themselves. There are several widely used conventions (see examples below), but any set of letters can be used, as long as they are consistent within a given body of code. It is possible for code using Apps Hungarian notation to sometimes contain Systems Hungarian when describing variables that are defined solely in terms of their type.

Белгілерге қатынасы

Кейбір бағдарламалау тілдерінде осыған ұқсас жазулар, қазір сигильдер деп аталады, тілге енгізілген және компилятормен күшімен орындалады. Мысалы, BASIC-тің кейбір түрлерінде name$ жол (string) екенін, ал count% бүтін сан (integer) екенін көрсетеді. Венгерлік нотациясы мен сигильдердің басты айырмашылығы – сигильдер тілдегі айнымалының типін анықтайды, ал венгерлік нотациясы бағдарлама мәтінін машиналық түрде түсіндіруге ешқандай әсер етпейтін, тек атау жүйесі болып табылады.

Ерекше пікірлер

Роберт Сесил Мартин (мажар нотациясына және кодтаудың барлық басқа түрлеріне қарсы): қазіргі уақытта HN және типтік кодтаудың басқа түрлері жай ғана кедергі келтіреді. Олар айнымалының, функцияның, мүшесінің немесе кластың атауын немесе түрін өзгертуді қиындатады. Олар кодты оқуды қиындатады. Олар кодтау жүйесі оқырманды жаңылыстыру мүмкіндігін тудырады. Линус Торвальдс (Systems Hungarian-қа қарсы): Функцияның түрін атауға (мажарша нотация деп аталады) кодтау – мидың зақымдануы. Компилятор түрлерді өзі біледі және оларды тексеруге болады, ал ол бағдарламашыны шатастырады. Стив Макконнелл (Apps Hungarian үшін): Мажар нотациясы енді кеңінен қолданылмаса да, қысқаша, нақты аббревиатураларды стандарттаудың негізгі идеясы әлі де құнды. Стандартталған префикстер сізге компилятор міндетті түрде тексермейтін абстрактілі деректер түрлерін қолданғанда, түрлерді дәл тексеруге мүмкіндік береді. Бьярн Строструп (C++ үшін Systems Hungarian-қа қарсы): Мен «мажар» нотациясын ұсынбаймын. Мен «мажар» (түрдің қысқартылған нұсқасын айнымалының атына енгізу) типсіз тілдерде пайдалы болуы мүмкін, бірақ жалпыға бірдей бағдарламалауды және объектіге бағытталған бағдарламалауды қолдайтын тіл үшін мүлдем қолайсыз деп санаймын, себебі олар екеуі де түрге және аргументтерге негізделген операцияларды таңдауды (тілге немесе орындалу уақытына белгілі) ерекшелендіреді. Бұл жағдайда «объектінің түрін атауларға енгізу» абстракцияны жай ғана қиындатады және азайтады. Джоэл Спольски (Apps Hungarian үшін): Егер сіз Симоньидің мақаласын мұқият оқысаңыз, ол жоғарыдағы мысалдағыдай атаудың бір түрін қолданды, онда біз us дегеніміз – қауіпсіз емес жол, s дегеніміз – қауіпсіз жол. Олар екеуі де жол түрінде. Компилятор сізге көмектеспейді, егер сіз бірін екіншісіне тағайындасаңыз және Intellisense [ақылды кодты толықтыру жүйесі] сізге ештеңе айтпайды. Бірақ олардың мағынасы әртүрлі. Оларды әртүрлі түсіндіру керек және әртүрлі қарау керек, және егер сіз бірін екіншісіне тағайындасаңыз, қандай да бір түрлендіру функциясын шақыру керек немесе орындалу кезінде қате пайда болады. Егер сәттілік болса. Apps Hungarian кодты оқуды, жазуды, түзетуді және күтіп-ұстауды жеңілдетеді, ал ең бастысы, қате кодты қате көрінеді. (Systems Hungarian) Симоньидің ниеті мен тәжірибесін түсінбеушілік болды. Microsoft-тың жобалау нұсқаулары NET кітапханаларындағы элементтерге атаулар таңдағанда әзірлеушілерді Systems Hungarian нотациясын пайдаланудан бас тартуға шақырады, дегенмен бұл Visual Basic 6 және одан бұрынғы Microsoft-тың даму платформаларында кең таралған. Бұл жобалау нұсқаулықтары функциялардың ішіндегі жергілікті айнымалылардың атау ережелері туралы ештеңе айтпайды.

Robert Cecil Martin (against Hungarian notation and all other forms of encoding): nowadays HN and other forms of type encoding are simply impediments. They make it harder to change the name or type of a variable, function, member or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader. Linus Torvalds (against Systems Hungarian): Encoding the type of a function into the name (so called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer. Steve McConnell (for Apps Hungarian): Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check. Bjarne Stroustrup (against Systems Hungarian for C++):No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction. Joel Spolsky (for Apps Hungarian): If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant unsafe string and s meant safe string. They're both of type string. The compiler won't help you if you assign one to the other and Intellisense [an intelligent code completion system] won't tell you bupkis. But they are semantically different. They need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky. There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong (Systems Hungarian) was a subtle but complete misunderstanding of Simonyi’s intention and practice. Microsoft's Design Guidelines discourage developers from using Systems Hungarian notation when they choose names for the elements in NET class libraries, although it was common on prior Microsoft development platforms like Visual Basic 6 and earlier. These Design Guidelines are silent on the naming conventions for local variables inside functions.