carom schrieb:
Bei der ==0 Sache gebe ich dir völlig Recht, aber das zitierte gilt trotzdem als schlechter Stil und macht man in der Regel auch nicht so. Davon abgesehen ist es fragwürdig, nur aufgrund der Bennenung von Variablen gleich eine andere Programmstruktur zu wählen (isOk vs OK).
Es wird nicht die Programmstruktur geändert, sondern nur ein ==True angehängt zur besseren Lesbarkeit. Falls die Variable schon mit Is oder Has anfängt, so ist das unnötig, da schon aus dem Namen hervor geht, dass es sich um einen Boolean handelt.
Microsoft hat für .NET eine kleine Hilfe mit Designrichtlinien für Bibliotheken verwendet, wo auch die Namensgebung hineinspielt. Dort sind einige wichtige Punkte drin, die man für seine Programme übernehmen kann (muss nicht nur .NET sein, geht für Java genauso). Man muss nicht alles exakt befolgen, aber manche Dinge sind für saubere Programmierung absolut notwendig z.B. dass man bei Properties im Getter keine Schreibzugriffe macht:
http://msdn.microsoft.com/en-us/library/ms229042.aspx
Kampfgnom schrieb:
Ich muss manchmal mehrere Dinge zugleich zurückgeben. z.B. einen String und Gleichzeitig ein File. Das lässt sich nunmal recht einfach über solche Klasse lösen.
Außerdem können dann FileReturnValue zugleich auch BooleanReturnValue sein, sodass ich z.B. von einem FileChooser zurückgeben kann, welche Datei ausgewählt wurde, aber zugleich auch, dass sie nicht gespeichert werden soll.
So kann ich mir die zuletzt gewählte Datei merken und beim nächsten Speichern Dialog direkt wieder eintragen.
Ich glaube da gehst du überhaupt in eine falsche Richtung. Es hat schon seinen Sinn, dass man nur einen Wert zurückgeben kann. Eine Klasse hat immer einen Zweck und ist nicht nur eine Ansammlung wilder Werte. Wenn du mehr als einen Wert zurückgeben willst, dann musst du das anders lösen.
Microsoft hat das mit den FileDialogen so gelöst, dass alle Dialog (Basisklasse) einen Rückgabewert zurückliefern, nämlich OK, Cancel etc.
Die ausgewählte Datei kann dann je nach Dialog über die Properties erfolgen z.B. mit FileDialog.FileName. In deinem Fall würde kein String zurückgegeben werden, sondern in deiner Klasse als Klassenvariable gesetzt werden. Alle diese Variablen haben dann einen sprechenden Namen. Ein Außenstehender hat keine Ahnung, welche Bedeutung "BooleanValue" haben soll.
Jetzt ist es halt folgendes:
Code:
FileReturnValue result = Main.getUserInterface().showNewFileDialog();
if(!result.booleanValue()) { //the user did not enter a filename (e.g. clicked cancel)
LOG.trace("User did not enter a new filename. Aborting.");
return null;
}
File filename = result.fileValue();
Main.setLastChosenDir(filename.getParentFile());
SheepShaver schrieb:
Es wird das Ergebnis des boolschen Vergleichs zurückgegeben, kein int.
Klar wird das richtige zurück gegeben und wenn man unter Berücksichtigung aller Vorrangregeln die Zeile genau durchdenkt, wird man das auch feststellen, aber es ist nicht sofort für jeden erkennbar und stört des Lesefluss. Das zeigen die Posts oben. Ein guter Code ist keiner, der alles in einer Zeile verpackt. Mehr Code ist oft übersichtlicher, als weniger Code.
SheepShaver schrieb:
Dein Beispiel wäre unter Java garnicht realisierbar, da der Compiler in der if-Abfrage nur boolsche Ausdrücke zulässt.
Ja und das tut so gut wie jede moderne Programmiersprache. Das ist nur dieser C Unfug, dass man mit syntaktisch falschen Sachen einfach weiterarbeitet und einfach irgendetwas zurückgegeben wird, weil es für die Compilerbauer in den 70er Jahren einfach so praktisch war und sich ein paar Leute gut fühlen, wenn sie kilometerlange Normen über die Behandlung von Vorrangregeln und Syntax Sonderfällen erstellen, wie diese vom Compiler zu behandeln sind, die ein geistig gesunder Mensch sowieso nie ernsthaft verwenden würde (Stichwort i++ vs. ++i).
Ein Boolean ist entweder wahr oder falsch, aber nicht 0,1,-1, der Pointer auf irgendeinen Speicherbereich etc. Wie das intern gespeichert wird, ist völlig irrelevant.
Wenn val nicht false ist, dann ist es true. Ja richtig, und? Wo liegt das Problem?
