Funktionsname: Enable/Disable

set

Bin für setIrgendwas(bool enable);

Du kannst das C++ vielleicht riechen.
Ich sehe es hier noch nicht.


Aber wo du die OOP schon ins Spiel bringst:
https://de.wikipedia.org/wiki/Zugriffsfunktion
Da ist es absolut üblich setxxx() und getxxx() zu verwenden.
oder auch mal isxxx()

KA, welche Konstruktion dir vorschwebt...
Aber bei mir beginnen Setter, und auch alles was man als solches 
betrachten kann, eben mit set.

Walter T. schrieb:
> Funktion

Wilhelm M. schrieb:
> Methode

!?!

So eine Frage macht nur im Gesamtkontext Sinn. Kannst Du mit XXX noch 
etwas anderes machen? Parametrieren, Diagnose, Abfragen, ... . Wenn es 
beispielsweise nur an/aus gemacht werden kann (und sonst nichts), dann 
reicht auch XXX(bool on). Erst wenn es andere Aktionen gibt bemisst sich 
der Name (und seine Geschwätzigkeit) daran, das alles gut und eindeutig 
unterscheiden zu können.

StatusLed(bool on) reicht völlig aus, wenn es nichts anderes dazu gibt.

naja ein Schalter nennt man switch,
schaltet man etwas physisches ist on/off okay,
(fernseher an)
schaltet man nur teile ab (fernseher an, ton aus)
ist enable/disable die korektere bezeichnung.

ich würde also

1

void XXX_enable(bool on)

2

{...}

3

//und noch n overload dazupacken

4

void XXX_enable()

5

{

6

   XXX_enable(true);

7

}

8

//sowie ein disable, weil man ja bequem ist

9

void XXX_disable()

10

{

11

   XXX_enable(false);

12

}

du kannst aber auch ohne overload
den Namen anders gestalten zB

1

void XXX_switch(bool enable)

2

{...}

3

//und dann trotzdem mit enable

4

void XXX_enable()

5

{

6

   XXX_switch(true);

7

}

8

//und disable arbeiten wenn du magst

9

void XXX_disable()

10

{

11

   XXX_switch(false);

12

}

eine funktion enableDisable zu nennen halte ich für falsch,
das verwirrt nur, weil man die "Richtung" des Aufrufparameters nichtmehr 
so schnell erkennt (schaltet true nun ein oder aus?)

Im Grunde aber kannst Du die Funktion auch "Reinhold" nennen wenn Du das 
nur ordentlich dokumentierst (ist nicht schön, aber es regnet auch keine 
Fische falls Du es doch tust)

> XXX_enable(true);
Hier ist die Semantik klar, irgendein Flag wird auf true gesetzt.

> XXX_enable(false);
Hier lese ich, dass das Flag nicht angefasst wird.
Es könnte auch meinen, dass das Flag auf false gesetzt wird.

setXxxFlag(true);
setXxxFlag(false)
getXxxFlag();
lassen keine Zweifel aufkommen

Arduino Fanboy D. schrieb:
> Hier lese ich, dass das Flag nicht angefasst wird.

Eine Funktion aufrufen die Absichtlich genau nichts tut?
Haste das schonmal gemacht? Ich in 30 Jahren nicht

Arduino Fanboy D. schrieb:
> Hier ist die Semantik klar, irgendein Flag wird auf true gesetzt.

Woher weisst Du, daß Walter überhaupt ein flag setzen will?
ich seh nirgendwo eins, ich seh auch nicht wo eins abgefragt werden 
würde...
hätte ja auch ein toggle pin sein können um ne LED anzuknipsen.
(völlig ohne flags)

Aber ja, klar setzt er ein flag wäre "set" eine logische 
Funktionsnamensergänzung.
und wollte er es nachher irgendwann abfragen ist "get" ebenso hilfreich.
Aber ernsthafterweise bei -wie wir nun wissen- nur vier funktionen,
können die auch Dieter, Klaus, Bärbel und Renate heissen ohne wirklich 
verwirrung zu stiften ;)

Walter T. schrieb:
> void DRV0_deinit();
Walter, deinit?
nene das wort gibt's nicht
uninitialize gäb's wenn es nur um die Rückgängigmachung der 
initialisierung geht. (quasi reset, no init)
ansonsten sind terminate oder destroy (zur einleitung des Abbruchs) 
vermutlich die konstruktnamen die Du suchst.

Destroy verwende ich nur zusammen mit create. Bei init nenn ich das 
immer cleanup.

Nenne sie

1

 void kuhliefumdenTeich()

Probleme haben manche Leut - die hätt ich ich auch gern.

Ach, die nervigen Flag-Parameter... Letztendlich sind sie mehr schlecht 
als recht:

    https://martinfowler.com/bliki/FlagArgument.html


Und wenn man (oft) gezwungen ist, irgendwo zu schreiben:

1

    if (some_condition)

2

    {

3

        enableXYZ();

4

    }

5

    else

6

    {

7

        disableXYZ();

8

    }

...sollte man gleich weiter machen: Warum muss man überhaupt mit einer 
IF-Abfrage unterscheiden, ob irgendetwas freigegeben werden soll oder 
nicht? Kann man das nicht schon viel früher wissen und dieses IF 
entsorgen?


Alternativ kann man auch das nichtssagende True/False in etwas 
sinnvolles umbenennen:

    https://www.codereadability.com/boolean-arguments/



Man könnte sich noch an einem anderem Thema abarbeiten: Warum überhaupt 
die Namen "enable/disable" verwenden? Man liest es zwar millionenfach, 
doch sind diese beiden Begriffe viel zu generisch:

  - Eine LED kann hell oder dunkel sein.
  - Ein Motor kann gestoppt sein oder sich drehen, womöglich ich zwei 
Richtungen.
  - Eine Datenübertragung kann gestartet und gestoppt werden.

etc.


Übrigens, sid schrieb:

1

> void XXX_enable(bool on)

2

> {...}

3

> //und noch n overload dazupacken

4

> void XXX_enable()

5

> {

6

>    XXX_enable(true);

7

> }

8

> //sowie ein disable, weil man ja bequem ist

9

> void XXX_disable()

10

> {

11

>    XXX_enable(false);

12

> }

...ist ziemlich übel, auch wenn es in so vielen (C++)-Büchern drin 
steht: Nun gibt es für das "Enable" und "Disable" plötzlich jeweils zwei 
Möglichkeiten, die (hoffentlich) jeweils das selbe tun:

1

    // Freigabe

2

    XXX_enable();

3

    XXX_enable(true);

4

5

    // Sperre

6

    XXX_disable();

7

    XXX_enable(false),

Gar nicht gut! Wie soll sich der Programmierer entscheiden? Welche der 
beiden Methoden ist jeweils die bessere und sollte bevorzugt werden? Und 
warum? Usw.

Ach, vergessen: Persönlich würde ich statt:

1

    XXX_enable();

immer:

1

    enableXXX();  // oder auch enable_XXX();

vorziehen. Das ist halbwegs normal lesbares Englisch.

Experte schrieb:
> Gar nicht gut! Wie soll sich der Programmierer entscheiden? Welche der
> beiden Methoden ist jeweils die bessere und sollte bevorzugt werden? Und
> warum? Usw.
Du bist mir ja n Experte ... tse

Naja wie Du siehst tun sie dasselbe (exakt dasselbe ohne chance es nicht 
zu tun)
zu bevorzugen ist klar xxx_switch(bool) (ein call weniger)
ist aber manchmal unbequem..
während der initialisierung zB
ist xxx_enable(); shöner als xxx_switch(true); zu tippen,
weil man beim lesen des codeblocks nicht über funktion nachzudenken 
braucht um ihn zu ergründen.
idealerweise weiss man unzweifelhaft ahaaa drv0 wird hier aktiviert

Experte schrieb:
> Ach, vergessen: Persönlich würde ich statt:
>     XXX_enable();
>
> immer:
>     enableXXX();  // oder auch enable_XXX();
>
> vorziehen. Das ist halbwegs normal lesbares Englisch.

Absolut NICHT

hat man DRV0 DRV1 DRV2 usw zu beackern
ist DRV0_enable()
in der funktionsübersicht zusammen mit DRV0_read() und 
DRV0_gehmirnichtaufdenSack()
danach folgen dann DRV1 und DRV2
benutzt man enableDRV0() enableDRV1() und enableDRV2()
gruppiert sich das eben genauso in der Funktionsübersicht,
gefolgt von gehmirnichtaufdenSack_DRV0() gehmirnichtaufdenSack_DRV1() 
gehmirnichtaufdenSack_DRV2()
und man kann sich schneller 'verklicken' ;)

Ausserdem behält das so höhere Konsistenz
sollte man sich später zu Objektklassen
hangeln
DRV0.enable()
ist näher an DRV0_enable() als an enableDRV0() ;)

wieso ich as anspreche?
naja DRV-NULL bedeutet für mich dass sich jmd die option für eins zwei 
und drei offenhalten möchte.

ab drei find ich macht ne Objektklasse deutlich Sinn..
oder was sagt der selbsternannte Experte dazu?

enableDisable(x) gefällt mir überhaupt nicht. Mit allen anderen 
genannten Varianten kann ich leben.

wie in der schaltungstechnik
bei positiver Logic:
void XXX_enable_notDisable(bool enable);

bei negativer:
void XXX_disable_notEnable(bool disable);

> DRV0_enable()
Voll doof.
Auf Unbehagen des TE, ich synchronisiere.


Dagegen, voll coool:
> drivers[0].enable();

Weitere schöne Alternativen, es gibt!
Mindestens, über drei.

frei nach Joda

Sven L. schrieb:
> aber wieso gibt es eine Methode Enable mit einem Parameter bool und eine
> Methode Disable mit einem Parameter bool?

Nein, gibt es nicht.

Walter T. schrieb:
> Es hat den Programmfluß deutlich übersichtlicher gestaltet, die beiden
> letzten Funktionen zu einer zusammenzufassen. Nur der gute Name fehlt
> noch.

Vorher 2 ohne Parameter
Jetzt 1 mit bool

Sven L. schrieb:
> oder
> das Ganze als Attribut in Form einer Varibale macht, wenn es sich um
> eine Klasse handelt

Mantra:
> Instanz Variablen nur über Getter und Setter manipulieren (lassen)

(Ausnahmen bestätigen die Regel, sind aber sehr selten)

Getter und setter ermöglichen, auf Zugriffe zu reagieren. Das kann auch 
hilfreich sein, bei künftigen Änderungen kompatibel zu bleiben. Manche 
Leute verbieten direkte Zugriffe auf Objekt-daten regelrecht.

Auf meiner Arbeit sind getter und setter Pflicht. Immer und überall, 
ihne wenn und aber.

Carl D. schrieb:
>> Auf meiner Arbeit sind getter und setter Pflicht. Immer und überall,
>> ihne wenn und aber.
>
> Einen ordentlichen Compiler ist das auch egal.

Getter und Setter sind hier ja nicht wirklich Thema. Aber abgesehen von 
Teams mit blutigen Anfängern ist ein Zwang dazu schon bedenklich. 
Spätestens, wenn für jede Variable auch gleich getter und setter 
angelegt werden, wird es absurd.

Wilhelm M. schrieb:
> Falls dem so ist, solltest Du mal mit
> dem Verantwortlichen ein ernstes Gespräch führen.

Ich nutze die Geduld meiner Kollegen und der Geschäftsleitung zur 
Korrektur von wichtigeren Dingen.

Wilhelm M. schrieb:
> War das jetzt ein implizites "ja" zu meiner Frage?

Es war ein implizites ja zu:
> Etwa für jedes non-const Member Modifikatoren und
> Observatoren-Elementfunkitonen?

Und ein "will ich nicht tun" zu:

> solltest Du mal mit dem Verantwortlichen ein ernstes Gespräch führen.

Stefan ⛄ F. schrieb:
> Und ein "will ich nicht tun" zu

Da machst nix dran.
Der Wilhelm hat es halt voll auf dem Schirm.
Da können wir beide nicht gegen an stinken.

Er hat es sich auf seinem hohen Ross schön bequem gemacht.
Dieser hohe Grad an Schlauheit und Wissen gibt ihm das Recht, alle 
anderen nach Belieben für blöd zu erklären.

Hier erwischt es gerade uns beide.


Ansonsten entert er sowieso jeden nur möglichen Thread, und prahlt mit 
seinem C++. Egal ob das zum Thema passt oder nicht.

Zusammenfassung:
Wilhelm hat immer recht.
Missverständnisse und Kommunikationsprobleme gibt es in seiner Welt 
nicht.
Und wenn, hat er nichts damit zu tun, es sind immer nur die anderen, 
welche zu blöd sind, zu kapieren was er meint.

Stefan ⛄ F. schrieb:
> Auf meiner Arbeit sind getter und setter Pflicht. Immer und überall,
> ihne wenn und aber.

Typisches "Prinzip Hoffnung":

Stelle eine einfache Regel auf, beschäftige Programmierer mit dem 
Schreiben von Boilerplate-Code, und hoffe auf ein gutes Ergebnis.

Genau das Gegenteil passiert aber.

Wilhelm M. schrieb:
> Dann würde mich mal interessieren, wie Du Klasseninvarianten zusicherst?
> Bzw.: warum machst Du dann Deine Member private (falls Du das tust)?

Darüber habe ich mir noch keine Gedanken gemacht. Das ist ja auch nicht 
meine Regel, ich muss sie nur umsetzen.

Stefan ⛄ F. schrieb:
> Das ist ja auch nicht meine Regel, ich muss sie nur umsetzen.

Stefan, Du bist so erfahren und hast so viel hier und auf Deiner 
Webseite veröffentlicht. Und dann propagierst Du eine kuriose Regel, die 
Du blind befolgst und hast Dir noch keine Gedanken dazu gemacht? 
Nichtmal auf Nachfrage?

A. S. schrieb:
> Und dann propagierst Du eine kuriose Regel

Ich propagiere nicht, ich sage nur, dass es manche Leute so haben 
wollen.