NamensKonventionen / Ungarische Notation

[d0ne]

Hallo,

ich will ein mich mal wieder "weiterbilden" und auf meiner Liste steht als nächstes "VariabelnNamenKonventionen".
Jetzt habe ich mich ein wenig umgesehen und bin auch schon schlauer als zu vor, aber nicht richtig schlau.

Und zwar habe ich die Ungarische Notation und finde die Idee auch an sich nicht schlecht, aber ...
1. liest man auf Wikipedia "[...]den schlechten Ruf der Konvention verantwortlich" und auch ansonsten habe ich irgendwie den Eindruck, dass sie negativ besetzt ist - deshalb, findet ihr die Ungarische Notation (insbesondere für PHP) "gut", bzw. nutzt Sie?
2. Ist die Version auf Wikipedia die "bekannteste/annerkannteste" oder sollte man lieber eine andere nehmen? (Es gibt ja irgendwie "verschiedene Versionen")
3. Gibt es ein OpenSource Projekt was die UN schön umgesetzt hat und man sich das mal "in echt" anschauen kann? (kann, muss aber nicht in PHP sein)
4. Gibt es Alternativen? Welche?

mfg
d0ne

[Manko10]

Die ungarische Notation habe ich zuletzt bei Visual Basic 6.0 eingesetzt. In PHP halte ich sie für ziemlich unhandlich. Variablennamen wie $arrFoo, $intBar, $strFoobar etc. lohnen sich meines Erachtens nach nicht, außerdem ist PHP sowieso schwach getypt. Vor allem bei Objekten wird's aber haarsträubend. Entweder du nennst sie alle &objBla und hast den gesamten Nutzen wieder hinweggeblasen oder du überlegst dir für jedes Interface ein eigenes Präfix. Das ist irgendwie alles andere als praktisch. Ich halte es für wesentlich wichtiger, dass du den Variablen sprechende, also selbsterklärende Namen gibst und dir überlegst, wann du camelCase, wann PascalCase und wann Underscores nutzt. Ich nutze z.B. für Klassennamen PascalCases, für Methoden und Eigenschaften sowie für normale Variablen camelCases. Underscores nutze ich, um bestimmte Namensräume voneinander zu trennen. Es gibt aber auch viele, die gern in Variablen oder Methoden/Funktionen Underscores verwenden, was an sich sogar besser zum Stil der PHP-Core-Funktionen passt. Mir gefallen camelCases aber besser und die neueren nativen PHP.-Klassen nutzen diese auch.
Wie du es machst, ist deine eigene Entscheidung, nur sei konsequent und gib den Variablen Namen, die ihren Inhalt erklären. Eine Variable $i sagt nichts über den Inhalt aus, eine Variable $userAccessGranted schon (eine Variable vom Typ bool, die ein Schalter ist, ob der User rein darf oder nicht).
Viele (mich eingeschlossen) nutzen übrigens strenge Regel für die Benennung von Methoden, um deren Rückgabewerte erkennbar zu machen. Eine Methode getXYZ() gibt etwas zurück, eine Methode setXYZ() setzt einen Wert und fordert mindestens einen Parameter (den zu setzenden Wert). isXYZ() und hasXYZ() geben stets einen boolschen Wert zurück.

[Chriz]

Auf jeden Fall solltest du eben eine Konvention einhalten und zwar strikt, das versuche ich beispielsweise auch bei alten Projekten einzuhalten (früher habe ich protected-Eigenschaften ohne führenden Unterstrich geschrieben, wenn ich jetzt alte Dateien bearbeite, erweitere ich entweder alle Eigenschaften um den führenden Bindestrich oder halte mich an die alte Schreibweise, ein Mischmasch finde ich sehr unordentlich).
Persönlich habe ich nichts handfestes gegen die ungarische Notation, auch wenn ich sie nicht mehr benutze (nikosch aber glaube ich abgewandelt). Ich finde damit wird der Quellcode einen Tick unleserlicher, außerdem beschreibt ein einfacher Variablenname ja häufig schon den Wertetyp ($user, $userId, $users). Gut man könnte streiten was nun in $user steht (String, Objekt, ..?), aber das ergibt sich häufig aus dem Kontext. Zudem - und da wiederspreche ich mir vielleicht in Bezug auf "ergibt sich aus dem Kontext" - ändern sich manchmal Werte auch und Änderungen dann konsequent nachtragen macht kaum einer. Dann steht in $strUser statt dem Usernamen irgendwann doch die User-ID und die ganze Sinnhaftigkeit der Notation ist ausgehebelt.

[nikosch]

nikosch aber glaube ich abgewandelt

Si Senor

Ich benutze - seit Jahren - eine Abwandlung. Das gefällt mir immer noch gut, vor allem wenn in ganz dringenden Projekten mal wieder die Dokumentation zu kurz kommt oder warten muss. Dann sieht man schon in den Methodensignaturen schön die erwarteten Typen. Ich benutze u.a. auch „mixed“, wenn eine Methode mal Strings und Arrays verarbeiten kann o.ä.
Kurz:
Camelcase, erster Kleinbuchtstabe gibt den Typ an:
i - integer
f/d - float, double
s - string
b - bool
o - object
m - mixed
r - rescource
a - array

Denkbar wären noch
c/f - Callback (Function)
c/d - Constant (define)
c - Character

- optisch schön finde ich, dass sich immer ein Camelcase ergibt, und, dass man qua automatisch auch Zählvariablen u.ä. immer sinnvoll benennt, weil bspw. $iI ziemlich dämlich aussähe.
- Schnickanöschen wie as (Array of string) oder dergl. gibts bei mir nicht.
- Ich gebe zu, dass das Prinzip für Objektproperties nicht optimal ist, wenn man bspw. Direktzugriffe verwendet:

$oUser = new User;
$oUser->sName = "Horst"; // bissel häßlich

der Einheitlichkeit halber nutze ich es aber auch dort, weil es in den Methoden wieder Vorteile bietet)
- Große Ausnahme sind bei mir Templates, dort nutze ich nur sprechende Variablen ohne Typ-Suffix.
- übrigens kann man über Tokenizerfunktionen damit supi Dokumentationen generieren.

Änderungen dann konsequent nachtragen macht kaum einer

Netbeans Strg + R

[Flor1an]

Ich nutz ebenfalls die Notationsart wie sie manko beschrieben hat. Das kommt zum einen weil ich sie persönlich am "schönsten" finde und zum anderen da ich mit Zend Framework arbeite und dort der Codingstandard eben entsprechend gilt.

Kannst dir ja mal diesen Teil durchlesen: Zend Framework: Documentation: Zend Framework Coding Standard for PHP - Zend Framework Manual Ich denke solch eine Notationsart ist deshalb besser da sie zum einen verständlich ist wenn man nur kurz den Code anschaut. Manchmal interessiert einen der Typ der Variable gar nicht, ich möchte nur wissen was darin steckt und was der Code macht. Bei der ungarischen Notation müssen wohl die meisten erstmal nachschlagen was denn jetzt wieder die Abkürzungen bedeuten. Da würde ich dann auch eher nikosch's Version verwenden!

Jetzt haben wir dann ja bald alle Mods einmal durch

[d0ne]

So erst mal an alle, danke für die Antworten!

@Manko10,

außerdem ist PHP sowieso schwach getypt

Das ist ein Punkt der IMHO eher für eine solche Notation spricht, weil ich dann direkt sehe, dass $bValidUserName eine boolesche Variable ist, und nur true/false drin steht, der gültige User name steht dann in $sValidUserName. Das hilft auch Variablen nur für einen Zweck zu gebraucht, statt dass in $validUserName wenn der Name gültig ist der Name steht und sonst "false".
Bei den Objecten muss ich dir recht geben da immer ein obj/o vorstehen zu haben ist nicht wirklich hübsch - mal gucken, wie ich das mache.
Ach, und Getter/Setter benutze ich so wie du beschrieben hast.

@Chriz,
klar einerseits hast du Recht, aber ich habe bisher gar keine Konvention benutzt. Und ich glaube nicht, dass ich jetzt erstmal so weiter machen kann, wie bisher und dann "plötzlich" bei einem neuen Projekt mich an eine Konvention halten kann.

@nikosch, ja ich glaube ich werde so etwas in deine Richtung machen. Aber, wie schon geschrieben, werde ich mir das mit dem o für Object noch mal überlegen. Weil wenn man richtig OOP programmiert hat man ja irgendwann überall "o"s ... Vll. mache ich es so, dass eine $User ("ohne alles") ein Object ist und alles andere eben s/b/i ...

@Flor1an, den "Zend Framework Coding Standard" werde ich mir auf jeden Fall mal ansehen, vll. steht 'was hilfreiches 'drin!
Und das Problem mit dem "nachschlagen müssen" sehe ich auch, besonders da ja noch "verschiedene Versionen" im Umlauf sind.

mfg
d0ne

[mermshaus]

Ich halte Notationsarten, die ein Typenpräfix verwenden, bei ansonsten sauberem Programmier- und Kommentierstil für nicht wirklich notwendig, da der Informationsgewinn sehr gering ist.

Einige "Faustregeln":

- Keine übertrieben langen Funktionen/Methoden.
- Saubere Initialisierung (offenbart den Typ -- Edit: okay, nicht zwingend ) der verwendeten Variablen möglichst zu Beginn des Geltungsbereichs.
- Durchgängig phpDoc-Kommentare für Membervariablen und Methodenparameter/-rückgaben.
- Type Hinting wann immer möglich.

[Manko10]

Das ist ein Punkt der IMHO eher für eine solche Notation spricht, weil ich dann direkt sehe, dass $bValidUserName eine boolesche Variable ist, und nur true/false drin steht, der gültige User name steht dann in $sValidUserName. Das hilft auch Variablen nur für einen Zweck zu gebraucht, statt dass in $validUserName wenn der Name gültig ist der Name steht und sonst "false".
Bei den Objecten muss ich dir recht geben da immer ein obj/o vorstehen zu haben ist nicht wirklich hübsch - mal gucken, wie ich das mache.

Sehe ich genau gegenteilig. Die Notation soll eher dabei helfen, bei festen Typen diesen zu erkennen. Bei PHP halte ich das nicht für notwendig und es gibt auch durchaus Fälle, in denen man eine schwache Typisierung durchaus legitim und sinnvoll nutzen kann, wobei diese Präfixe dann sofort ad absurdum geführt würden. Wie Flor1an halte ich sprechende Namen für weitaus wichtiger. Das nimmt zudem Komplexität und ehrlich gesagt finde ich, dass die Präfixe den Code auf Dauer unübersichtlich machen, weil es immer ein bisschen länger dauert, den Namen zu lesen und zu verstehen, wenn davor noch ein Buchstabe steht. Um es mal an einem Text zu demonstrieren:

iDies ist ein bText, der Aufschluss darüber sgeben soll, ob sich typbedingte mPräfixe negativ auf die Lesbar- und Erfassbarkeit von rTexten auswirken können.

vs.

Dies ist ein Text, der Aufschluss darüber geben soll, ob sich typbedingte Präfixe negativ auf die Lesbar- und Erfassbarkeit von Texten auswirken können.

Welcher Text ist schneller erfassbar? Selbiges lässt sich auch auf Quellcode übertragen:

$mUser = MyDataBase::getUser($iUserId);
if ($mUser->isAuthorized('read') && $mUser->getAdminStatus() == $iStatusId) {
    $sOutputText   = $mUser->getPreferences();
    $sOutputTeaser = substr($sOutputText, 0, 20);
}

$sCompleteOutput = isset($sOutputText) ? $sOutputTeaser . "\r\n\r\n" . $sOutputText : 'No output'; 

vs.

$user = MyDataBase::getUser($userId);
if ($user->isAuthorized('read') && $user->getAdminStatus() == $statusId) {
    $outputText   = $user->getPreferences();
    $outputTeaser = substr($outputText, 0, 20);
}

$completeOutput = isset($outputText) ? $outputTeaser . "\r\n\r\n" . $outputText : 'No output'; 

Beim ersten Code dauert es deutlich länger, bis man die Variablennamen erfasst hat, während dies beim zweiten deutlich schneller geht, der Typ der Variablen aber dennoch ziemlich klar sein sollte. Stell dir vor, was passierte, wenn man jetzt noch dreibuchstabige Präfixe verwendete.
Ich persönlich sehe für den Fall PHP keinen Mehrwert der ungarischen Notation und halte sie eher für hinderlich.

[d0ne]

Also die ungarischen Notation werde ich auf jeden Fall erstmal nicht benutzen.
Ich bin mir aber nicht sicher sicher, ob ich jetzt gar keine Präfixe nutzen sollte, oder aber b/s/i/...

Ich die nächste Zeit beim programmieren einfach mal beides (am selben Code) testen und dann entscheiden, was mir besser gefällt.