[PHP] Variable namen

[Tha Ertenal]

Als ik soms programeerwerk van iemand anders bekijk kom ik wel eens variabelen als $iMemberId of $sMemberName tegen. Ik heb me echt altijd al afgevraagd waarvoor die eerste i of s nou wordt gebruikt. Eerst dacht ik misschien om aan te geven dat een bepaalde variable een int (i) of een string (s) was, maar dat werd ook door elkaar gehutst dus kon het dat niet zijn. Wat houdt deze speciale variable naam nou eigenlijk in?

ik heb geprobeerd te zoeken op google, maar ik zou serieus niet weten wat ik daar zou moeten in tikken. Met 'variable name' en allerlei varianten kwam ik er helaas niet..

[Matis]

Zoiets bedoel je?

Wikipedia: CamelCase

[fiftyhillswest]

Is dat niet de Hungarian Notation? Wikipedia: Hungarian notation

Die s en i die zouden dan staan voor het datatype dat die variabele bevat, in dit geval respectievelijk string en integer

[ Voor 76% gewijzigd door fiftyhillswest op 16-03-2010 21:31 ]

[Voutloos]

Wikipedia: Hungarian notation

En als het niet consistent gebruikt wordt (of consistent niet ) is men slordig of heb je iemand in je team die het niet kent en voor de lol alles met s begint omdat hij dat ooit gezien heeft.

[Avalaxy]

Bij mijn weten heeft het geen enkel nut. Misschien is het wel een Apple fan als hij alles met een i begint?

[Tha Ertenal]

Tja, dat klinkt wel logisch. De meeste kloppen ook wel maar aangezien sommige variablen in het voorbeeld wat ik hier voor me heb net niet kloppen dacht ik dus iets anders.. Mooi, vanaf nu voortaan ook zo programmeren. Erg makkelijk lezen zo!

[fiftyhillswest]

Ik kan het je daarentegen afraden. Probeer van deze

code:

a_crszkvc30LastNameCol

maar eens het type te raden, en nee niet spieken op wikipedia!

Bovendien haal je zo een beetje de features van de IDE onderuit. Die hoort maar bij te houden waar je mee bezig bent, niet jijzelf.

[Haan]

Mooi, vanaf nu voortaan ook zo programmeren. Erg makkelijk lezen zo!

Wees wel gewaarschuwd dat de mening daarover nogal verdeeld zijn in voor- en tegenstanders.
Als je bijv. met een strongly-typed taal als Java of C++, C# zou werken, wordt hungarian notatie afgeraden. Ik ben er zelf ook geen fan van eerlijk gezegd.

[Matis]

Haan schreef op dinsdag 16 maart 2010 @ 21:37:
Wees wel gewaarschuwd dat de mening daarover nogal verdeeld zijn in voor- en tegenstanders.
Als je bijv. met een strongly-typed taal als Java of C++, C# zou werken, wordt hungarian notatie afgeraden. Ik ben er zelf ook geen fan van eerlijk gezegd.

Mij hebben ze idd aangeraden om met C# de CamelCase te gebruiken, vooral omdat het met Auto-Completion erg eenvoudig werkt.

nvmd

[krvabo]

Haan schreef op dinsdag 16 maart 2010 @ 21:37:
[...]

Wees wel gewaarschuwd dat de mening daarover nogal verdeeld zijn in voor- en tegenstanders.
Als je bijv. met een strongly-typed taal als Java of C++, C# zou werken, wordt hungarian notatie afgeraden. Ik ben er zelf ook geen fan van eerlijk gezegd.

Daar heb je een punt, maar in php is het goddankendopjeknietjes-handig als je door iemand anders' code loopt.
Als je het consequent gebruikt dan is het is loose-typed talen zeker een pluspunt.

i - int
s - string
a - array
b - boolean
o - object
f - float
d - decimal
u - unknown (nja dat hoor je dus eigenlijk niet te gebruiken )
m - multiple (bijvoorbeeld int(number of rows) of 'false')
n - afhankelijk van de programmeur, vaak number..

Je kunt gewoon heel snel zien of je een foreach kunt gebruiken

[ Voor 21% gewijzigd door krvabo op 16-03-2010 22:11 ]

[pieturp]

Hungarian notatie is echt een no-no voor mij. In een strongly typed taal moet je toch al alles vooraf beslissen, en weet je dus al wat het type is.
In een dynamische taal, weet je maar nooit of hetgeen je eerst had bepaald later echt nog wel klopt:

JavaScript:

var nGetal = 10; // n suggereeert een number...
nGetal += ',3';
alert(typeof nGetal); // ...maar is nu een string

Nou is dat wel een beetje een suf voorbeeld, maar een foutje is zo gemaakt en juist door dan Hungarian notation te gebruiken raak je zo gemakkelijk, als je niet de oorspronkelijke programmeur bent, op een verkeerd been.

[pedorus]

krvabo schreef op dinsdag 16 maart 2010 @ 21:44:
Je kunt gewoon heel snel zien of je een foreach kunt gebruiken

Door te kijken of de naam meervoud is. Ik mis trouwens klassen in je schema. Maar evengoed:

quote: http://mindprod.com/jgloss/unmainnaming.html

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack.

Het beste is natuurlijk dat je opeens namen moet wijzigen als het type wijzigt; hoewel dat vergeet je natuurlijk gewoon... En in php is het natuurlijk ook de vraag of er expliciet gecast is, of niet.

[krvabo]

pedorus schreef op dinsdag 16 maart 2010 @ 21:56:
[...]

Door te kijken of de naam meervoud is. Ik mis trouwens klassen in je schema. Maar evengoed:

Dus volgens jou kun je een foreach gebruiken op $iNumberOfFields ? (Niet dat dit een geweldige varnaam is, maar je snapt mijn punt )
Als ik ergens $aBooks (Jup, meervoud inderdaad) zie staan dan weet ik al meteen dat ik daar simpel doorheen kan loopen:

PHP:

foreach ($aBooks as $oBook) {

Waarbij $oBook dan een object is waar ik dan weer met functies tegenaan kan praten.

Zou ik echter $books gebruiken, dan kan het ook makkelijk dit zijn:

PHP:

$books = count($bookarray);

of zelfs:

PHP:

$books = true; // books are available on the plane

[...]

Het beste is natuurlijk dat je opeens namen moet wijzigen als het type wijzigt; hoewel dat vergeet je natuurlijk gewoon... En in php is het natuurlijk ook de vraag of er expliciet gecast is, of niet.

Ik vergeet dat echter nooit? Misschien een kwestie van gewenning, maar als je een datatype moet veranderen dan heb je imho eerst niet goed nagedacht wat je precies wil. Mocht het nou echt blijken dat na het toevoegen van functionaliteit iets wijzigt dan is een Refactor > Rename snel genoeg gedaan. Sowieso moet je dan alsnog je code doorlopen om te kijken of er geen andere fouten kunnen optreden door die wijziging (foreach op een bool gooien bijvoorbeeld). Je ziet dan vanzelf dat je datatype fout is.

Ook al cast je de variabele niet expliciet, dan is het alsnog handig en scheelt het echt programmeertijd. Ik meen het serieus dat ik de code veel overzichtelijker vind, en als ik code tegenkom zonder deze notatie (ook van mezelf!) dan is het veel moeilijker om te lezen.

[pedorus]

krvabo schreef op dinsdag 16 maart 2010 @ 22:09:
Ook al cast je de variabele niet expliciet, dan is het alsnog handig en scheelt het echt programmeertijd. Ik meen het serieus dat ik de code veel overzichtelijker vind, en als ik code tegenkom zonder deze notatie (ook van mezelf!) dan is het veel moeilijker om te lezen.

In welke gevallen scheelt het dan precies programmeertijd? Verder: is het bijvoorbeeld zo raar om een willekeurige Traversable (met t als prefix ofzo?) terug te krijgen ipv een Array (a)? En ga je dan alles af mocht zoiets wijzigen? Zonder prefix hoeft dat niet.

Verder is het gebruik van Hungarian niet een standaard php coding convention, dus zal een ander eerst een tijd moeten wennen. Hit 2 raadt het zelfs expliciet af:

quote: http://www.evolt.org/node/60247

A lot of textbooks (particulary those about Visual C++) will try to drum hungarian notation into your head. Basically, this means having rules such as pre-pending g_ to global variables, i to integer data types etc. Not only is a lot of this irrelevant to PHP (being a typeless language), it also produces variable names such as g_iPersonAge which, to be honest, are not easy to read at a glance and often end up looking like a group of random characters strung together without rhyme or reason.

[TheBorg]

Ik heb heel lang de Hungarian notation gebruikt, maar later ben ik overgestapt op de Zend Coding Guidelines, omdat ik steed meer met het Zend Framework te maken kreeg. De Zend guidelines zijn ook veel breder gedocumenteerd (namen voor functies, classes, etc.) en daardoor een veel betere houvast.

Ik vind het weak-typing in PHP een grote frustratie, maar achteraf mis ik de i-tjes en a-tjes van de Hungarian notation helemaal niet.

[Cyphax]

krvabo schreef op dinsdag 16 maart 2010 @ 21:44:
i - int
s - string
a - array
b - boolean
o - object
f - float
d - decimal
u - unknown (nja dat hoor je dus eigenlijk niet te gebruiken )
m - multiple (bijvoorbeeld int(number of rows) of 'false')
n - afhankelijk van de programmeur, vaak number..

Je kunt gewoon heel snel zien of je een foreach kunt gebruiken

Met Apps Hungarian Notation kan ik wel leven, dat heeft nog nut maar dat lelijke vieze Systems Hungarian Notation. Ik kan veel hebben, maar van iWatmaaktmijdenaamvandevariabelenoguitalsikergewooneenivoorzetweetjehettypeookalhebjegeenenkelegarantiedathetoverdrieregelsnogsteedsdattypeis word ik altijd een beetje verdrietig...

Ik zie meer heil in prefixes die wat meer informatie geven over welk soort variabele, maar niet het type. Joel Spolsky had er een leuk artikel over.

[Raynman]

krvabo schreef op dinsdag 16 maart 2010 @ 22:09:
[...]

Dus volgens jou kun je een foreach gebruiken op $iNumberOfFields ? (Niet dat dit een geweldige varnaam is, maar je snapt mijn punt )

'number' is enkelvoud, dus nee.

Als ik ergens $aBooks (Jup, meervoud inderdaad) zie staan dan weet ik al meteen dat ik daar simpel doorheen kan loopen:

PHP:

foreach ($aBooks as $oBook) {

Waarbij $oBook dan een object is waar ik dan weer met functies tegenaan kan praten.

Zou ik echter $books gebruiken, dan kan het ook makkelijk dit zijn:

PHP:

$books = count($bookarray);

of zelfs:

PHP:

$books = true; // books are available on the plane

Dat zijn ook gewoon niet echt duidelijke namen. Met een i of b ervoor kun je misschien iets beter gokken wat het is, maar in plaats daarvan kun je ook een beetje informatie toevoegen die net wat duidelijk maakt wat de functie is, bijv. $numBooks (of onafgekort als je wilt) of $booksAvailable. Bij die laatste zou je met 'are' kunnen prefixen (soort conventie: 'is' of 'has' voor booleaanse waarden/functies, hier met meervoud 'books').

[pieturp]

krvabo schreef op dinsdag 16 maart 2010 @ 22:09:
[...]

PHP:

$books = count($bookarray);

Bedoelde je misschien

PHP:

$iBooks = count($aBooks);

[MueR]

Hungarian notation wordt bij ons op het werk niet gewaardeerd in ieder geval. Of om het dichter bij de waarheid te zoeken, curry684 of ik laat je code opnieuw typen als je HN gebruikt

Ik vind het absoluut nutteloos om hungarian notation te gebruiken omdat, nog afgezien van het loose typed gebeuren, je normaal gesproken aan code vrij duidelijk kan zien of iets nu een int, bool of string bevat. Ik heb liever een variabelenaam die beschrijft wat er in zit dan die het type beschrijft.

[krvabo]

pedorus schreef op dinsdag 16 maart 2010 @ 22:46:
[...]

In welke gevallen scheelt het dan precies programmeertijd? Verder: is het bijvoorbeeld zo raar om een willekeurige Traversable (met t als prefix ofzo?) terug te krijgen ipv een Array (a)? En ga je dan alles af mocht zoiets wijzigen? Zonder prefix hoeft dat niet.

Verder is het gebruik van Hungarian niet een standaard php coding convention, dus zal een ander eerst een tijd moeten wennen. Hit 2 raadt het zelfs expliciet af:
[...]

Als ik in een stuk code een $aBla zie, dan weet ik dat het een array is (als je gewoon consequent die naamgeving gebruikt!) dus dan kan ik count(), foreach(), array_diff() en wat dan nog meer gebruiken, zonder eerst te moeten kijken of de functie die mij die array geeft ook een NULL terug kan geven. Ik hoef dus niet in andere code te kijken naar wat wordt teruggegeven.
Met een string weet ik dat ik een string heb, en geen int, handig bij queries schrijven.

Cyphax schreef op dinsdag 16 maart 2010 @ 23:41:
[...]



Met Apps Hungarian Notation kan ik wel leven, dat heeft nog nut maar dat lelijke vieze Systems Hungarian Notation. Ik kan veel hebben, maar van iWatmaaktmijden[..]ettypeookalhebjegeenenkelegarantiedathetoverdrieregelsnogsteedsdattypeis word ik altijd een beetje verdrietig...

Als je geen garantie hebt dat het nogsteeds hetzelfde type is dan gebruik je het fout. punt.

Raynman schreef op dinsdag 16 maart 2010 @ 23:50:

[...]

Dat zijn ook gewoon niet echt duidelijke namen. Met een i of b ervoor kun je misschien iets beter gokken wat het is, maar in plaats daarvan kun je ook een beetje informatie toevoegen die net wat duidelijk maakt wat de functie is, bijv. $numBooks (of onafgekort als je wilt) of $booksAvailable. Bij die laatste zou je met 'are' kunnen prefixen (soort conventie: 'is' of 'has' voor booleaanse waarden/functies, hier met meervoud 'books').

Ik zeg ook niet dat je niet alsnog fatsoenlijke variabelenamen moet gebruiken, maar er zijn genoeg mensen die echt BRAKKE namen verzinnen. Als je dan gewoon aangeeft welk type het is, scheelt het me iig koppijn.
Ook brakke dingen als $tmp ... met een type $iTmp of $aTmp weet ik in ieder geval nog wat ik er mee moet.

MueR schreef op woensdag 17 maart 2010 @ 00:46:
Hungarian notation wordt bij ons op het werk niet gewaardeerd in ieder geval. Of om het dichter bij de waarheid te zoeken, curry684 of ik laat je code opnieuw typen als je HN gebruikt

Ik vind het absoluut nutteloos om hungarian notation te gebruiken omdat, nog afgezien van het loose typed gebeuren, je normaal gesproken aan code vrij duidelijk kan zien of iets nu een int, bool of string bevat. Ik heb liever een variabelenaam die beschrijft wat er in zit dan die het type beschrijft.

Maar goed dat ik niet bij jullie werk dan

Je zegt dat je aan code snel kunt zien welk type.. totdat je een keer een functie aanroept die een int terug zou moeten geven.. maar wellicht geeft ie wel false ergens (0) of true (1). Snel weten wat je dan kan verwachten is zeer handig.

En natuurlijk moet je alsnog fatsoenlijke varnamen gebruiken, maar het één is niet exclusief.
$iChairsAvailable is imho handiger dan $numberAvailableChairs..

[Peter]

Ik gebruik zelf ook veel hungarian notation, met name omdat ik het gewoon duidelijker vind. Je kunt direct zien welk type een variable heeft. Wel is het zo dat het valt of staat met goed, consequent gebruik. Even een uitzondering maken is in mijn ogen dan ook een no-go..

Met typed languages gebruik ik het overigens minder, vaak zelfs niet, omdat het dan geforceerd wordt. Gezien er in PHP 5.4 *waarschijnlijk* ook scalar-types als hints gebruikt kunnen worden wordt dat een goed moment om te heroverwegen of ik het in PHP ga gebruiken, maar ook in bijv. Javascript en LUA vind ik het duidelijker.

[Cyphax]

krvabo schreef op woensdag 17 maart 2010 @ 07:19:

Als je geen garantie hebt dat het nogsteeds hetzelfde type is dan gebruik je het fout. punt.

Dat is mijn punt ook; je bent overgeleverd aan de fratsen van een ander die die notatie gebruikt icm een weakly typed taal als PHP of Javascript. Mijn eigen variabelenamen zijn van zichzelf beschrijvend. Wel langer dan met gebruik van hongaarse notatie, maar dat neem ik op de koop toe, het is leesbaarder.

[Janoz]

krvabo schreef op woensdag 17 maart 2010 @ 07:19:
Als ik in een stuk code een $aBla zie, dan weet ik dat het een array is (als je gewoon consequent die naamgeving gebruikt!) dus dan kan ik count(), foreach(), array_diff() en wat dan nog meer gebruiken, zonder eerst te moeten kijken of de functie die mij die array geeft ook een NULL terug kan geven. Ik hoef dus niet in andere code te kijken naar wat wordt teruggegeven.
Met een string weet ik dat ik een string heb, en geen int, handig bij queries schrijven.

Als je niet kunt zien of een variabele een array is of niet dan is het waarschijnlijker 1 van de volgende punten:
1 - Je hebt een brakke naam
2 - De scope van je variabelen is te groot
3 - Je methoden/functies zijn te lang

Als je geen garantie hebt dat het nogsteeds hetzelfde type is dan gebruik je het fout. punt.

imho geen argument. Een codingstyle moet automatisch goed werken. Ten eerste geeft de noodzaak van HN al aan dat er waarschijnlijk een matige IDE ondersteuning is waardoor refactoring zeer waarschijnlijk ook niet beschikbaar is. Dit maakt het vervolgens een hels karwij om eens een type aanpassing door te voeren. HN vereist actief onderhoud waarbij de gebruiker druk na moet denken. Ik snap dan ook niet waar het idee weg komt dat het de programmeur juist werk uit handen neemt.

Ik zeg ook niet dat je niet alsnog fatsoenlijke variabelenamen moet gebruiken, maar er zijn genoeg mensen die echt BRAKKE namen verzinnen. Als je dan gewoon aangeeft welk type het is, scheelt het me iig koppijn.
Ook brakke dingen als $tmp ... met een type $iTmp of $aTmp weet ik in ieder geval nog wat ik er mee moet.

Maar mensen die geen fatsoenlijke namen weten te verzinnen zullen vast wel gedisciplineerd genoeg zijn om overal handmatig de HN up to date te houden?

Maar goed dat ik niet bij jullie werk dan

The feeling is mutual

Je zegt dat je aan code snel kunt zien welk type.. totdat je een keer een functie aanroept die een int terug zou moeten geven.. maar wellicht geeft ie wel false ergens (0) of true (1). Snel weten wat je dan kan verwachten is zeer handig.

Het lijkt me handiger om bij de documentatie van de functie op te geven wat deze verwacht en terug geeft. In het stuk commentaar kun je meer kwijt dan in 1 teken in je variabele naam. Ik neem aan dat ze zelfs voor php wel een javadoc achtige notatie hebben?

En natuurlijk moet je alsnog fatsoenlijke varnamen gebruiken, maar het één is niet exclusief.
$iChairsAvailable is imho handiger dan $numberAvailableChairs..

Ik zou zelfs eerder amountOfAvailableChars gebruiken.

[krvabo]

Janoz schreef op woensdag 17 maart 2010 @ 09:08:
[...]

Als je niet kunt zien of een variabele een array is of niet dan is het waarschijnlijker 1 van de volgende punten:
1 - Je hebt een brakke naam
2 - De scope van je variabelen is te groot
3 - Je methoden/functies zijn te lang

Tja, jij zou voor een array dus het volgende gebruiken ?
- $chairArray
- $listOfChairs
- $chairArr
- $arrChairs
?
Dan vind ik een 'a' toch korter en handiger.

Functies zijn bij mij vaak genoeg langer dan één scherm, juist omdat ik er zoveel commentaar bijzet en veel enters gebruik om het overzichtelijk te houden:

PHP:

/*
 * [..]
 * @returns array|null chair numbers to reserve
 */
public function reserveChairs($iAmount = -1) {

    /*
     * Check if we need to overwrite value. Could be when not called by dutch alias
     */
    if ($iAmount != -1) {
    
        $this->iReserveChairAmount = $iAmount;
    }

    $aChairNumbers = array();

    /*
     * Set correct values for largest chair space
     */

    ....

Dan vind ik een keer scrollen overzichtelijker dan alles een beetje op een paar regels gefrot.

[...]

imho geen argument. Een codingstyle moet automatisch goed werken. Ten eerste geeft de noodzaak van HN al aan dat er waarschijnlijk een matige IDE ondersteuning is waardoor refactoring zeer waarschijnlijk ook niet beschikbaar is. Dit maakt het vervolgens een hels karwij om eens een type aanpassing door te voeren. HN vereist actief onderhoud waarbij de gebruiker druk na moet denken. Ik snap dan ook niet waar het idee weg komt dat het de programmeur juist werk uit handen neemt.

Netbeans zou ik niet meteen een matige IDE noemen. Echter kan netbeans ook niet gokken welk type ik terugkrijg uit een functie, dat zou ik dan uit de phpdoc moeten krijgen. Ja, met een functie gaat dat prima, maar met variabelen al snel niet meer.
Ja, HN heeft beperkt onderhoud nodig, maar ik hoef echt zo goed als nooit iets aan te passen? Sowieso, hoe los jij het op als je een functie aanroept die
- Eerst alleen eeen array teruggeeft
- Na aanpassingen ook 'null' terug kan geven
- Je gebruikt foreach op de array

Dan moet je toch alsnog code gaan zitten editten? Kleine moeite de var dan ook even aan te passen.

[...]

Maar mensen die geen fatsoenlijke namen weten te verzinnen zullen vast wel gedisciplineerd genoeg zijn om overal handmatig de HN up to date te houden?

Als je programmeert met engelse functie- en variabelennamen, en je hebt een programmeur die slecht is in engels (of niet zo goed als je zou willen) dan is het voor hem makkelijker om een 'i' of een 's' te gebruiken ipv een GOEDE varnaam te schrijven..
But like I said, hoe vaak pas je daadwerkelijk je flow aan?

[...]

Het lijkt me handiger om bij de documentatie van de functie op te geven wat deze verwacht en terug geeft. In het stuk commentaar kun je meer kwijt dan in 1 teken in je variabele naam. Ik neem aan dat ze zelfs voor php wel een javadoc achtige notatie hebben?

Wederom: sluit het één het ander uit? Dat kan toch prima beiden?

[...]

Ik zou zelfs eerder amountOfAvailableChars gebruiken.

Tja, dan zie ik zelfs voordelen dat HN zelfs sneller ontwikkeld als je zulke varnames gaat gebruiken..

[Toolskyn]

Zolang mensen maar niet dingen als

PHP:

function ____(){for($_=1;$_<$__;$_++){if($_==$___)return $_;}return false;}

gaan schrijven is het toch ook weer niet zo heilig of je nu wel of niet hungarian notation gebruikt. Ik zie hier een beetje twee kampen, die waarin het absoluut heilig verboden is om hungarian notation te gebruiken en die waarin het absoluut niet anders mogelijk is dan alleen hungarian notation gebruiken.

Maar laten we eerlijk zijn, er zijn van beide stijlen voorbeelden te vinden die prima leesbaar zijn, en er zijn van beiden ook voorbeelden te vinden die echt vreselijk zijn. Als een programmeur in z'n eentje werkt moet ie lekker zelf weten welke stijl ie kiest. In een groter project bepaal je van te voren even de stijl van programmeren en moeten de programmeurs daarna niet meer zeuren. Het is niet dat de keuze voor het een of het ander een dodelijke zonde is, ver van dat zelfs.

[hostname]

PDT/Eclipse houdt gewoon netjes bij van welk type een variable is en geeft daar ook 'IntelliSense' op (bij objecten). Daar heb je dus helemaal geen hungarian notation voor nodig, mits je een fatsoenlijk IDE hebt.

Peter schreef op woensdag 17 maart 2010 @ 08:24:
Gezien er in PHP 5.4 *waarschijnlijk* ook scalar-types als hints gebruikt kunnen worden wordt ...

Recentelijk is besloten dat die patch inderdaad in de volgende versie (5.4 / 6) komt. Maar dat is nog geen garantie dat het ook gaat gebeuren... (PHP6 gaan ze nu ook helemaal opnieuw schrijven/implementeren).

[Voutloos]

krvabo schreef op woensdag 17 maart 2010 @ 09:25:
Als je programmeert met engelse functie- en variabelennamen, en je hebt een programmeur die slecht is in engels (of niet zo goed als je zou willen) dan is het voor hem makkelijker om een 'i' of een 's' te gebruiken ipv een GOEDE varnaam te schrijven..

Dit argument kan alleen maar een sarcastisch grapje zijn.

Als je slecht in spellen bent of dyslectisch bent, moet je maar code completion gebruiken of een IDE welke waarschuwt voor ongedeclareerde vars.

[YopY]

HN is, zoals Janoz ook al aangeeft, een soort van lapmiddel voor brakke code. Als je al variabelen hebben die van type veranderen, zou je al na moeten denken over je code, en dat in twijfel trekken.

Ik bedoel, hoe vaak doet iemand in de praktijk nu

PHP:

$piet = "1337";
$piet = (int) $piet;
$piet = array($piet, $piet);

in één functie oid? Ik niet.

Code die wij willen laten certificeren willen ze ook dat wij alle class variabelen (fields?) prefixen met 'my', en ze noemen dit ook hungarian notation. Dus je krijgt myId, myPiet, myKlaas boven elke class definitie.

Mijn contra-argument: een beetje IDE, zelfs een beetje text editor, geeft dit soort dingen al een afwijkende kleur (die je vaak ook nog kunt customizen), geeft waarschuwingen als je er gekke dingen mee doet, dus het is alleen handig als je nog in Notepad oid dit soort dingen doet.

Heb zo gereaguurd op een blogpost van die ontwikkelaar, met een paar plaatjes erbij hoe ik het ingericht heb / zou kunnen. Zeg nou zelf, welke is beter, myBob of bob in het fel bold rood?

http://img138.imageshack.us/img138/2306/thingymabob1.png
http://img191.imageshack.us/img191/6199/thingymabob2.png
http://img52.imageshack.us/img52/1051/thingymabob3.png

[krvabo]

Voutloos schreef op woensdag 17 maart 2010 @ 09:54:
[...]
Dit argument kan alleen maar een sarcastisch grapje zijn.

Als je slecht in spellen bent of dyslectisch bent, moet je maar code completion gebruiken of een IDE welke waarschuwt voor ongedeclareerde vars.

Nee hoor, dat was geen grap. Dat het geen sterk argument is: klopt. Maar dat is een overmatig luie programmeur ook niet.
Als je te lui bent om een fatsoenlijke naam te gebruiken voor je variabelen dan hoor je niet te programmeren. Net zoals dat als je te lui bent om je HN-naamgeving consequent en correct te gebruiken je het niet zou moeten gebruiken.
Als je echter geen lamzak bent dan kun je gewoon HN gebruiken en wordt de code gewoon inzichtelijker, voornamelijk als andere mensen er ook mee werken.

Het is niet dat HN heilig is, maar
1) het zorgt voor overzichtelijkheid, ZELFS in IDE's die niet zo goed zijn als gehoopt mag worden
2) je krijgt (soms) handigere variabelenamen, die korter kunnen zijn.
$numChairs / $amountOfChairs zijn langer dan $iChairs, en het leest hetzelfde.

Zoals ik al zei sluit het gebruik van HN andere ontwikkelstijlen niet uit, terwijl het wel wat toevoegt aan loose-typed talen.
$numberOfPeople en $iNumberOfPeople ($iPeople kan ook, maar even ter illustratie) scheelt één letter, en het is nauwelijks meer werk?

YopY schreef op woensdag 17 maart 2010 @ 09:59:
HN is, zoals Janoz ook al aangeeft, een soort van lapmiddel voor brakke code. Als je al variabelen hebben die van type veranderen, zou je al na moeten denken over je code, en dat in twijfel trekken.

Dat is ook precies wat ik zeg. Aangezien je variabelen niet van type veranderen (of nauwelijks) hoef je dus (zo goed als) nooit je variabelen te renamen. M.a.w. je kunt prima HN gebruiken.

---

Overigens gebruik in strong-typed talen dus nooit HN, omdat het daar niets toevoegt.
In PHP voegt HN toe dat je niet hoeft te gokken welk type je krijgt. Dat is het, niet meer, niet minder.

[ Voor 5% gewijzigd door krvabo op 17-03-2010 10:13 ]

[Voutloos]

krvabo schreef op woensdag 17 maart 2010 @ 10:10:
2) je krijgt (soms) handigere variabelenamen, die korter kunnen zijn.
$numChairs / $amountOfChairs zijn langer dan $iChairs, en het leest hetzelfde.

En daar verschillen wij ook duidelijk van mening. Imo leest het absoluut niet hetzelfde en de lengte van variabelenamen mag helemaal al nooit het argument zijn. Ik besteed liever tijd in het optimaliseren van var namen qua leesbaarheid en betekenis ipv lengte.

[Janoz]

krvabo schreef op woensdag 17 maart 2010 @ 09:25:

Tja, jij zou voor een array dus het volgende gebruiken ?
- $chairArray
- $listOfChairs
- $chairArr
- $arrChairs
?
Dan vind ik een 'a' toch korter en handiger.

Ik zou listOfChairs of chairList gebruiken. Korter is niet hetzelfde als handiger.

Functies zijn bij mij vaak genoeg langer dan één scherm, juist omdat ik er zoveel commentaar bijzet en veel enters gebruik om het overzichtelijk te houden:

PHP:

/*
 * [..]
 * @returns array|null chair numbers to reserve
 */
public function reserveChairs($iAmount = -1) {

    /*
     * Check if we need to overwrite value. Could be when not called by dutch alias
     */
    if ($iAmount != -1) {
    
        $this->iReserveChairAmount = $iAmount;
    }

    $aChairNumbers = array();

    /*
     * Set correct values for largest chair space
     */

    ....

Dan vind ik een keer scrollen overzichtelijker dan alles een beetje op een paar regels gefrot.

Precies. Heel overzichtelijk. Ik kan me dan ook erg moeilijk voorstellen dat je in een dergelijke opzet niet snel kunt achterhalen wat, bij twijfel, het type van een variabele is

Netbeans zou ik niet meteen een matige IDE noemen. Echter kan netbeans ook niet gokken welk type ik terugkrijg uit een functie, dat zou ik dan uit de phpdoc moeten krijgen. Ja, met een functie gaat dat prima, maar met variabelen al snel niet meer.

Als je niet automatisch kunt refactoren vind ik dat je een beperkte integrated development enviroment hebt. Of dat ligt aan de tool of het platform laat ik maar even in het midden .

Javadoc kun je ook bij een variabele zetten, maar als het een probleem is denk ik eerder dat je last hebt van puntje 2 "scope van je variabelen is te groot".

Ja, HN heeft beperkt onderhoud nodig, maar ik hoef echt zo goed als nooit iets aan te passen? Sowieso, hoe los jij het op als je een functie aanroept die
- Eerst alleen eeen array teruggeeft
- Na aanpassingen ook 'null' terug kan geven
- Je gebruikt foreach op de array

Dan moet je toch alsnog code gaan zitten editten? Kleine moeite de var dan ook even aan te passen.

Dus omdat je toch al code aan moet passen kun je net zo goed nog meer code aan gaan passen? Persoonlijk vind ik dat een beetje een vreemde redenatie. Daarnaast, dat een functie nu ook null terug kan geven betekent niet dat het type van de return value aanpast.

Als je programmeert met engelse functie- en variabelennamen, en je hebt een programmeur die slecht is in engels (of niet zo goed als je zou willen) dan is het voor hem makkelijker om een 'i' of een 's' te gebruiken ipv een GOEDE varnaam te schrijven..
But like I said, hoe vaak pas je daadwerkelijk je flow aan?

Duidelijke variabele namen hangen niet zo heel erg af van goed engelse kennis. Er zijn redelijk standaard regeltjes. Amount, available, list, __s voor meervoud. Dat lijstje lijkt mij een stuk eenvoudinger dan een legenda met enkele karakters uit het hoofd te leren.

Daarnaast heb je geen reet meer aan HN als straks alles $oChair is.

Sowieso wordt het in HN nogal een onoverzichtelijke benden wanneer je steeds meer object

Dubbel onderhoud is synoniem voor 'vroeg of laat gaat het zeker een keer uit elkaar lopen'.

Tja, dan zie ik zelfs voordelen dat HN zelfs sneller ontwikkeld als je zulke varnames gaat gebruiken..

Want? Heeft netbeans geen ctrl-spatie? De hoeveelheid toetsaanslagen die je nodig hebt is een requirement die je mee moet wegen bij de keuze van je IDE, niet in de keuze van je coding standaard. Dat idee doortrekkende zou betekenden dat je voor de hoeveelheid stoelen eigenlijk $iC zou moeten gebruiken.

[krvabo]

Voutloos schreef op woensdag 17 maart 2010 @ 10:19:
[...]
En daar verschillen wij ook duidelijk van mening. Imo leest het absoluut niet hetzelfde en de lengte van variabelenamen mag helemaal al nooit het argument zijn. Ik besteed liever tijd in het optimaliseren van var namen qua leesbaarheid en betekenis ipv lengte.

$amountOfChairsAvailableForRental

Kun je anders even minder neerkijkend doen tijdens een discussie alsjeblieft?


Ik zeg nergens dat je zo kort mogelijke variabelen moet gebruiken. Ik zeg alleen dat variabelen wel korter worden, wat ontwikkeltijd scheelt. Het is nog net zo leesbaar, maar dan met kortere namen. Als jij dat niet vindt: prima, maar zo'n smiley gebruiken schiet me echt in het verkeerde keelgat.

Janoz schreef op woensdag 17 maart 2010 @ 10:21:
[...]

Ik zou listOfChairs of chairList gebruiken. Korter is niet hetzelfde als handiger.

Klopt, korter is niet altijd handiger, maar als je (iets) kortere naamgeving kunt gebruiken dan kan het ook overzichtelijker worden. Je gebruikt immers ook geen functienamen als getPeopleConnectedToCompaniesByGroupId()

Maar goed, dat is een puntje voor eigen voorkeur.

[...]

Precies. Heel overzichtelijk. Ik kan me dan ook erg moeilijk voorstellen dat je in een dergelijke opzet niet snel kunt achterhalen wat, bij twijfel, het type van een variabele is

Jawel, het is prima achterhaalbaar hoor, maar toch vind ik het handiger als ik verder in een stukje code ben, bijvoorbeeld bij het schrijven van een query, dat ik weet of ik een IN() of een == moet gebruiken, zonder dat ik mijn gedachtegang hoef te gaan om te kijken welk type het is.

[...]


Dus omdat je toch al code aan moet passen kun je net zo goed nog meer code aan gaan passen? Persoonlijk vind ik dat een beetje een vreemde redenatie. Daarnaast, dat een functie nu ook null terug kan geven betekent niet dat het type van de return value aanpast.

Nee, dat betekend het niet, maar wel dat je er rekening mee moet houden.
Sowieso gebeurt het toch al zo goed als nooit dat je echt een variabeletype veranderd..
Maar ik vind het dan inderdaad een kleine moeite, wellicht is dat persoonlijk.

[...]

Duidelijke variabele namen hangen niet zo heel erg af van goed engelse kennis. Er zijn redelijk standaard regeltjes. Amount, available, list, __s voor meervoud. Dat lijstje lijkt mij een stuk eenvoudinger dan een legenda met enkele karakters uit het hoofd te leren.

Daarnaast heb je geen reet meer aan HN als straks alles $oChair is.

Je laatste punt wil ik je wel toegeven. Dan is het inderdaad al weer minder makkelijk omdat je dan inderdaad moet kijken naar het return type van de functie.
Zo lang is het lijstje overigens ook weer niet, en het laat zich wel gokken natuurlijk

[...]

Dubbel onderhoud is synoniem voor 'vroeg of laat gaat het zeker een keer uit elkaar lopen'.


Want? Heeft netbeans geen ctrl-spatie? De hoeveelheid toetsaanslagen die je nodig hebt is een requirement die je mee moet wegen bij de keuze van je IDE, niet in de keuze van je coding standaard. Dat idee doortrekkende zou betekenden dat je voor de hoeveelheid stoelen eigenlijk $iC zou moeten gebruiken.

Uiteraard heeft Netbeans ctrl+spatie, maar te lange namen voor alles zorgt imho weer voor onoverzichtelijke code.
Het is natuurlijk een dunne lijn, overzichtelijke korte code, of eigenlijk-al-te-lange code..
M.i. zou je sowieso geen variabelen moeten hebben met een lengte korter dan 5.. Maar meer dan 25 is ook weer overdreven..

[ Voor 64% gewijzigd door krvabo op 17-03-2010 10:31 ]

[MueR]

krvabo schreef op woensdag 17 maart 2010 @ 07:19:
Je zegt dat je aan code snel kunt zien welk type.. totdat je een keer een functie aanroept die een int terug zou moeten geven.. maar wellicht geeft ie wel false ergens (0) of true (1). Snel weten wat je dan kan verwachten is zeer handig.

Als jij een functie schrijft die een int moet teruggeven (waar dan ook voor) en ik krijg een true of false er uit mag je ook je code opnieuw doen. Dat hoort namelijk niet te kunnen. Ik verwacht een bruikbaar getal of een meaningful default, niet een false. Mocht er door een fout ergens iets niet goed gaan, kan je een exception gooien.
Verder kan ik met phpDoc style commentaar gewoon zien wat een functie doet. De meeste IDEs voor php ontwikkeling ondersteunen dit gewoon.

$iChairsAvailable is imho handiger dan $numberAvailableChairs..

Beiden zijn niet nodig imho. $availableChairs werkt ook prima. Of je nu een "i" of "number" er voor zet, beiden zijn in de basis gewoon een type definition. Er gaat een getal in zitten. Verder met een aantal mensen hier, de lengte van een varnaam gebruiken als argument is

[ Voor 8% gewijzigd door MueR op 17-03-2010 10:30 ]

[Janoz]

krvabo schreef op woensdag 17 maart 2010 @ 10:10:
Het is niet dat HN heilig is, maar
1) het zorgt voor overzichtelijkheid, ZELFS in IDE's die niet zo goed zijn als gehoopt mag worden

Schijnveiligheid die puur afhangt van de consequent correct toepassing. Om zeker te weten moet je alsnog je code doorwerken.

2) je krijgt (soms) handigere variabelenamen, die korter kunnen zijn.
$numChairs / $amountOfChairs zijn langer dan $iChairs, en het leest hetzelfde.

Nogmaals. Lengte is de meest belachelijke meetwaarde voor de duidelijkheid van een variabele naam.

Ik heb liever
$someObjectValid
$someObjectAvailable
$someObjectReserved

dan
$bSomeObject

[Janoz]

krvabo schreef op woensdag 17 maart 2010 @ 10:22:
$amountOfChairsAvailableForRental

Keurig duidelijke variabele naam (alhoewel ik het liever als een functie zou zien aangezien het me een typische afgeleide waarde lijkt). Iig een stuk duidelijker dan

$iChairRent

[krvabo]

Janoz schreef op woensdag 17 maart 2010 @ 10:28:
[...]

Schijnveiligheid die puur afhangt van de consequent correct toepassing. Om zeker te weten moet je alsnog je code doorwerken.

Inderdaad, consequent correcte toepassing. Als het je al niet lukt om zoiets consistent te houden.. WAAROM niet? Zo moeilijk is het ook weer niet.

[...]

Nogmaals. Lengte is de meest belachelijke meetwaarde voor de duidelijkheid van een variabele naam.

Ik heb liever
$someObjectValid
$someObjectAvailable
$someObjectReserved

dan
$bSomeObject

Ik vind lange variabelenamen ook onoverzichtelijk, maar dat is misschien persoonlijk. Ik heb geen zin om meters code te gaan zitten lezen als een boek. Ik wil snel zien waar een variabele voor staat.
En uiteraard gebruik je in dat voorbeeld wel gewoon
$bSomeObjectValid
$bSomeObjectAvailable
Ik zei niet dat het altijd korter wordt, nieteens dat het vaker korter dan langer wordt.

MueR schreef op woensdag 17 maart 2010 @ 10:28:
[...]

Als jij een functie schrijft die een int moet teruggeven (waar dan ook voor) en ik krijg een true of false er uit mag je ook je code opnieuw doen. Dat hoort namelijk niet te kunnen. Ik verwacht een bruikbaar getal of een meaningful default, niet een false. Mocht er door een fout ergens iets niet goed gaan, kan je een exception gooien.

Agreed, maar ik neem aan dat in de organisatie waar jij werkt (als je al iets programmeert) vaak genoeg oudere code tegenkomt.. of code moet schrijven die daar volgens een bepaalde methode geschreven _moet_ worden ('geef aantal beschikbare stoelen of NULL als het niet mogelijk is te reserveren'). Natuurlijk is het opgooien van een exception vele malen netter, maar niet alles mag altijd geschreven worden zoals je het zou willen. Wellicht moet het wel samenwerken met een ander systeem wat wel een int of null verwacht, geen exception.

Beiden zijn niet nodig imho. $availableChairs werkt ook prima. Of je nu een "i" of "number" er voor zet, beiden zijn in de basis gewoon een type definition. Er gaat een getal in zitten. Verder met een aantal mensen hier, de lengte van een varnaam gebruiken als argument is

Wat een geweldige smiley om te gebruiken! Dat is vooral niet op te vatten als een sneer

Janoz schreef op woensdag 17 maart 2010 @ 10:30:
[...]

Keurig duidelijke variabele naam (alhoewel ik het liever als een functie zou zien aangezien het me een typische afgeleide waarde lijkt). Iig een stuk duidelijker dan

$iChairRent

Ik zou er dan $iChairsForRent of $iChairsRentable van maken, maar dat terzijde.

[ Voor 7% gewijzigd door krvabo op 17-03-2010 10:42 ]

[Janoz]

krvabo schreef op woensdag 17 maart 2010 @ 10:40:
Inderdaad, consequent correcte toepassing. Als het je al niet lukt om zoiets consistent te houden.. WAAROM niet? Zo moeilijk is het ook weer niet.

Murphy dicteert dat een dergelijke niet te valideren handmatige onderhoudsslag die door mensen uitgevoerd zal worden een keer mis zal gaan. Het grootste probleem is daarnaast dat de kans dat dit misgaat alleen maar groter wordt wanneer het project groter en complexer wordt. Wanneer je vervolgens vertrouwd op de correcte toepassing kan het vervolgens alleen nog maar verder uit de hand lopen, waarna je waarschijnlijk wel gedwongen wordt om je complete project handmatig door te gaan wandelen of al je labeltjes nog wel in overeenstemming zijn met de werkelijkheid.

[Haan]

Het wordt de TS nu wel erg lastig gemaakt wat hij moet gaan doen, wordt het wel of geen Hungarian notation? Ik heb zelf het idee dat het in PHP nog wel verdedigbaar is, zo te zien zijn de voorstanders in de discussie hier ook PHP-ers.

[MueR]

krvabo schreef op woensdag 17 maart 2010 @ 10:40:
Agreed, maar ik neem aan dat in de organisatie waar jij werkt (als je al iets programmeert) vaak genoeg oudere code tegenkomt.. of code moet schrijven die daar volgens een bepaalde methode geschreven _moet_ worden ('geef aantal beschikbare stoelen of NULL als het niet mogelijk is te reserveren'). Natuurlijk is het opgooien van een exception vele malen netter, maar niet alles mag altijd geschreven worden zoals je het zou willen. Wellicht moet het wel samenwerken met een ander systeem wat wel een int of null verwacht, geen exception.

Aangezien ik maatwerk websites/software maak doe ik niet veel met oude code, behalve trashen. Verder kan je in je exception catcher natuurlijk gewoon een meaningful default aangeven indien dit vereist wordt door een eventueel extern systeem.

Wat een geweldige smiley om te gebruiken! Dat is vooral niet op te vatten als een sneer

Gelukkig kan dat ook af en toe. Het argument is redelijk kansloos. Het enige scenario (wat ik zo kan bedenken) waar lange variabelenamen vervelend zijn is voor de leesbaarheid in je IDE, wanneer je alles zonder horizontaal scrollen op je scherm wil hebben. Als je dat gaat aandragen als argument om vooral maar hungarian notation te gebruiken, zou ik zeggen dat je een breedbeeld monitor kan kopen, of een hogere resolutie instellen.

Haan schreef op woensdag 17 maart 2010 @ 11:02:
Het wordt de TS nu wel erg lastig gemaakt wat hij moet gaan doen, wordt het wel of geen Hungarian notation? Ik heb zelf het idee dat het in PHP nog wel verdedigbaar is, zo te zien zijn de voorstanders in de discussie hier ook PHP-ers.

Tja, eigen voorkeur. Ik (als PHPer) vind het gruwelijk. Binnen het bedrijf mag het niet en blij toe.

[ Voor 13% gewijzigd door MueR op 17-03-2010 11:05 ]

[Cartman!]

MueR schreef op woensdag 17 maart 2010 @ 10:28:
[...]
Beiden zijn niet nodig imho. $availableChairs werkt ook prima. Of je nu een "i" of "number" er voor zet, beiden zijn in de basis gewoon een type definition. Er gaat een getal in zitten. Verder met een aantal mensen hier, de lengte van een varnaam gebruiken als argument is

Ben ik het niet helemaal mee eens, het zou net zo goed een array kunnen zijn met de beschikbare plaatsen ( array(1,5,6,8) ). Om die reden vind ik het prefixen van variabelen met het type erg handig.

edit: kan iemand de topictitel fixen? Het is nu half engels/half nederlands met onnodige spatie enzo

[ Voor 8% gewijzigd door Cartman! op 17-03-2010 11:37 ]

[PeterSelie]

MueR schreef op woensdag 17 maart 2010 @ 11:04:
[...]

Aangezien ik maatwerk websites/software maak doe ik niet veel met oude code, behalve trashen. Verder kan je in je exception catcher natuurlijk gewoon een meaningful default aangeven indien dit vereist wordt door een eventueel extern systeem.

Wat een onzin, ik kan me niet voorstellen dat je nooit gebruik maakt van algemene code die in latere projecten terugkomt of later nog in deze projecten moet gaan werken. In dat geval is een stuk leesbaarheid wel prettig.
Ik snap overigens heel de discussie om HN niet echt, het is puur voorkeur en niet te bestempelen als goed of slecht. Uberhaupt snap ik niet waarom een organisatie het gebruik ervan zou verbieden, tenzij er uiteraard richtlijnen bestaan waarin op een andere manier van notatie gericht wordt.

Gelukkig kan dat ook af en toe. Het argument is redelijk kansloos. Het enige scenario (wat ik zo kan bedenken) waar lange variabelenamen vervelend zijn is voor de leesbaarheid in je IDE, wanneer je alles zonder horizontaal scrollen op je scherm wil hebben. Als je dat gaat aandragen als argument om vooral maar hungarian notation te gebruiken, zou ik zeggen dat je een breedbeeld monitor kan kopen, of een hogere resolutie instellen.

Again: voorkeur. Hoezo kansloos? Beetje oppervlakkig en kort door de bocht. Het kopen van een breedbeeld monitor of het instellen van een hogere resolutie, dat vind ik pas kansloos en nonsense..
Het verkorten van een variabelnaam verhoogd gewoon de leesbaarheid en is puur en alleen voorkeur. Wanneer mensen dit een geldig argument voor eigen gebruik vinden vind ik 't een beetje jammer om daar op in te gaan rossen.

HN is puur een onderwerp van voorkeur, daarin zijn argumenten alles behalve zinloos / kansloos, aangezien dit de voorkeur vormt.

[ Voor 10% gewijzigd door PeterSelie op 17-03-2010 11:36 ]

[Hydra]

Haan schreef op woensdag 17 maart 2010 @ 11:02:
Het wordt de TS nu wel erg lastig gemaakt wat hij moet gaan doen, wordt het wel of geen Hungarian notation?

Gewoon geen weakly typed taal gebruiken

Ik denk dat het af te raden is. Er zijn twee kampen binnen gebruikers van talen als PHP en ik heb zo'n vermoeden dat het anti-hungarian kamp groter is. Daarnaast zijn er coding standaards en die kun je volgens mij altijd 't beste volgen. Iemand die hier de standaards niet volgt wordt net zo goed op z'n vingers getikt.

Wat ik zelf bijvoorbeeld erg irritant vindt is het prefixen van members met een underscore. Wij coden vooral in Java. Zelf ben ik daar op tegen maar dat is een discussie die ik helaas verloren heb

MueR schreef op woensdag 17 maart 2010 @ 11:04:
Tja, eigen voorkeur. Ik (als PHPer) vind het gruwelijk. Binnen het bedrijf mag het niet en blij toe.

Wij coden (god zij dank) vooral in Java maar ik heb vroeger bij een webbedrijfje gewerkt aan een CMS. Dat heb ik moeten refactoren omdat het door 3 verschillende mensen gebouwd was waarvan 2 complete prutsers waren, en een van hun gebruikte HN in z'n code (maar ook weer niet consequent). Dat heb ik er dus ook fijn uitgeknikkerd. Sindsdien heb ik in ieder geval gevoelsmatig geen hoge pet op van mensen die HN aanhangen

[ Voor 28% gewijzigd door Hydra op 17-03-2010 11:38 ]

[Cartman!]

Hydra schreef op woensdag 17 maart 2010 @ 11:35:
[...]
Ik denk dat het af te raden is. Er zijn twee kampen binnen gebruikers van talen als PHP en ik heb zo'n vermoeden dat het anti-hungarian kamp groter is. Daarnaast zijn er coding standaards en die kun je volgens mij altijd 't beste volgen. Iemand die hier de standaards niet volgt wordt net zo goed op z'n vingers getikt.

Niemand zegt dat de Zend Framework coding standaard de standaard is. Wij hebben 3 jaar geleden een eigen standaard bedacht intern en daar zitten de prefixes ook bij. Ik heb het idee dat het me een berg tijd scheelt als ik in de code van collega's kijk om iets te fixen dat ik weet wat voor type de variabelen hebben.

[Janoz]

SoaDmaggot schreef op woensdag 17 maart 2010 @ 11:35:
Wat een onzin, ik kan me niet voorstellen dat je nooit gebruik maakt van algemene code die in latere projecten terugkomt of later nog in deze projecten moet gaan werken. In dat geval is een stuk leesbaarheid wel prettig.

Leesbaarheid is zeker een vereiste voor goede code, maar leesbaarheid bereik ik liever met:
- Meerdere kortere methoden/functies ipv minder lange.
- Niet bezuinigen op de lengte van functie en variabele namen.
- Scope van variabelen zo klein mogelijk houden.
- Low cohesion tussen classes.
- Standaard documentatie bij methoden en functies waarin ook de betekenis van de variabelen en return value beschreven wordt en waarin aangegeven wordt welke exceptions er in welke situatie op kunnen treden.

In tegenstelling tot HN hebben deze punten de volgende voordelen:
- Het is redelijk simpel te spotten of automatisch af te leiden wanneer een regel geschonden wordt.
- De metrics zijn geautomatiseerd te bepalen waardoor raportages over code quality mogelijk zijn.
- Bieden meer overzicht dan enkel het type van je variabelen.
- Blijven werken wanneer je object georiënteerd werkt. (als alles een $o... is heb je niks meer aan HN).

Ik snap overigens heel de discussie om HN niet echt, het is puur voorkeur en niet te bestempelen als goed of slecht. Uberhaupt snap ik niet waarom een organisatie het gebruik ervan zou verbieden, tenzij er uiteraard richtlijnen bestaan waarin op een andere manier van notatie gericht wordt.

Zie onderaan.

Again: voorkeur. Hoezo kansloos? Beetje oppervlakkig en kort door de bocht. Het kopen van een breedbeeld monitor of het instellen van een hogere resolutie, dat vind ik pas kansloos en nonsense..
Het verkorten van een variabelnaam verhoogd gewoon de leesbaarheid en is puur en alleen voorkeur. Wanneer mensen dit een geldig argument voor eigen gebruik vinden vind ik 't een beetje jammer om daar op in te gaan rossen.

Ik vind het kopen van een nieuwe monitor of het aanpassen van je resolutie ook onzin. Een betere oplossing is om je regel consequenter af te breken. Ik begrijp echter niet hoe het verkorten van een variabele naam de boel leesbaarder maakt.

HN is puur een onderwerp van voorkeur, daarin zijn argumenten alles behalve zinloos / kansloos, aangezien dit de voorkeur vormt.

Niet mee eens. HN is een codingstyle fossiel uit de tijd dat ruimte nog wel uitmaakte en tooling beperkt was. De enige die dit überhaupt opgepakt heeft was MS en zelfs zij zijn er al van af gestapt.

[ Voor 4% gewijzigd door Janoz op 17-03-2010 11:52 ]

[curkey]

Site Joel On Software heeft m.i. een mooi verhaal over de Hongaarse notatie geschreven. Eentje die er wel zinnig uitziet, in tegenstelling tot wat MS ooit bedacht heeft voor de Windows API.

http://www.joelonsoftware.com/articles/Wrong.html

[MueR]

SoaDmaggot schreef op woensdag 17 maart 2010 @ 11:35:
Wat een onzin, ik kan me niet voorstellen dat je nooit gebruik maakt van algemene code die in latere projecten terugkomt of later nog in deze projecten moet gaan werken. In dat geval is een stuk leesbaarheid wel prettig.

Klopt, we bouwen op basis van een eigen framework. De functies en classes daarin zijn redelijk goed inline gedocumenteerd, plus phpDoc comments bij het grootste deel. Ik ga er van uit dat een programmeur bij ons daar wel uit komt. Zo niet, dan zit hij duidelijk bij het verkeerde bedrijf.

Uberhaupt snap ik niet waarom een organisatie het gebruik ervan zou verbieden, tenzij er uiteraard richtlijnen bestaan waarin op een andere manier van notatie gericht wordt.

Richtlijnen hebben we ook, camelCasen. Verder zoals gezegd absoluut geen Hungarian. Vind ik niet prettig lezen, vindt de baas niet prettig lezen.

Het kopen van een breedbeeld monitor of het instellen van een hogere resolutie, dat vind ik pas kansloos en nonsense..

Klopt. Is het ook. Dat was de bedoeling.

Het verkorten van een variabelnaam verhoogd gewoon de leesbaarheid en is puur en alleen voorkeur. Wanneer mensen dit een geldig argument voor eigen gebruik vinden vind ik 't een beetje jammer om daar op in te gaan rossen.

Alleen dragen een aantal mensen het hier niet aan als eigen redenering, maar als absoluut voordeel. Dan mag ik toch gewoon zeggen dat ik het een kulreden vind?

[ Voor 4% gewijzigd door MueR op 17-03-2010 12:48 ]

[PeterSelie]

MueR schreef op woensdag 17 maart 2010 @ 12:47:
[...]

Alleen dragen een aantal mensen het hier niet aan als eigen redenering, maar als absoluut voordeel. Dan mag ik toch gewoon zeggen dat ik het een kulreden vind?

Waar las jij exact dat het voor ieder als absoluut voordeel geldt in plaats van persoonlijke voorkeur? Ik zie niemand impliceren dat het om een `DAMN DIT MOET IEDEREEN DOEN~~!!`-geval gaat, dat is puur je eigen interpretatie.

[ Voor 3% gewijzigd door PeterSelie op 17-03-2010 13:41 ]

[pedorus]

Haan schreef op woensdag 17 maart 2010 @ 11:02:
Het wordt de TS nu wel erg lastig gemaakt wat hij moet gaan doen, wordt het wel of geen Hungarian notation? Ik heb zelf het idee dat het in PHP nog wel verdedigbaar is, zo te zien zijn de voorstanders in de discussie hier ook PHP-ers.

Dit lijkt me een misverstand. Het lijkt me duidelijk als je even gaat [google=php coding conventions] hoe het echt zit: verreweg de meeste professionele php-programmeurs gebruiken geen HN. Al ga ik [google=php coding conventions hungarian] dan zie ik alleen maar afraders (wellicht behalve Joel). Het is me nog niet gelukt een duidelijke php guideline te vinden die het wel aanraadt.

Cartman! schreef op woensdag 17 maart 2010 @ 11:39:
[...]

Niemand zegt dat de Zend Framework coding standaard de standaard is. Wij hebben 3 jaar geleden een eigen standaard bedacht intern en daar zitten de prefixes ook bij. Ik heb het idee dat het me een berg tijd scheelt als ik in de code van collega's kijk om iets te fixen dat ik weet wat voor type de variabelen hebben.

Zou je mij kunnen uitleggen hoe dit precies werkt? Welke prefixes gebruik je? Kun je === gebruiken bij geprefixte variabelen? Hoe werkt het bijvoorbeeld bij een object van het type DOMNodeList: prefixen met o en dan weet je nog niet dat je foreach() kan gebruiken? En kun je mij vertellen waar je die tijd precies hebt bespaard?

[YopY]

Ik heb een uitdaging voor de pro-HN partij: Post een stukje code waar HN een duidelijk voordeel heeft tegenover niet-HN notatie. Ik ben zelf van mening dat HN weinig meerwaarde heeft in 'mooie' code, maar dat is misschien een vooroordeel.

[RayNbow]

De enige plek waar ik Hungarian Notation gebruik is bij het maken van GUIs, doodeenvoudig om de reden dat ik geen betere namen kan verzinnen. Een tekstveld voor een adres zou ik dus txtAddress noemen.

[Haan]

Hmm ja, dat doe ik inderdaad ook Eigenlijk nooit bij stilgestaan dat dat eigenlijk hetzelfde is.

[Standeman]

Ik vind HN een drama omdat het je ook allemaal moet onderhouden. Mocht er ergens een attribute van type veranderen (int naar double bijv.) moet je het overal gaan zitten aanpassen en geheid dat je het op N+1 plaatsen vergeet. Als devver heb ik wel beters en leukers te doen.

Overigens snap ik sowieso niet waarom er loose-typed talen bestaan? Als iets wel niet fouten in de hand werkt is het on-the-fly veranderen van een type.

* Standeman heeft ooit een keer drie dagen zitten zoeken naar een kleine *$&%-bug in een stapel javascripts welke in een strong-typed taal nooit was voorgekomen.

[ Voor 3% gewijzigd door Standeman op 18-03-2010 15:54 ]

[kwaakvaak_v2]

geweldig hoe een vraag als dit 100% garantie is voor een stevige pro/con HN notatie discussie


En ontopic, ik vind dat je aan een variabele in 1 oog opslag moet kunnen zien wat er in kan staan. En dan maakt camelCase het lezen best wel makkelijker.

Heb bij zo'n beetje alle bedrijven waar ik de afgelopen 10 jaar PHP geschreven heb, verschillende notatie's in de developers guide gehad.

$iMooiGetal, $i_mooi_getal, $mooigetal, $watjijwilalshetmaareenlabelheeft,$MooiGetal, $mooiGetal
is voorbij gekomen.

[Avalaxy]

Maar als je per sé wilt kunnen zien wat voor type een bepaalde variabele is, zou je dan niet beter bij je werkgever kunnen opteren om met Java te werken? (geldt alleen bij de ontwikkeling van nieuwe systemen uiteraard)

[HuHu]

Avalaxy schreef op donderdag 18 maart 2010 @ 16:29:
Maar als je per sé wilt kunnen zien wat voor type een bepaalde variabele is, zou je dan niet beter bij je werkgever kunnen opteren om met Java te werken? (geldt alleen bij de ontwikkeling van nieuwe systemen uiteraard)

Want zien welk type een variabele is kan alleen in Java?

[PeterSelie]

Avalaxy schreef op donderdag 18 maart 2010 @ 16:29:
Maar als je per sé wilt kunnen zien wat voor type een bepaalde variabele is, zou je dan niet beter bij je werkgever kunnen opteren om met Java te werken? (geldt alleen bij de ontwikkeling van nieuwe systemen uiteraard)

Daarbij zal je al je developers dan vaak om moeten gaan scholen of een opfriscursus aan moeten gaan bieden. Kosten / tijd.