Zitat Zitat von DFYX Beitrag anzeigen
Ich bevorzuge es, mich jeweils an die Konvention der Standardbibliothek der entsprechenden Sprache zu halten. Grade bei Java gibt es von Sun einen sehr ausführlichen Style Guide.
Ja. Allein schon, weil einige Sachen auch nicht gut übertragbar sind. Nehmen wir mal als Extrembeispiel Objective-C: Da hat man Aufrufe, die in etwa so aussehen:
Code (Obj-C):
 
[GrowlApplicationBridge notifyWithTitle:@"Bei Artikel überboten"
							description:title
					   notificationName:@"Outbid"
							   iconData:nil
							   priority:1
							   isSticky:NO
						   clickContext:articleID];
 

Das ist sehr deskriptiv, aber nur deshalb lesbar, weil a) Name und Variablen vermengt sind und b) XCode in der Lage ist, das automatisch sinnvoll einzurücken. Daß man mehrere Zeilen für einen Aufruf hat, ist bei längeren Aufrufen absolut nicht ungewöhnlich.

Aber was, wenn wir solche Namen in C++ benutzen wollen?
Code (C++):
 
GrowlApplicationBridge.notifyWithTitleDescriptionNameIconPriorityStickyContext("Bei Artikel überboten", title, "Outbid", null, 1, false, articleID);
 

Funktioniert gar nicht. Wir haben zwar drin, was die Variablen bedeuten, aber der Funktionsaufruf ist enorm lang und man müßte ohnehin abzählen, welches Wort zu welcher Variable gehört. Das sollte uns doch eher die IDE erklären und nicht der Variablenname. Für sowas gibt es Doxygen und Konsorten und jede IDE, die den Namen verdient, wird einem genau sagen können, welche Variable was ist.


Ich muß aber zugeben, daß ich mich bei einer Sprache absolut nicht daran halte, wie die Funktionen standardmäßig heißen: PHP. In PHP ist camelCase typisch für objektorientierten PHP-Code, während Unterstriche in der Regel in prozeduralen Funktionen zu finden sind. Da ich aber meine Codebase konsistent formatiert haben will, nehme ich überall camelCase.


Zitat Zitat von niR-kun Beitrag anzeigen
Das ist ja genau das Problem. Es wirkt für mich mit der Unterstrich-Konvention uneinheitlich und ist für mich schwer lesbar, weil ich mich an die unter Java typischen Namens-Konvention halte.
Aber auf Hinblick das nicht nur TWS und ich den Code lesen werden sondern auch andere.
"Einheitlich" bedeutet nicht, daß der Stil gleichförmig aussieht; es bedeutet, daß die Codebase einheitlich ist. Eine Variable sollte in Quelldatei A den selben Formatierungsregeln folgen wie in Quelldatei B und C. Denn man WIRD früher oder später mit jemand anderes Code arbeiten müssen und dann ist es einfacher, wenn man sich nicht erst in die Konvention einarbeiten muß.

Solchen Spaß habe ich auf der Arbeit. Ein von meinem Vorgänger geschriebenes Modul hat Datenklassen, die zusammen mit den Werten noch Metadaten für den (schlechten) Formulargenerator mitbringen. Das macht das Befüllen umständlich:
Code (PHP):
 
$customer = new Customer();
 
// falsch
$customer->FirstName = "Walter";
 
// so wie der Code vom Vorgänger es macht
$customer->FirstName->Value = "Walter";
 
// so, wie es korrekt wäre
$customer->FirstName = new stdClass();
$customer->FirstName->Value = "Walter";
 
// Es geht auch ohne das explizite Instanzieren von FirstName, aber dann warnt
// PHP, weil ein Objekt implizit erzeugt wurde. Das ist idR. kein Problem, aber
// wir haben einen eigenen Fehlerhandler, der jedes Mal aufgerufen wird. Bei
// 1.500 Warnungen beim Erstellen der Kundenliste macht das ein fieses
// Performanceloch aus.
 

Wenn ich jetzt also mit Daten aus seinem System arbeite, muß ich daran denken, daß a) camelCase herrscht, aber Unterwerte von Objekten mit PascalCase geschrieben werden und b) Werte Objekte sind, die eine Variable für den eigentlichen Wert beinhalte. Freude.

(Ja, ich weiß, das könnte man mit magischen Gettern und Settern lösen, aber meine erste Handlung als Entwickler war, den Code meines Vorgängers komplett zu deprecaten. Irgendwann wird der ganze Ramsch komplett ersetzt und bis dahin halte ich mich mit strukturellen Änderungen zurück.)