[c#] Hungarian of Camel casing

[bastv]

Ik ben sinds kort bezig met C# en ben nu aan het uitzoeken wat de standaarden zijn binnen .NET

in veel tutorials/ebooks gebruiken ze Hungarian notation zoals: "string m_sName;"
Op veel internet sites word ook gezegd dat je dat beter niet kan doen (en met bijv. this. te werken).

een site die aangeeft dat je geen hungarian moet gebruiken:

However, in .NET coding standards, this is not recommended. Usage of data type and M_ to represent member variables should not be done. All variables should use Camel casing.

http://www.codeproject.com/KB/cs/c__coding_standards.aspx

en één die dat weer wel zegt:

We prefer the prefix “m_” private properties because CLS compliance clearly states that variables can differ by no more than casing, using “camal case for private and pascal case for everything else” is not an option.

http://www.danrigsby.com/...08/16/c-coding-standards/


en zo zijn er nog veel meer sites.
Is er wel een standaard om moet ik kiezen wat voor mij het prettigst is?

[D-Raven]

Jij moet de code schrijven.
Kies wat jij het prettigste vindt. Persoonlijk gebruik ik _varnaam voor private vars en VarNaam voor public properties. Om een var te prefixen met een s om aan te geven dat het een string is vindt ik afschuwelijk . In 99% van de gevallen kun je al zien wat voor en var het is, en anders is er altijd nog intellisense.

[H!GHGuY]

google + msdn:
http://msdn.microsoft.com/en-us/library/ms229042.aspx

[Gomez12]

Voor zover ik weet is er geen standaard behalve een standaard binnen een bedrijf / project.

Alleen kan ik je wel afraden om hungarian te gaan gebruiken binnen .net, hungarian is leuk voor talen /ide's waar je niet direct het type van de variabele kan zien. Kan jij gelijk het type zien dan is hungarian alleen maar meer tikwerk.

[Confusion]

'Hungarian' zoals veel mensen het opvatten, is, om Linus Torvalds te citeren, 'braindead'. Daarentegen is 'Hungarian', zoals Joel Spolsky het uitlegt in zijn weblog wel degelijk nuttig. Maar in die vorm is het geen alternatief voor camelCasing; meer iets dat je ook kunt gebruiken.

Ik ben er geen fan van, omdat ik liever 'unsafeUserInput' als variabele gebruik, dan 'usUserInput', maar eigenlijk is dat ook 'Hungarian' in de zin waarin Joel het gebruikt.

Note: Waarom liever 'unsafe' voluit: hoe meer afko's je bij het lezen van code in je hoofd moet omzetten, hoe moeilijker code te begrijpen is..

[Verwijderd]

In Delphi gebruik ik wel hungarian, maar in C# houd ik me aan de MS richtlijnen: camel case voor private members en Pascal case voor properties.
Maar of iets nu btnCancel heet of CancelButton maakt eigenlijk niks uit, zolang je je maar consequent aan je eigen conventie houdt.

[ATS]

Het artikel dat Confusion aanhaalt is interessant, maar in mijn ogen niet erg overtuigend. Hoewel het wel iets zegt over hoe braindead "Systems Hungarian" is, vind ik het nog steeds niet fraai. Waarom "dx" gebruiken als je eigenlijk "width" bedoelt? Voor mij is het tweede leesbaarder dan het eerste. Dat het meer typewerk is, is dan maar jammer. Code schrijf je maar één keer, en daarna mag jij, en daarn je opvolger er nog tig keer doorheen voor updates, onderhoud en bugfixes. Dan kan de code maar beter leesbaar zijn.

Wat ik zelf overigens wél doe is member variabels prefixen met m_, zodat ik weet of ze op class of op method niveau werken, maar voor de rest ben ik liever expliciet in wat een variabele betekent door het gewoon uit te schrijven.

[Bergen]

ATS schreef op zondag 25 mei 2008 @ 19:10:
Waarom "dx" gebruiken als je eigenlijk "width" bedoelt? Voor mij is het tweede leesbaarder dan het eerste.

Dit is naar aanleiding van het zinnetje "(for example “dx” meant “width”)" uit dat artikel neem ik aan. dx (en dy) wordt vaak in grafische routines gebruikt, waar het vaak prima leesbaar is:

code:

public void lineSimple(int x0, int y0, int x1, int y1, Color color)
    {
        int pix = color.getRGB();
        int dx = x1 - x0;
        int dy = y1 - y0;

        raster.setPixel(pix, x0, y0);
        if (dx != 0) {
            float m = (float) dy / (float) dx;
            float b = y0 - m*x0;
            dx = (x1 > x0) ? 1 : -1;
            while (x0 != x1) {
                x0 += dx;
                y0 = Math.round(m*x0 + b);
                raster.setPixel(pix, x0, y0);
            }
        }
    }

(Niet mijn routine.) Als je gewend bent om naar dit soort routines te kijken dan is het zo klaar als een klontje.

Wat Hungarian/Camel betreft, ik zie het zo: Hungarian is meer bedoeld om te voorkomen dat je verkeerde typecasts gebruikt, omdat je bij elke variabele direct ziet wat het type is. Maar bij talen waar de compiler voorkomt dat er in het wilde weg wordt getypecast (zoals Delphi) is het volstrekt overbodig. In talen zoals PHP waar je zonder na te denken mag typecasten, zou het nuttig kunnen zijn. Misschien is PHP niet zo'n goed voorbeeld omdat het nooit een probleem is om te typecasten, C is waarschijnlijk een beter voorbeeld.

[ Voor 7% gewijzigd door Bergen op 25-05-2008 20:11 ]

[FTL]

Microsoft zelf raadt het volgende aan:
http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx

In 't kort: alles PascalCasing met uitzondering op Parameter en "Public instance field" die beide CamelCasing moeten.

[.oisyn]

Bergen schreef op zondag 25 mei 2008 @ 20:04:
[...]
Dit is naar aanleiding van het zinnetje "(for example “dx” meant “width”)" uit dat artikel neem ik aan. dx (en dy) wordt vaak in grafische routines gebruikt, waar het vaak prima leesbaar is:

code:

public void lineSimple(int x0, int y0, int x1, int y1, Color color)
    {
        int pix = color.getRGB();
        int dx = x1 - x0;
        int dy = y1 - y0;

        raster.setPixel(pix, x0, y0);
        if (dx != 0) {
            float m = (float) dy / (float) dx;
            float b = y0 - m*x0;
            dx = (x1 > x0) ? 1 : -1;
            while (x0 != x1) {
                x0 += dx;
                y0 = Math.round(m*x0 + b);
                raster.setPixel(pix, x0, y0);
            }
        }
    }

(Niet mijn routine.) Als je gewend bent om naar dit soort routines te kijken dan is het zo klaar als een klontje.

Het punt is dat "delta in x" semantisch een andere betekenis heeft als "width", hoewel het dezelfde waarde kan hebben (de breedte van een rechthoek is immers gelijk aan de delta in x tussen de linker- en rechterrand). "dx" past in die routine beter omdat het echt om de delta gaat, en niet zozeer om de daadwerkelijke breedte. Dit komt ook meer uit de wiskunde, waar delta oftewel ∆ een veelgebruikt symbool is voor precies die betekenis.

[ Voor 4% gewijzigd door .oisyn op 25-05-2008 23:06 ]

[Verwijderd]

Bergen schreef op zondag 25 mei 2008 @ 20:04:
Maar bij talen waar de compiler voorkomt dat er in het wilde weg wordt getypecast (zoals Delphi) is het volstrekt overbodig. In talen zoals PHP waar je zonder na te denken mag typecasten, zou het nuttig kunnen zijn.

Delphi staat ook gewoon toe om een willekeurige variabele naar welk type dan ook te typecasten. Dat je dan keihard op je bek gaat als je verkeerd cast is aan de ontwikkelaar, niet aan de compiler.
Maar je kunt niet bv. direct een float in een variabele drukken die is gedefinieerd als string.

[MacWebber]

Het maakt niet uit wat je doet, als je het vooral maar consequent doorvoert. Maak geen zoekplaatje van je source.

[Bergen]

.oisyn schreef op zondag 25 mei 2008 @ 23:03:
[...]

Het punt is dat "delta in x" semantisch een andere betekenis heeft als "width", hoewel het dezelfde waarde kan hebben (de breedte van een rechthoek is immers gelijk aan de delta in x tussen de linker- en rechterrand). "dx" past in die routine beter omdat het echt om de delta gaat, en niet zozeer om de daadwerkelijke breedte. Dit komt ook meer uit de wiskunde, waar delta oftewel ∆ een veelgebruikt symbool is voor precies die betekenis.

Precies. En als ik dat gelinkte artikel lees, krijg ik het vage idee dat de schrijver ervan dat niet weet. Hij noemt het ook de 'd' van 'difference' ipv 'delta':

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.

Een beetje jammer... (De uitleg over delta had ik eerst ook staan, maar heb 't later weer weggeëdit omdat delta soms echt voor als 'breedte' wordt bedoeld in de zin van breedte ipv verschil.)

Verwijderd schreef op zondag 25 mei 2008 @ 23:26:
[...]
Delphi staat ook gewoon toe om een willekeurige variabele naar welk type dan ook te typecasten.

Ja, als je het impliciet aangeeft. Maar als A een string is en B een integer, kun je niet C := A + B doen. Dan tikt de compiler je op je vingers. Je moet dan bijvoorbeeld C := Integer(A) + B doen. En dat kan in (bijvoorbeeld) PHP wel, er wordt zelfs niet eens een notice gegeven! "hoi" + 3 = 3, zonder error, warning of notice. 2 + "8" = 10. Dat bedoelde ik dus. Als een taal zo gemakkelijk met variabelen omgaat heb je sneller last van bugs. In zo'n situatie zóu Hungarian kunnen helpen als geheugensteuntje bij de types.

Maargoed, als je PHP-code zo ondoorzichtig is dat je Hungarian nodig hebt om de types te onthouden doe je sowieso iets verkeerd vind ik...

[ Voor 22% gewijzigd door Bergen op 26-05-2008 07:26 ]

[DrDelete]

Microsoft heeft zijn c# coding guidelines verwoord in "Framework Design Guidelines" (B. Abrams e.a.).

Echter... bij het publiceren van dit werk waren nog veel MS teams niet overgegaan, vandaar dat je in het .NET framework 1.1 bijvoorbeeld via Reflector nog "oude" coding style varianten tegenkomt (m_ private instance vars bijv.). MS kon vanwege deadlines toen niet op tijd de teams zo ver krijgen om de nieuwe coding style door te voeren.

De meeste discussies zijn echter vaak te vinden op private instance variabelen benamingen en niet zo zeer over Hungarian notatie. Dit heeft ook meer te maken met legacy code, waardoor je niet van de een op de andere dag zo maar een nieuwe coding style kunt introduceren. Team blijven dan vaak nog de "oude" notatiewijze aanhouden. Als de coding guidelines dan niet strak worden gecontroleerd, zullen andere teams het kunstje van elkaar afkijken waardoor je op de lange termijn zo veel code in een bepaalde stijl krijgt dat je in je coding guidelines afspraken moet maken over de invoering daarvan: oude code blijft in de oude coding style, nieuwe code/nieuwe projecten gaan over naar de nieuwe guideline. Uiteindelijk gaat het er vooral om, om consequent te blijven en met steekproeven te controleren of er daadwerkelijk aan de guidelines gehouden wordt.

Over het algemeen is het toch verstandig om de MS coding guidelines te volgen: veel ontwikkelaars gaan over richting MS coding guidelines of een sterke afgeleide hiervan. Bij het aannemen van nieuwe ontwikkelaars heb je dan meer kans dat ze al bekend zijn met de coding guidelines, dit scheelt weer inleertijd.

Nog dit:
MS is in de Framework Design Guidelines niet echt duidelijk over de naamgeving van instance variablen uit de Toolbox bijvoorbeeld. Een button die op ee Form wordt gesleept, krijgt default de class type name + een nummer. Zelf haal ik het nummer er af en vervang het nummer door een nuttige naam, zonder dat deze te lang wordt. Deze werkwijze is handig bij het introduceren van nieuwe componenten in de toolbox, waarbij je bij Hungarian notation je elke keer je guideline moet aanpassen bij een nieuw component, hoef je dat niet te doen als je het nummer er af haalt en een nuttige naam er achter zet.