A Hungarian notation szerintem...

Címkék

...jó dolog és használom.
8% (50 szavazat)
...jó dolog, de nem használom.
10% (65 szavazat)
...jó dolog, de nem hasznáható, mert mindenki a típust jelöli vele.
5% (33 szavazat)
...nem jó dolog, de használom.
0% (2 szavazat)
...nem jó dolog és nem használom.
22% (139 szavazat)
...nem tudom mi az a Hungarian notation.
55% (356 szavazat)
Összes szavazat: 645

Hozzászólások

De tényleg. Mi az a hungarian notation?
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Ez ahogy van, baromság.
Az angol Wikipedia-cikk leírja, hogy egyrészt kétféle magyar jelölés van, másrészt Simonyi eredetileg a mára Apps Hungariannek nevezett jelölést értette alatta.
http://en.wikipedia.org/wiki/Hungarian_notation
"His proposal was largely concerned with decorating identifier names based upon the semantic information of what they store (in other words, the variable's purpose), consistent with Apps Hungarian."

szerintem java/swing-nél hasznos tudni, hogy most éppen milyen objektumon dolgozik az ember, viszont int/string/float, stb. 'hagyományos' típusoknál nem használom.

Majd most kiderül, hogy hányan készítenek "megfelelő minőségű" és "olvasható" kódot, hányan csak gányolnak és hány embernek köze nincs a dologhoz. xD

Sajnos a "megfelelő minőségű" és "olvasható" kódnak nincs köze a hungarian notation-höz. Minősített rendszerek kódjában mindenféle baromságokat megkövetelnek, de pont a magyar változóelnevezést nem. Pedig sokkal többet javítana a kód minőségén, mint az, hogy csak 1 break lehet egy while loop-ban, vagy hogy nem lehet pointer aritmetikát használni.

Nem érzem hiányát. Eclipse-ben egy mouseover vagy egy billenytűlenyomás, és tudom a változó típusát. Emellett törekszem rá, hogy a változó referencia ne kerüljön túl messzire a definiciótól.

A változó nevében nem a típusát, hanem a célját (felhasználását) kódolod, hogy könnyebben észrevedd, ha hülyeséget csinálnál. pl cRow legyen count of rows (sorok száma) cbFile pedig a File bytejainak száma (count of bytes). Ekkor bármilyen cRow = cbFile + 5; vagy hasonló értékadás gyanús, hiszen egy file bytejainak száma és sorok számának semmi köze egymáshoz. vagy dX legyen X irányú különbség koordinátákban. ekkor dX = x1 + x2; is értelmetlennek látszik egyből, hiszen ez összeg, nem különbség.
Simonyi ezt a fizikából lopta: egy képlet helyességét könnyne lehet ellenőrizni, ha megnézzük, hogy a jobb oldalának és bal oldalának dimenziói (mértékegységekkel együtt) ugyanazok-e vagy nem. Ugyanitt ezt is meg lehet tenni: ha az értékadás bal oldalán byteok száma van, akkor a jobboldali kifejezésben sok keresnivalója nincs például oldalszámnak vagy egy lista hosszának.
Ami a félreértést adta: Simonyi az eredeti írásban typenak nevezte azt a tulajdonságot, amit a névben kéne rövidíteni, pedig nem típusról, hanem felhasználásról, a változó tartalmának jelentéséről van szó. Ezt egy IDE sem fogja neked kitalálni :)

Manapság már nem kell rövidíteni, régen még eléggé korlátos volt az azonosítók hossza, ezért volt szépen pár karakterbe sűrítve a rendeltetés. Ma már szépen ki lehet írni a dolgokat, és ez ugyanúgy Hungarian notation: a változó nevében benne van a felhasználás köre, célja.

Épp ezaz: ha kiírod, hogy countRow = countOfBytesFile + MAGIC_OFFSET; az ugyanúgy Hungarian notation: egységes nevezéktan használata a változó rendeltetésének leírására. Az egy dolog, hogy régen korlátozva volt az azonosítónév, ma pedig nincs. Attól ez még ugyanúgy Hungarian notation. A nem hungarian notaion az lenne, hogy c1 = c2 + 5;.

Ha a nevben benne van a valtozo rendeltetese (nem csak az, hogy nemi ertelme van...), es ez a nevezektan egyseges (azaz countOf es numberOf uti egymast), az bizony Hungarian notation. A Hungarian notation lenyege ugyanis nem a konkret nevezektan (hiszen ez lehet projektfuggo), hanem az, hogy van ilyen nevezektan, amely segitsegevel konnyeden ellenorizhetjuk a valtozok tipusanak es dokumentaciojanak megnezese nelkul, hogy az adott kifejezes ertelmes-e szemantikailag.

Termeszetesen a CamelCase sem feltetel: tartsuk csak be az adott nyelv ajanlasait.

"c1 = c2 + 5;"

Ez konkrétan szar kód, nem csak a hungarian notation hiánya.

A változó elnevezésének célja, hogy a változó rendeltetése látsszon.
Normális ember nem váltogatja a countOf és a numberOf kifejezéseket (azaz egységes is), attól még az nem magyar jelölés. (Mellesleg már a példádban sem sikerült az egységes használat.)

Tudom jó volna abban hinni, hogy mindent a magyarok találtak fel, de a magyar jelölés eléggé specifikusan azt jelenti, hogy egy-egy karaktert dobunk a változónév elejére...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.)"
Ezt Simonyi írta. Tehát szerinted a rowFirst sem magyar jelölés.

Vegyünk azért külön két dolgot:
- Milyen elnevezési szabályokat írt le Simonyi
- Ezek alapján mi került be a köztudatba hungarian notation néven.

Ezek szerint Simonyi bevezetett egy szabályrendszert ami bizonyos esetekben a világ legtermészetesebb dolga (rowFirst), máskor meg kevésbé (cbFile).
Nem ő nevezte el hungarian notationnak, sőt gyanítom nem is szánta forradalmi újításnak.

Ehhez képest amit a világ hungarian notationnak nevez az csak a cbFile és társai.
Tehát szerintem (és ahogy nézem sokak szerint még) a rowFirst nem magyar jelölés.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A megálmodott programnyelvemben minden változónak a tárolási formátum mellett (sőt néha az a kevésbé fontos) meg lehet adni egy dimenziót is.
A fizikában használatos dimenziókkal együtt követett számítások mintájára a fordító compile time ellenőrizné azt, hogy a mennyiségekkel az adott művelet értelmesen elvégezhető-e. Ott már tényleg felesleges lenne ez a notation bohóckodás :-).

+1000

Nem tudom, hogy ez is a magyar jelölés része-e, de hasonlítsuk össze az alábbi kettőt:

float temperature;
int duraiton;

és

float temperature_c;
int duration_ms;

Hoppá, a másodikból kapásból látszik, hogy Celsiusban és millisec-ben tároljuk az információkat. Hány dollármilliárdos költségvetésű űrprojekt meg ilyesmi szállt már el ezen?

Régesrégi álmom egy olyan programnyelv, amelyben a dimenziót nem a változó neve, hanem az értéke képviseli nyelvi szinten, tehát például azt tudod mondani, hogy

temperature = 25 C;
duration = 100 ms;

és valahol definiálni tudod a létező mértékegységeket, például Fahrenheit-Celsius konverziót, illetve különböző típusú mértékegységek közti átjárást (például 1V * 1A = 1W) így a

temperature = 77 F;
duration = 0.1 s;

egyenértékű lenne a fentiekkel, és maga a programnyelv (fordító) vigyázna arra, hogy csak dimenzióhelyes műveleteket engedjen.

Persze, tudom, lehet már most is szépen kódolni... viszont van egy kis különbség aközött, hogy mindig fel kell építened ezt a hókusz-pókuszt (ergó a fejlesztők kis része megteszi, másik része meg marad a rossz kódnál), vagy hogy teljesen alsó szinten, nyelvi elemekkel ösztönzi a nyelv a helyes szemléletre a fejlesztőket, kvázi azt mondva hogy így _kell_ csinálni.

Ez így nem teljesen igaz.

Egy kereskedelmi projektnél, ahol a költséghatékonyság szempont, nem biztos, hogy belefér az, hogy (a példa kedvéért) a C++ nyelvi elemeire alapozva kidolgozol egy új típusrendszert, ami megfelel az Egmont által leírtaknak.

A mérleg egyik serpenyőjében van az, hogy esetleg jobb minőségű lesz az elkészült rendszer. A másik oldalon pedig az, hogy ha mégsem váltja be a hozzáfűzött reményeket ez a kisérleti fejlesztés, akkor akár az egész projekt elbukhat rajta.

Ellenben ha már létezik egy kiforrott megoldás (akár nyelv, akár osztálykönyvtár szintjén), akkor azok is használni tudják, akiknek erre egyébként nem lett volna (gyakorlati okok miatt) lehetőségük.

Szerintem ez egy tipikusan egyetemi (TDK, diplomamunka, doktori) projekt, amit ha open-source elvek mentén fejlesztenek, akkor 1-2 év alatt akár használhatóvá is válna...

Üdv,
Gergely

Akkor van egy jó hírem (mint a jehováknak): a C++ már majdnem tudja ezt anélkül, hogy hatékonyságot veszítenél (az osztályok nem lassabbak, mint bármi más, ha nem bénázol vagy nem kell OOP), az új szabványban meg custom literalok is vannak, szóval nem kell már sokat aludni (hehe, még mindig nem tudjuk, hogy a szabvány jön előbb vagy az euro)...
----
Hülye pelikán

Nekem van egy még jobb hírem, ilyen könyvtár már létezik:
http://www.boost.org/doc/libs/1_45_0/doc/html/boost_units.html

Szeretném ezt küldeni azoknak, akik szerint az operator overloading marhaság, és mindenkinek aki szereti.

(Elsőre bonyolultnak tűnhet, de a leírás nagy része arról szól, hogyan lehet definiálni új dolgokat. Az SI nagy része viszont már benne van out-of-the-box.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"Azt kétlem, hogy a custom literalokat új nyelvi elem nélkül meg lehet oldani :)"

Nem is lehet, de speciel én nem is látom az egetrengető újdonságot abban, hogy azt írhatom, hogy

length=12_meter

ahelyett, hogy

length=12*meter

.

"Márpedig minden más csak részletkérdés, triviális módon lehet definiálni az osztályokat, műveleteket, átváltásokat, nem kell hozzá standardizált keretrendszer."

Persze, de mi a francnak definiáljak ~10 féle műveletet minden lehetséges variációban, ha ezt már más megtette helyettem...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A literálokat azért írtam, mert az volt az alap felvetés. Én speciel szívesebben írok olyat, amit te is írtál, mert nekem abból egyértelműbb, hogy mi a helyzet, míg literáloknál meg kéne nézni, mi is van oda írva.

Azt gyanítom, hogy ez elég általános dolog ahhoz, hogy ilyen egyszerű dologra ágyúval verébre legyen. Sokkal egyszerűbb újra feltalálni a spanyolviaszt, mint megtanulni más spanyolviaszát. Csak akkor van jelentősége, ha valaki mással (külsőssel) kell együtt dolgozni, ilyenkor egy már létező könyvtár használata persze sokmindenben előnyös. De ez szerintem nem egy túl jól általánosítható probléma, egyszerűségénél és sokféleségénél fogva.
----
Hülye pelikán

Kiírhatja, hogy rowPosition, ez már Apps Hungarian. A lényeg, hogy egy IDE nem tudja kiszűrni, hogy rowPosition = countBytes * numFiles (eléggé értelmetlen kifejezés), míg a változónevekből ez kiderül. Az, hogy cBytes és nFiles vagy countBytes és numFiles, az már tökmindegy, csak legyen egységes nevezéktan a "típusra" (rendeltetésre) vonatkozóan.

szerintem szégyen
rengeteg külhoni fejlesztőnek ez jut eszébe elsőnek hazánkról, szép kis országimázs

f30KGer

nem hiába, hogy a fortranhoz lett kitalálva

OOP-ben nincs helye, csak egy rosszemlékű vicc kellene legyen. A vele készült kód olvashatatlan, érthetetlen. Tulajdonképpen lúzerek használták a szar stílusuk gányolására.

Pedig OOP-ben is nagyon hasznos tud lenni. Nem mindig nezi az ember a kodot IDE-bol, es egy qMsgs referenciabol egybol latszik, hogy uzenetek soraval manipulal, akkor is, ha egy iszonyat hosszu sor kellos kozepen dolgozik vele az ember.

A masik, hogy en azt gyulolom, amikor emberek kitalalnak valami harom-negy betus roviditest a valtozonak, es ugyan talald ki mit csinal. Nyilvan, a temp valtozok egy specialis eset (puffer, reszeredmenyek amiket rogton tovabbdolgoznak, etc), de egyebkent borzaszto nehez egy ilyen kodot karbantartani.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Úgy tűnik neked nem egyértelmű, úgyhogy megsúgom. Ha te kiírod a teljes változónevet azzal veszítesz (mondjuk) 10 másodpercet. Utánad viszont mindenki aki a te kódoddal kell dolgozzon ugyancsak veszít 10 másodpercet amíg kibogozza hogy mit is akartál jelölni. Összességében a projekt hatékonyságára megy.
Persze ha ez egy egy emberes projekt, aminek a kódjával soha senki nem fog dolgozni, akkor csak nyugodtan, bánom is én.

1. Senkinek egy szót se a szoftverfejlesztő klubról.
2. Senkinek egy kurva szót se a szoftverfejlesztő klubról.
3. Ha az ügyfél elfogadja vagy elfogy a költségvetés, a szoftverfejlesztésnek vége.
4. A szoftverfejlesztés kétszemélyes (értsd: pair programming (vagy ügyfél és dev, semmi mánáger, tesztelő, arhitekt))
5. Egyszerre egy projetken dolgozunk.
6. IDE és debugger nélkül fejlesztünk.
7. Minden fejlesztés addig tart, ameddig tart (lásd Duke Nukem, Blizzard játékok, MPlayer)
8. Végül: ha ma vagy itt először, kódolnod kell.
----
Hülye pelikán

"...jó dolog, de nem hasznáható, mert mindenki a típust jelöli vele."

pedig nem arra valo

Tyrael

Furcsa, hogy ennyi "nem tudom" válasz jött... Értem én, hogy nem programozó mindenki, de azért az - akár csak nevükben - magyar vonatkozású dolgokat szokták ismerni itt az emberek.

Egyébként a legviccesebb ezen a téren a .NET design guidelines. Ha jól emlékszem, viszonylag korrekt érveket hozott fel, hogy miért nem akarták használni, ellenben, ami miatt a falhoz vágtam volna, ha nem PDF-ben olvasom, az az, ahol leírják, hogy mi az a Hungarian notation.

----------------
Lvl86 Troll

Ahogy mások is említették az Apps Hungarian logikája használható, de manapság már kevéssé szükséges, és eléggé megköti az ember kezét helyenként. (Értem itt azt, hogy egy fix prefix-készletet használni a teljes projektben a változó használatára vonatkozóan elég nehézkes ha a projekt mérete túllép egy határt. Egyszerűen túl sok használati minta lesz, illetve a párbetűs prefixek rettenetesen olvashatatlanok.) Sokkal hasznosabb inkább egy hosszabb változónevet használni, ami leírja a változó tulajdonságait. Pl: sanitizedSQLQuery s_SQLQuery helyett - nem, szerintem ez már nem Apps Hungarian, főleg ha nem ugyanazt a szót használjuk mindenhol, amit a természetes nyelvek abszolút lehetővé tesznek, és néha hasznos mást használni ha ezzel pontosabban le lehet írni a változót.

Azért egy pár dolgot így is használok:
- member változók: 'm_' prefix.
- globális változók: 'g_' prefix. (Természetesen csak nagyon ritkán, igen indokolt esetben. :-) )
- statikus memberek: 's_' prefix.
- enumok: 'e_' prefix.
Ennyi. Így még megkönnyíti a "típus" azonosítást, ennél több már vizuális zaj. Szerintem.

vazeee, akkor azért jelölte így a mezőket akinek a kódját át kellett írnom: c meg n

Egyeb: kontextusfuggoen hasznalom.

Tipikus pelda: van egy hashmaped, ami a params nevre hallgat, es ebbol neked http query parameterlistat kell osszeallitanod. Ez raadasul altalaban ket lepesben zajlik, eloszor letrehozod a kulcs=ertek parok tombjet, majd ezeket osszefuzod &-jelekkel.

Itt reflexbol jelzem, hogy az egyik params_arr a masik meg params_str.

Globalis valtozo reflexbol nagybetu, vagy javascript eseten window.valtozonev, esetleg var global=window az elejere.

member valtozo ele akkor is kiteszem a this-t, ha a nyelvben amugy nem eloiras.

A rowCount es hasonlonal vagy kiirom teljesen, vagy elgondolkozom, a row nem-e rejtett osztaly.

Ide most írtam egy fél oldalas teljesen felháborodott és szapuló kommentet a hungarian notation-tól, aztán gondoltam elolvasom a róla szóló wiki cikket és rájöttem mekkora hülyeségeket akartam posztolni így kitöröltem az egészet.
Jééééééééééé mik vannak...

Na majd én is kitalálok egy új ételt aloe vera-val, pingvin hússal, barbecue-val, pitával és fűszerpaprikával, mellesleg borzalmas íze lesz de majd jól ráerőltetem mindenkire mert épp olyan hatalmi pozícióban leszek, majd __magyar__ __nemzeti__ eledelként fogom árulni a világ minden táján hiszen van benne paprika.

Beleolvasva a szálba, arra szavaztam, hogy nem tudom mi az (a hozzászólások alapján csak tippem van), de igazából nem is érdekel. Vagy egy blőd hülyeség, amire aggattunk egy nevet, de amúgy minden épeszű ember használja (NYÍLVÁN benne van a változó nevében, hogy mire való, aki nem így csinálja az idióta), vagy valami, amit nem értek, mindenesetre szükségét még nem láttam, hogy elnevezzek bármit így.
----
Hülye pelikán

nem biztos, hogy jo dolog minositened valamit, amit sajat bevallasod szerint sem ertesz teljesen.
a hungarian notation korul meg amugy is nagy felreertesek vannak

hungarian notation jol lehet pl. egy olyan helyzetben, ha user inputtal kell dolgoznod, de nem vedheted le egybol, mert nem tudod meg akkor, hogy ez html attributumkent, vagy sql ertekkent, vagy shell argumentumkent fog-e kesobb felhasznalasra kerulni.
ilyenkor szeretned azert jelezni, hogy ezen valtozo erteke nem megbizhato, ezt mondjuk megteheted egy u prefixxel(de akar ki is irhatod hogy unsafe).
ez egy felhasznalasi terulet a sok kozul.
a problema azzal volt, hogy esz nelkul elkezdtek atvenni emberek ezt a jelolesmodot, csak nem tudtak felfogni, hogy a notation-ben olyan informaciot probalunk atadni, ami amugy nem allna egyszeruen rendelkezesre.
az hogy a valtozo milyen tipusu, az elegge egyszeruen kideritheto, raadasul erosen tipusos nyelveknel amugy is ismerned kell a valtozoid tipusat.
az hogy a string tipusu input korabban le lett-e mar escapelve nem ennyire konnyen elerheto informacio.

Tyrael

Nem tudom feltűnt-e, hogy nem igazán minősítettem megát a fogalmat. Annyit mondtam róla, hogy triviális. És hogy minden normális ember magától használja (egy formáját, esetleg céges policyn keresztül szabályozva), anélkül, hogy tudná, ennek van amúgy neve is.
----
Hülye pelikán

Nem tudom feltűnt-e, hogy nem igazán minősítettem megát a fogalmat. Annyit mondtam róla, hogy triviális.

nem ezt mondtad, de ne kelljen mar az elozo hozzaszolasodat idezgessem.

Beleolvasva a szálba, arra szavaztam, hogy nem tudom mi az (a hozzászólások alapján csak tippem van), de igazából nem is érdekel.

ezzel azt allitod, hogy a topic olvasasa elott nem tudtad, a hozzaszolasok elolvasasa utan pedig meg mindig nem vilagos, de nem is erdekel teged.

Vagy egy blőd hülyeség, amire aggattunk egy nevet, de amúgy minden épeszű ember használja (NYÍLVÁN benne van a változó nevében, hogy mire való, aki nem így csinálja az idióta), vagy valami, amit nem értek, mindenesetre szükségét még nem láttam, hogy elnevezzek bármit így.

itt minosited azt, amit a korlatozott ismereteid alapjan belelatsz a kifejezesbe.

És hogy minden normális ember magától használja (egy formáját, esetleg céges policyn keresztül szabályozva), anélkül, hogy tudná, ennek van amúgy neve is.

meg azzal sem ertenek egyet, hogy mindenhol lenne coding standard, ami eloirja a valtozok elnevezeset, de meg ahol van is, ott sem gondolom, hogy mindenhol resze lenne, a valtozok ilyesfajta "tagelese" a prefixen keresztul, amit a hungarian notation jelent.

amit mondasz az kb. olyan mintha arra hogy valaki kulonbozo szinu dossziekba(ahol a szineknek jelentosege van) lefuzve evek szerint szetvalogatva tartja a hivatalos papirjait, es ezt a rendszert mondjuk Foobar osztalyzasnak hivja azt mondanad, hogy:

És hogy minden normális ember magától használja (egy formáját, esetleg céges policyn keresztül szabályozva), anélkül, hogy tudná, ennek van amúgy neve is.

igen, az emberek eleg nagy resze tarolja valahogy a hivatalos iratait, de itt csak rész-egész kapcsolatról van szó, nem egyenlőségről.

Tyrael

Most komolyan megkérdezném, hogy hány éves vagy, és hogy mentél át az irodalom érettségin :(

Blőd hülyeség == triviális, csak csúnyábban megfogalmazva. A hülyeség része az, hogy menedzselik és szakszerű leírást adnak egy ennyire egyszerű dologhoz.

>ESETLEG céges policyn keresztül
Sehol sem állítottam, hogy MINDENHOL szabályozzák, csak hogy az ember saját hozzáállását esetleg kicsit rendszerezi a céges, de itt nem erről volt szó, hanem az ember saját szabályairól.

Természetesen amikor nevet aggattak rá, akkor kellett hozzá sok-sok szabály és irodalmat készíteni, különben nem elég komoly. De az elvet mindenki használja, anélkül, hogy tudná, hogy amúgy erről könyvet írtak és szakértői is vannak, meg Hungarian Notation Managerek.
----
Hülye pelikán

Most komolyan megkérdezném, hogy hány éves vagy, és hogy mentél át az irodalom érettségin :(

ha kifogytunk az ervekbol jon a szemelyeskedes.

Blőd hülyeség == triviális, csak csúnyábban megfogalmazva. A hülyeség része az, hogy menedzselik és szakszerű leírást adnak egy ennyire egyszerű dologhoz.

http://www.kislexikon.hu/blod.html
http://www.idegen-szavak.hu/keres/bl%C5%91d

Blőd hülyeség == triviális, csak csúnyábban megfogalmazva. A hülyeség része az, hogy menedzselik és szakszerű leírást adnak egy ennyire egyszerű dologhoz.

lasd korabbi hozzaszolasomat: a valtozok neve utaljon a valtozo funkciojara jellegu best-practise valoban nagyon elterjedt, de ennek a hungarian notation csak egy specialis esete, kiterjesztese, nem pedig csak egy raakasztott nev.
amikor ezt kitalaltak, akkor meg ennyire sem volt a megfelelo valtozonevadas best-practice mint most, persze neked manapsag mar annak tunik.

Sehol sem állítottam, hogy MINDENHOL szabályozzák, csak hogy az ember saját hozzáállását esetleg kicsit rendszerezi a céges, de itt nem erről volt szó, hanem az ember saját szabályairól.

azt nem, de azt igen, hogy mindenki(minden normalis ember) hasznalja ezt(vagy valamilyen formajat):

És hogy minden normális ember magától használja (egy formáját, esetleg céges policyn keresztül szabályozva), anélkül, hogy tudná, ennek van amúgy neve is.

Természetesen amikor nevet aggattak rá, akkor kellett hozzá sok-sok szabály és irodalmat készíteni, különben nem elég komoly. De az elvet mindenki használja, anélkül, hogy tudná, hogy amúgy erről könyvet írtak és szakértői is vannak, meg Hungarian Notation Managerek.

kerem kapcsolja ki.

ps: nem szeretnem a vitat veled folytatni, nem latom a szikranyi jelet sem annak, hogy megprobalnad ertelmezni az altalam leirtakat, ezaltal 0 az eselye hogy meggyozzuk egymast.

Tyrael

" A hülyeség része az, hogy menedzselik és szakszerű leírást adnak egy ennyire egyszerű dologhoz."
Egy projekten belul menedzselik a kodolasi stilust is, pedig trivialis a dolog. Vagy menedzselik az osztalyok nevezektanat.
(hint: a hungarian notationnek akkor van nagyon nagy ertelme, ha meg akarod erteni mas kodjat, vagy hibat keresel benne)

Olyan, mint a kommunizmus.
Elméletben jó, viszont az implementációja sok életet tett tönkre...

Communism is a sociopolitical movement that aims for a classless and stateless society structured upon common ownership of the means of production, free access to articles of consumption, and the end of wage labour and private property in the means of production and real estate.[1]

Ez elég jól hangzik.

Alapvető emberi természetnek mond ellent. Tehát nem hangzik jól.

he?
akkor a vilagbeke is hangzik jol, csak mert az emberek nagy szazaleka idonkent agressziv?

a kozosseg erdeket minden tarsadalom az egyen erdeke fole helyezi, a kulonbseg csak abban van, hogy hol helyezi el az egyen jogait a totalis partallam es a teljes onmegvalositas kozott.

Tyrael

És mivel az ember nem hangya, ezért a kommunista elhelyezés nem megfelelő -> ellentmond az emberi természetnek. Egyéb kérdés?

nagyszeruen rajottel arra, amit mar korabban mind en mind Quain leirtunk:

de nem errol beszeltunk most, hanem arrol a kijelentesedrol, hogy amiert valami nem megvalosithato a gyakorlatban(kommunizmus, vilagbeke, orokelet, szarbol varat, etc.), az azt is jelenti, hogy maga az otlet(mint vagy) nem "jo".

ez az, amivel vitatkoztam.

ps: itt is kiszalltam a vitabol.

Tyrael

mindenki csak a szuksegleteinek megfelelo mertekben vesz ki a kozos kalapbol, es mindenki a legjobb tudasa szerint reszt vesz a munkaban.
a jelenlegi tarsadalmi problemak jo resze a javak egyenlotlen elosztasabol fakad, valamint rengeteg ember nem tudja kihasznalni a benne rejlo potencialt.

sajnos a gyakorlatban azert nem mukodik/mukodott, mert az emberek nem egyformak, nem akar mindenki egyenlokent dolgozni, illetve nem elegszik meg a szuksegleteinek kielegitesevel (vagy eppen teljesen mast ert a szukseges elegseges alatt)
ez szinten feszultsegeket szul(t)

szerintem.

Tyrael

Bár nem tudtam erről (pirul), de valam hasonló dolgot kitaláltam mgamnak, matematikánál gyakran jól jön, a millió változó, komplex....., amit ha a feladat úgy kívánja használom. pl: holo_c_8192 hola a név, c nekem a komplex. a szám pedig a max méret

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Nem hiszek benne. Ha olyan kódba kell dolgozni, amibe használva van akkor használom, egyébként bukó.

--
GPLv3-as hozzászólás.