About a code. Code Style Frage.

happystudent

Könnte man machen, aber ich finde

Window w(VideoMode(800, 600), "SFML window");

hat halt auch was.

Ich hab mir deine Argumente durchgelesen und kann diese nachvollziehen (ist ja letztendlich eh alles Geschmacksache).

Aber mMn muss man sich ja eh immer die Deklaration anschauen bevor man (irgend)eine Funktion benutzt. Allein schon damit man weiß ob gewisse Parameter (const) Referenzen sind oder nicht (kann man ja am Aufruf nicht erkennen). Nur weil es jemand falsch machen könnte der keine Ahnung hat und sich nichtmal die Deklaration der Funktionen anschaut die er benutzt finde ich ein bisschen übervorsichtig

Deswegen seh ich das mit default Parametern nicht so dramatisch, mir ist übersichtlicher Code wichtiger als alles super explizit hinzuschreiben. Das lenkt dann nur vom wesentlichen ab.

TyRoXx

happystudent schrieb:

Aber mMn muss man sich ja eh immer die Deklaration anschauen bevor man (irgend)eine Funktion benutzt. Allein schon damit man weiß ob gewisse Parameter (const) Referenzen sind oder nicht (kann man ja am Aufruf nicht erkennen).

Beim Benutzen ja. Bei existierendem Code (wie dem SFML-Tutorial) nicht. Aus dem Aufruf kann man fast alles ableiten, was zum Verständnis notwendig ist. Nicht-const-Referenzen können das in meinem Beispiel nicht sein, weil das gar nicht übersetzbar wäre - unter der berechtigten Annahme, dass da keine globalen Variablen übergeben werden.

happystudent schrieb:

Deswegen seh ich das mit default Parametern nicht so dramatisch, mir ist übersichtlicher Code wichtiger als alles super explizit hinzuschreiben. Das lenkt dann nur vom wesentlichen ab.

Alle Argumente sind für mich wesentlich, unabhängig von subjektiven Defaults, die andere gewählt haben. Wenn ein Argument unwesentlich ist, kann man auch einfach den Parameter löschen.

happystudent schrieb:

Nur weil es jemand falsch machen könnte der keine Ahnung hat und sich nichtmal die Deklaration der Funktionen anschaut die er benutzt finde ich ein bisschen übervorsichtig

Code, für dessen Verständnis man weniger nachschlagen muss, ist tendentiell besser, oder nicht?

happystudent

TyRoXx schrieb:

Wenn ein Argument unwesentlich ist, kann man auch einfach den Parameter löschen.

Vielleicht nicht unwesentlich, aber "weniger" wesentlich.

Ich finde das halt gerade für Anfänger eine schöne Sache. In Matlab zum Beispiel ist alles voll von default Werten. Das macht es halt einfach extrem Einsteiger- und Benutzerfreundlich, weil ich einfach (zum Beispiel) einem Solver eine Kostenfunktion übergeben kann und in 99% der Fälle sind die default Einstellungen absolut ausreichend um das Problem zu lösen. Falls doch nicht, kann ich immer noch tiefer in die Materie einsteigen.

TyRoXx schrieb:

Alle Argumente sind für mich wesentlich, unabhängig von subjektiven Defaults, die andere gewählt haben.

Im Gegenteil, meiner Meinung nach.

Ich finde es sogar wertvoll und gut wenn mir von einem Experten, der sich ausführlich mit dem jeweiligen Problem auseinandergesetzt hat, ein vermutlich sinnvoller Wert vorgeschlagen wird.

Das ist auch eine Art der Dokumentation und zusätzliche Information/Mehrwert der oft auf viel Erfahrung seitens des Entwicklers basiert. Gerade bei irgendwelchen (nicht direkt ersichtlichen) numerischen Konfigurationsparametern. Ignorieren kann ich den Wert ja immer noch.

hustbaer

TyRoXx schrieb:

happystudent schrieb:

Nur weil es jemand falsch machen könnte der keine Ahnung hat und sich nichtmal die Deklaration der Funktionen anschaut die er benutzt finde ich ein bisschen übervorsichtig

Code, für dessen Verständnis man weniger nachschlagen muss, ist tendentiell besser, oder nicht?

Nein, nicht immer.
Was ich auch schon geschrieben habe, was du einfach ignoriert hast.
Weil du mich lieber über Dinge "belehrst" (wie z.B. schlechtere Performance bei optional<string>), um die es hier überhaupt nicht geht.
Was mir genau so auf den Sack geht wie (EDIT: dich) der "Ton" den ich dann anschlage wenn mir jemand auf den Sack geht.

Verstehst du jetzt vielleicht warum ich hier (ganz klar, zugegeben!) "unsachlich" reagiert habe?

Und was Default-Werte angeht (allgemein, unabhängig davon ob es Parameter sind oder Properties oder was auch immer): dass die extrem wichtig sind sollte klar sein.
Man muss sich bloss mal angucken wie viele Properties ein durchschnittliches Widget eines modernen GUI Frameworks hat (z.B. WCF). Klar, für die meisten dieser Properties gibt es keine Ctor-Parameter, aber Default-Werte haben sie dennoch, und ohne solche Default-Werte wären die entsprechenden GUI Frameworks unbedienbar.
Genau so sieht es bei Web-Service Stacks aus bzw. allgemein einfach vielen Libraries die flexibel einsetzbar sind.

Und zu Funktions-Parametern besteht da kein wesentlicher Unterschied.

Bei Sprachen die optionale Named-Parameters unterstützen sind Default-Werte für Parameter mMn. wirklich sinnlos. Lieber nen optionalen Parameter machen -- dann muss der Default-Wert nicht bei der Übersetzung bekannt sein.
Bei Sprachen die keine Named-Parameters haben sind Default-Werte für Parameter aber einfach ein nettes convenience Feature, das sowohl dem Library-Programmer als auch dem User-Programmer Arbeit abnimmt.

Was die erwähnte Netzwerk-Puffergrösse angeht: den User-Programmer interessiert das normalerweise nicht, und es soll ihn auch nicht interessieren. Er soll den Wert gar nicht angeben, so lange er nicht genau weiss welcher Wert da im Allgemeinen (oder speziell für ihn) Sinn macht. Und ohne sich ernsthaft mit der Materie auseinanderzusetzen kann er das nie so gut wissen wie der Library-Programmer. Der sich hoffentlich etwas damit beschäftigt hat, und nicht einfach eine willkürliche Zahl hingeschrieben hat.
Mein einziger Kritikpunkt wäre dabei: ich würde nicht fix 8000 angeben, sondern einen "null" Wert als Default übergeben, der für "nimm das was Sinn macht" steht. Also z.B. -1 , boost::none oder null - was auch immer in der jeweiligen Sprache zur Verfügung steht.

Weil man nicht ausschliessen kann dass für verschiedene Systeme verschiedene Default-Werte sinnvoll sind.

=> Den User-Programmer zu zwingen alle möglichen Parameter anzugeben, von denen er vermutlich die Hälfte nicht versteht/nicht einschätzen kann, verbessert gar nix. Sondern schadet wohl meistens nur.
Und ein relativ einfaches Mittel um zu ermöglichen dass nicht alles angegeben werden muss, sind eben Default-Werte für Parameter.

Lieber wären mir Named-Parameters, aber so lange es die nicht gibt, verwende ich gern Default-Werte.

ps: Ein grosser Vorteil von Default-Werten für Parameter wie sie C++ umsetzt: man muss nix dokumentieren, da man den Wert jederzeit im Header-File nachsehen kann. Der Nachteil davon ist klar (Default-Wert wird bei der übersetzung ins Client-Programm reincompiliert). Der Nachteil von "Anfänger-Funktionen" (egal ob Overload oder mit "eigenem" Namen) ist aber: wenn man keine Doku dazu schreibt, und der User-Programmer den Source nicht vorliegen hat, dann hat er keine einfache Möglichkeit rauszubekommen was die "Anfänger-Funktionen" für Werte verwenden. Und das ist jetzt nicht dahererfunden - die (ansonsten sehr gute!) MSDN Doku enthält etliche Einträge zu solchen "Anfänger-Funktionen", wo nicht dabeisteht was für Werte für die Parameter die "sie nicht haben" verwendet werden.
(Und auch davon abgesehen finde ich es viel mühsamer in der Doku nachzuschlagen als einfach zu gucken was der Intellisense mir anzeigt bzw. Alt+G zu drücken um zur Deklaration im Header-File zu springen. Speziell bei C++ wo es nicht üblich ist dass Doku mitgeliefert wird die ins Studio mit eingebunden wird, so dass es die Doku zur Funktion/Klasse beim Drücken von F1 findet und anzeigt.)

tntnet

TyRoXx schrieb:

tntnet schrieb:

Das ganze macht den Code lesbarer, da ich nicht bei jedem Methodenaufruf jedes Detail angeben muss, sondern nur die relevanten Parameter.

Eigentlich macht es den Code weniger lesbar, weil ich nach den Werten herumsuchen muss, die mich interessieren. Was du meinst, ist leichter schreibbar ohne nachzudenken.

Es geht doch darum, Werte nicht explizit erwähnen zu müssen, die eben nicht interessieren. Es sind Werte, die für den Verständnis des Codes eben nicht wichtig sind. Je mehr Informationen - und sei es "DefaultBufferSize" - vorhanden ist, desto mehr wird der eigentliche Sinn versteckt.

happystudent hat auch ein sehr gutes Beispiel. Ein Fenster in einer GUI Applikation ist ein Fenster. Und wenn ich ein Fenster öffne, welches nichts besonderes hat, dann möchte ich einfach sagen: "öffne ein Fenster" und nicht: "öffne ein Fenster wobei der Parameter A Standard sein soll und Parameter B auch und C erst recht und D wählst Du auch wie immer und E ist eigentlich hier sogar völlig egal". Wenn ich in dem Fenster noch einen Button platziere, wobei der Rahmen Standard sein soll und die Hintergrundfarbe auch und der Font soll das sein wie immer und ich will auch keine besonderen Attribute wie z. B. "deaktiviert" angeben, dann wird das richtig unübersichtlich. In dem ganzen Wust dann noch zu erkennen, dass eigentlich nur ein Fenster mit einem Button geöffnet wird, ist schon nicht mehr so einfach.