Prznenie C++ Microsoftom - Hungarian notation

[Ink]

Také záleží na dalších okolnostech. Ve funkci, která má pár řádků a krátkou životnost je to jiné, než u proměnných, které mají dlouhou životnost a objevují se na různých místech programu. Rozlišování datových typů se hodí hlavně tam, kde pracuji se stejným obsahem, ale s různými datovými typy. Jr to potřeba brát s rozumem, používat to tam, kde to má přínos. Ale chápu potřebu molocha, jako je microsoft, že se snaží mít jednotné api napříč projektem, na kterém pracují stovky lidí. Tam je třeba disciplinovanost, byť je občas ne zcela smyslná. Kdo si vzpomíná na rané verze php, ten ví, tam to byl pěkný kočkopes, jak v názvech, tak třeba v pořadí parametrů. A výsledkem byla zbytečně vyšší chybovost.

Ano, jelikož, jak jsi sám přiznal, všechno prasíš do jednoho dlouhého souboru, proměnné mají dlouhou životnost a (objevují se?) na různých místech programu, potřebuješ tyhle obezličky. Asi by stálo za to se zamyslet a namísto maďarské notace přestat prasit. Kromě jiného by mohlo pomoci i v tom Vimu používat pluginy, které drží kontext - co třeba na Rootu nedávno recenzované Kite, Kite?

[Reklama]

[Jiří Havel]

windows.h je hnusný smrdutý výhonek pekla. A ta maďarská notace je ještě ta lepší část. Chápu historické důvody, které to způsobily, ale stejně to jen na zlost.

Proč se mi sakra moje metoda neslinkuje? Aha, protože se jmenuje "CreateFile" a někde se mi tam dostalo windows.h.
Proč mi sakra překladač vyhazuje takovou nesrozumitelnou chybu? Aha, já pojmenoval proměnnou "far" a někde se mi tam dostalo windows.h.

windows.h je dobré mít nepropustně zabalené a oddělené od zbytku kódu. A při údržbě doporučuju gumové rukavice a dvoumetrové bidlo.
A pokud to nejde, tak neincludovat windows.h přímo, ale přes vlastní header který #undefne všechny ty pasti.

[qelurg]

Také záleží na dalších okolnostech. Ve funkci, která má pár řádků a krátkou životnost je to jiné, než u proměnných, které mají dlouhou životnost a objevují se na různých místech programu. Rozlišování datových typů se hodí hlavně tam, kde pracuji se stejným obsahem, ale s různými datovými typy. Jr to potřeba brát s rozumem, používat to tam, kde to má přínos. Ale chápu potřebu molocha, jako je microsoft, že se snaží mít jednotné api napříč projektem, na kterém pracují stovky lidí. Tam je třeba disciplinovanost, byť je občas ne zcela smyslná. Kdo si vzpomíná na rané verze php, ten ví, tam to byl pěkný kočkopes, jak v názvech, tak třeba v pořadí parametrů. A výsledkem byla zbytečně vyšší chybovost.

Ano, jelikož, jak jsi sám přiznal, všechno prasíš do jednoho dlouhého souboru, proměnné mají dlouhou životnost a (objevují se?) na různých místech programu, potřebuješ tyhle obezličky. Asi by stálo za to se zamyslet a namísto maďarské notace přestat prasit. Kromě jiného by mohlo pomoci i v tom Vimu používat pluginy, které drží kontext - co třeba na Rootu nedávno recenzované Kite, Kite?

Tohle prasení dělám jen u svých soukromých projektů a životnost proměnné přece nesouvisí s tím, jestli mám 50 tříd napsaný v jednom nebo v 50 souborech. Jestli si myslíš, že jsem nějaký Kit, tak jsi vedle. Dobře nazvaná proměnná není obezlička, to je základ dobrého programování. Dobrý název je samopopisný a nahradí ti půlku dokumentace. Někdy je těžké na něj přijít. Lidem kterým opravuji kódy se mnohdy rozsvítí jen tím, že jim ty proměnné přejmenuji.

[Ink]

Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.

[qelurg]

Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.

Tak protoze ja v Pythonu  cpu do jedne promenne ruzne typy, tak to nerozlisuju

Kód [Vybrat] Rozbalit


cislo = '1'
cislo = int(cislo)


Ale kdybych potreboval z nejakeho duvodu pracovat s obema formami soucasne, tak si je pravdepodobne rozlisim na iCislo a na sCislo.

[Reklama]

[Jiří Havel]

Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.

Já bych tady přidal, že ten datový typ by měl co nejvíc vypovídat o tom obsahu. Pokud můžu různé věci reprezentovat různými typy, tak je to jen dobře. Nejde to samozřejmě vždycky, ale věci co mi hlídá překladač si nemusím hlídat já.

Nechat předpony pro věci, co překladač neohlídá, mi přijde hodně rozumné.

Tak protoze ja v Pythonu  cpu do jedne promenne ruzne typy, tak to nerozlisuju

Kód [Vybrat] Rozbalit


cislo = '1'
cislo = int(cislo)


No tak tahle recyklace mi přijde jako zbytečný dodatečný nápor na hlavu. A to nejenom int+string ale třeba i recyklovat jednu proměnnou pro několik logicky různých intů. Už mi pro přemýšlení o obsahu nestačí jméno, ale musím tam zahrnout i místo.

Nevím jak v pythonu, ale moderní optimalizující překladače zlikvidují jakoukoliv takovouhle recyklaci jako jednu z prvních věcí, protože v SSA formě dostane každé přiřazení svou unikátní proměnnou.

[qelurg]

Kód [Vybrat] Rozbalit


cislo = '1'
cislo = int(cislo)


No tak tahle recyklace mi přijde jako zbytečný dodatečný nápor na hlavu. A to nejenom int+string ale třeba i recyklovat jednu proměnnou pro několik logicky různých intů. Už mi pro přemýšlení o obsahu nestačí jméno, ale musím tam zahrnout i místo.

Nevím jak v pythonu, ale moderní optimalizující překladače zlikvidují jakoukoliv takovouhle recyklaci jako jednu z prvních věcí, protože v SSA formě dostane každé přiřazení svou unikátní proměnnou.
[/quote]

Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.

[Jiří Havel]

Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.

Ale ona to úplně stejná data nejsou. V podobě intu to má výrazně menší stavový prostor než ve formě stringu.

Pokud je to string na vstupu, pak je ten stavový prostor větší o nejrůznější chybný nebo útočný binec. Pokud ten rozdíl odignoruju, mám bezpečnostní díru.
Pokud je to string na výstupu, pak je ten stavový prostor větší o to, jak ten int chci vypsat. U intu těch možností moc není, ale u jiných typů ten stavový prostor bobtná dost zásadně.

Kdyby opravdu nezáleželo na datovém typu, tak to může zůstat jako int (nebo string). Ale ono je to z nějakého důvodu nutné převést. A ten důvod z té abstrakce prosakuje ven (leaky abstraction). Typ (ve formě množiny hodnot, které můžu čekat) tam stále je.

[Jiří Havel]

A ještě jedna věc. Ta moje připomínka vlastně není primárně o typech. Proto jsem tam psal o těch různých intech. Proměnná není primárně ukazatel. To už je implementační detail. Primární je lidsky čitelné jméno. A díky té recyklaci už ze jména není vidět rozdíl mezi stavy před a po. A ten rozdíl důležitý je, jinak bys tu transformaci nedělal.

[rrrado1]

Kód [Vybrat] Rozbalit


typedef int INT;
typedef LONG HRESULT;


Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.

Ten INT takto vytrhnutý z kontextu nemá zmysel, ani ho dnes nik nepoužíva okrem starých API. Tie názvy majú svoj význam, len si treba pozrieť aj aké iné typy sú takto definované a uvedomiť si kedy vznikli (možno 40 rokov dozadu). Napr. LPWORD sa predsa len lepšie píše ako (unsigned short * far). Nie len že ešte neexistovali IDE ako dnes, ale bolo to v časoch 16 bit architektúry keď pointre mohli byť far (segment+adresa) a near (adresa 16 bit). Tiež sa už myslelo na prechod na 32 bit a napr. typy ako WPARAM a pod. boli závislé od toho, či sa kompilovala 16 alebo 32 bit aplikácia. Navyše každý kompiler mohol mať rôzne veľkosti typov int, short, atď (ešte neexistovali typy ako int32_t).

HRESULT je zas typ pre štandardné chybové kódy, náhodou o veľkosti LONG. Keď vidím, že funkcia vracia HRESULT, tak hneď viem ktoré bity čo znamenajú a ktorými makrami môžem ten výsledok spracovať. Keby funkcia vracala int, tak to nenesie žiadnu informáciu ako s výsledkom pracovať a treba hľadať v dokumentácii či to je nejaký kód chyby, alebo počet, alebo niečo iné.

[qelurg]

Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.

Ale ona to úplně stejná data nejsou. V podobě intu to má výrazně menší stavový prostor než ve formě stringu.

Pokud je to string na vstupu, pak je ten stavový prostor větší o nejrůznější chybný nebo útočný binec. Pokud ten rozdíl odignoruju, mám bezpečnostní díru.
Pokud je to string na výstupu, pak je ten stavový prostor větší o to, jak ten int chci vypsat. U intu těch možností moc není, ale u jiných typů ten stavový prostor bobtná dost zásadně.

Kdyby opravdu nezáleželo na datovém typu, tak to může zůstat jako int (nebo string). Ale ono je to z nějakého důvodu nutné převést. A ten důvod z té abstrakce prosakuje ven (leaky abstraction). Typ (ve formě množiny hodnot, které můžu čekat) tam stále je.

Technicky, z pohledu ulozeni v pameti, stejné nejsou. Vyznamove, po zanedbani zpusobu ulozeni v pameti, ale jsou. Proto jsem psal, at se to pokusis vnimat jako vyssi abstrakci. Jak jsem psal, v uvedenem pripade to, jako programator, nepotrebuji rozlisovat, proto to nerozlisuji. Kdybych to potreboval rozlisit, tak prave a jen z duvodu jinych typu a pak pouziju zminenou madarskou notaci.

V jazycích jako PHP to prevadet nepotrebujes, tam se to prevadi implicitne podle potreby. V pythonu to prevest potrebujes, ale ne vzdy to potrebujes rozlisovat na urovni promenych a mit pro kazdy typ jinou.

[qelurg]

A ještě jedna věc. Ta moje připomínka vlastně není primárně o typech. Proto jsem tam psal o těch různých intech. Proměnná není primárně ukazatel. To už je implementační detail. Primární je lidsky čitelné jméno. A díky té recyklaci už ze jména není vidět rozdíl mezi stavy před a po. A ten rozdíl důležitý je, jinak bys tu transformaci nedělal.

V pythonu je promenna vzdycky ukazatel. Je to pojmenovany odkaz do pameti na prislusny datovy objekt. Ne, neni pro me dulezity a davam to najevo tim pojmenovanim. Je to jako pouzivani pomocne promenne tmp ve statickem jazyku, kde nemas potrebu ji nejak specificky pojmenovat, akorat tam musis respektovat datovy typ, v dynamickem jazyku to je jednodussi. Duvody ktere uvadis jsou formalni, byrokraticke, pragmaticky vzato ale v uvedenem pripade zcela zbytecne.

[qelurg]

Kód [Vybrat] Rozbalit


typedef int INT;
typedef LONG HRESULT;


Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.

Ten INT takto vytrhnutý z kontextu nemá zmysel, ani ho dnes nik nepoužíva okrem starých API. Tie názvy majú svoj význam, len si treba pozrieť aj aké iné typy sú takto definované a uvedomiť si kedy vznikli (možno 40 rokov dozadu). Napr. LPWORD sa predsa len lepšie píše ako (unsigned short * far). Nie len že ešte neexistovali IDE ako dnes, ale bolo to v časoch 16 bit architektúry keď pointre mohli byť far (segment+adresa) a near (adresa 16 bit). Tiež sa už myslelo na prechod na 32 bit a napr. typy ako WPARAM a pod. boli závislé od toho, či sa kompilovala 16 alebo 32 bit aplikácia. Navyše každý kompiler mohol mať rôzne veľkosti typov int, short, atď (ešte neexistovali typy ako int32_t).

HRESULT je zas typ pre štandardné chybové kódy, náhodou o veľkosti LONG. Keď vidím, že funkcia vracia HRESULT, tak hneď viem ktoré bity čo znamenajú a ktorými makrami môžem ten výsledok spracovať. Keby funkcia vracala int, tak to nenesie žiadnu informáciu ako s výsledkom pracovať a treba hľadať v dokumentácii či to je nejaký kód chyby, alebo počet, alebo niečo iné.

Presne, typedef se v C pouziva kvuli snadnym zmenam architektury a kvuli semantickemu rozliseni datovych typu.