bool value = GetMouseVisible();
SetMouseVisible(value);

oder

bool value = MouseVisible();
MouseVisible(value);

Was spricht gegen die zweite Variante, in der die Funktion überladen wird?

Was spricht gegen die zweite Variante, in der die Funktion überladen wird?

Naja, bei Get und Set ist meiner Ansicht nach schneller ersichtlich, was getan wird. Aber zum Beispiel die Standardbibliothek handhabt viele Memberfunktionen auch überladen (z.B. std::stringstream::str() ). Ich würds jedoch anders machen.

joomoo schrieb:

Ich programmiere eine Library, die aus globalen Funktionen besteht.

Und das in C++?

Willst du nichts Objektorientiertes machen?

joomoo schrieb:

Was spricht gegen die zweite Variante, in der die Funktion überladen wird?

Naja, bei Get und Set ist meiner Ansicht nach schneller ersichtlich, was getan wird. Aber zum Beispiel die Standardbibliothek handhabt viele Memberfunktionen auch überladen (z.B. str() ). Ich würds jedoch anders machen.

Hm ... stimmt. Ist wohl wirklich verständlicher, auch wenn's zu längeren Funktionsnamen führt.

Nexus schrieb:

joomoo schrieb:

Ich programmiere eine Library, die aus globalen Funktionen besteht.

Und das in C++?

Willst du nicht Objektorientiertes machen?

Wär natürlich besser, aber die Library ist für totale Anfänger und soll deswegen solche Themen erstmal außen vor lassen.

Was spricht gegen die zweite Variante, in der die Funktion überladen wird?

eigentlich nichts.
zu überlegen ist nur, welche version den benutzer weniger nervt.

falls es sich um http://watteimdocht.de/jngl/wiki/Reference dreht, möchte ich anmerken, daß die meisten funktionsnamen als tuwörter stehen, wie

void ShowWindow(const std::string& title, int width, int heigt, bool fullscreen = false); 
void HideWindow();

davon weichst du ab bei

void Running(); //bool

statt

void IsRunning(); //bool

und ganz abweichend ist

bool Button(const std::string& texture, double xposition, double yposition, const std::string& mouseover)?

ich empfehle, alle Funktionen als tuwörter zu schreiben, also die erste version, und zwar konsequent. aber dafür gibt es keinen technischen grund, es ist nur geschmackssache.

joomoo schrieb:

Was spricht gegen die zweite Variante, in der die Funktion überladen wird?

eigentlich nichts.
zu überlegen ist nur, welche version den benutzer weniger nervt.

falls es sich um http://watteimdocht.de/jngl/wiki/Reference dreht, möchte ich anmerken, daß die meisten funktionsnamen als tuwörter stehen, wie

void ShowWindow(const std::string& title, int width, int heigt, bool fullscreen = false); 
void HideWindow();

davon weichst du ab bei

void Running()

statt

void IsRunning()

und ganz abweichend ist

bool Button(const std::string& texture, double xposition, double yposition, const std::string& mouseover)?

ich empfehle, alle Funktionen als tuwörter zu schreiben, also die erste version, und zwar konsequent. aber dafür gibt es keinen technischen grund, es ist nur geschmackssache.

Da hast du recht, danke. Okay ich mach mich gleich mal an die Arbeit ...

edit: Sollten auch Funktion wie "MouseDown" mit "Is" anfangen?

edit: Sollten auch Funktion wie "MouseDown" mit "Is" anfangen?

Wiederum Geschmackssache.

Ich finde, bei IsMouseDown ist klarer, dass ein boolscher Zustand ("is") abgefragt wird. MouseDown oder MyMouseDown würde ich eher eine Variable nennen, z.B.

bool MouseDown = IsMouseDown();

Ich programmiere eine Library, die aus globalen Funktionen besteht.

Dafür gibt es sogar einen Namen: Nennt sich C-Library

Sollten auch Funktion wie "MouseDown" mit "Is" anfangen?

Klar.
Das war noch einfach.
Der Spaß beginnt so richtig, wenn Du überlegen mußt, ob es GetFPS, CalcFPS, CalculateFPS, ReadFPS oder noch anders heißen soll. :xmas1:

joomoo schrieb:

Sollten auch Funktion wie "MouseDown" mit "Is" anfangen?

Klar.
Das war noch einfach.
Der Spaß beginnt so richtig, wenn Du überlegen mußt, ob es GetFPS, CalcFPS, CalculateFPS, ReadFPS oder noch anders heißen soll. :xmas1:

Da hast du Recht, echt nicht einfach sowas.

Noch eine Frage: Wenn ich eine Funktion habe, die IsMouseDown heißt, dann sollte es ja auch eigentlich auch IsMouseVisible heißen. Also so:

bool value = IsMouseVisible();
SetMouseVisible(value);

Wär's so am besten?

bool value = IsMouseVisible();
SetMouseVisible(bool visible);

Wär's so am besten?

kann sein. oder Get oder Read oder Calc oder noch was anderes? ich denke, ich würde Is nehmen.

manche bevorzugen vielleicht auch

bool IsMouseVisible();
void SetMouseVisibility(bool);

oder

bool GetMouseVisibility();
void SetMouseVisibility(bool);

oder

bool IsMouseVisible();
void ShowMouse();
void HideMouse();

vielleicht will man auch besonders nett sein und baut überflüssige funktionen

bool IsMouseVisible();
void SetMouseVisibility(bool);
inline void ShowMouse()
{
  SetMouseVisibility(true);
}
inline void HideMouse()
{
  SetMouseVisibility(false);
}

echt schwierig. und leider unmöglich im voraus perfekt zu machen.

Get/Set haben halt den Vorteil, dass man sie eigentlich überall benutzen kann. Das ist mit "is" nicht immer so.

Ich kann, wie volkard schon gesagt hat sagen "IsVisible", oder "GetVisibility". Das Problem mit "Is" ist nur, dass man es nicht überall verwenden kann, da es einen boolschen Wert halt schon impliziert. Entweder ist es Visible, oder nicht. Ansonsten müsste man "IsSize0 , IsSize1 , IsSize2 usw" schreiben. (Wenn man konsequent sein will.) Natürlich kann man da Ausnahmen machen, dass boolsche Werte mit Is Anfangen. Das nächste Problem damit wäre dann nur, wenn man die Visibility auch 50% haben kann. Mit Get ist das (namenstechnisch) kein Problem, aber mit Is..

Das Problem mit "Is" ist nur, dass man es nicht überall verwenden kann, da es einen boolschen Wert halt schon impliziert. Entweder ist es Visible, oder nicht.

das ist ein vorteil und kein nachteil, würde ich meinen.
ich brauche mir nämlich nicht zu merken, welchen typ IsVisible zurückgibt.
Es soll einfach logisch, nachvollziehbar und möglichst intuitiv zu nutzen sein.

drakon schrieb:

Das Problem mit "Is" ist nur, dass man es nicht überall verwenden kann, da es einen boolschen Wert halt schon impliziert. Entweder ist es Visible, oder nicht.

das ist ein vorteil und kein nachteil, würde ich meinen.
ich brauche mir nämlich nicht zu merken, welchen typ IsVisible zurückgibt.
Es soll einfach logisch, nachvollziehbar und möglichst intuitiv zu nutzen sein.

Ja, klar, aber ich meine, wenn man konsequent sein will mit der Namensgebung (im Sinne von Is oder Get), dann geht das mit Is nicht wirklich mit Get jedoch schon.
(impliziert dann aber (leider), dass es mehr, als 2 Zustände gibt, was wiederum auch nicht unbedingt schlecht sein muss).

Ich persönlich würde da auch eher zu einer gemischten Varianten tendieren mit klar geregelten Ausnahmen.

Ja, klar, aber ich meine, wenn man konsequent sein will mit der Namensgebung (im Sinne von Is oder Get), dann geht das mit Is nicht wirklich mit Get jedoch schon.

Diesen Wunsch kann ich nicht nachvollziehen. Wozu gleichartige Namensgebung? Müßte ich dann nicht genau in diesem Sinne auch das Get weglassen und nur Visible() schreiben?

drakon schrieb:

Ja, klar, aber ich meine, wenn man konsequent sein will mit der Namensgebung (im Sinne von Is oder Get), dann geht das mit Is nicht wirklich mit Get jedoch schon.

Diesen Wunsch kann ich nicht nachvollziehen. Wozu gleichartige Namensgebung? Müßte ich dann nicht genau in diesem Sinne auch das Get weglassen und nur Visible() schreiben?

Falls man das will. Kann ja durchaus sein. Ich persönlich möchte immer alles nach dem gleichen Schema haben und jede Ausnahme nervt mich. (Nichtsdestotrotz würde ich hier auch Ausnahmen machen, aber das muss ja nicht jeder so wollen).

Ist das einfach so eine fixe Idee von dir? (Ich frage nur, das hab ich nämlich selber oft).

Wichtig ist - wie du schon sagtest - Konsistenz. Aber die geht ja durch Verwenden von Is und Get je nach Rückgabetyp nicht verloren...

Mouse m;
m.Visible() = true;
if (m.Visible())
// diesunddas

also einfach eine referenz zurückgeben, mit einer helferklasse
geht das (eben ausprobiert)

kannst ja auch einfach nur Visible() nennen, getter und setter in einem

Dann hat man wieder das Problem, dass man nicht sofort sieht, was getan wird. Stell dir mal einen komplexeren Ausdruck vor. Da kann es schnell zu unvorhergesehenen Seiteneffekten kommen, weil man aus Versehen das Objekt verändert.

Mouse m;
m.Visible() = true;
if (m.Visible() = false)
// diesunddas

ich schlage vor:

Mouse m;
m.Visible() = true;
if (m.Visible() = false)
// diesunddas

Einer Funktion einen Wert zuweisen ist hässlich und fehleranfällig (siehe dein falsches if).