Funktionsname: Enable/Disable

[Walter T. (nicolas)]

Hallo zusammen,

wie würde ihr eine Funktion nennen, mit der man etwas ein- oder 
ausschaltet, wobei die Handlung mit einer booleschen Variable festgelegt 
wird?

     void XXX_enableDisable(bool enable);

[DPA (Gast)]

set

[Joe F. (easylife)]

void enable_blabla(bool enable);

[St. D. (st_d)]

onOff

[Wilhelm M. (wimalopaan)]

Nur /enable(bool)/, denn bei enableDisable(bool) weiß man ja nicht, was 
gemeint ist. Also:

class XXX {
    XXX& enable(bool);
};

[Einer K. (Gast)]

Bin für setIrgendwas(bool enable);

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Bin für setIrgendwas(bool enable);

Warum setXXX()? Das ist doch in C++ absolut unnötig. Non-const 
Elementfunktionen sind doch immer in der Rolle eines Modifiers.

[Einer K. (Gast)]

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.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Du kannst das C++ vielleicht riechen.
> Ich sehe es hier noch nicht.

Du meinst, es wäre C? Das steht da ebenso 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()

Liest das nochmal ganz genau. Da stehen solche Sätze wie:

/In anderen Programmiersprachen ist dies unüblich und die Methode hieße 
einfach name, da bereits der Funktionsaufruf als solcher ein Holen in 
sich hat./

[Einer K. (Gast)]

Walter T. schrieb:
> Funktion

Wilhelm M. schrieb:
> Methode

!?!

[Walter K. (walter_k488)]

Walter T. schrieb:
> Hallo zusammen,
>
> wie würde ihr eine Funktion nennen, mit der man etwas ein- oder
> ausschaltet, wobei die Handlung mit einer booleschen Variable festgelegt
> wird?

Wenn Du bei jedem function-name in Foren nachfragst, dann wird das wohl 
ein längerdauerndes Projekt ;-)

[Dergute W. (derguteweka)]

Moin,

void wrdlbrmfd(int wrdl)

und natuerlich  - ganz wichtig - nicht dokumentieren !!einself!!1

SCNR,
WK

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Walter T. schrieb:
>> Funktion
>
> Wilhelm M. schrieb:
>> Methode
>
> !?!

Ich habe nirgendwo von Methode geschrieben. Das kommt nur im Zitat vor. 
Desweiteren ist Methode und Elementfunktion ja synonym. Du scheinst es 
wirklich nicht zu verstehen, was der Unterschied ist. Const-Correctness 
ist etwas ganz wichtiges. Nur Java kann das eben nicht, deswegen diese 
bekloppten Namen, deren Semantik der Compiler ja nicht überprüft.

[A. S. (Gast)]

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.

[sid (Gast)]

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

void XXX_enable(bool on)
{...}
//und noch n overload dazupacken
void XXX_enable()
{
   XXX_enable(true);
}
//sowie ein disable, weil man ja bequem ist
void XXX_disable()
{
   XXX_enable(false);
}

du kannst aber auch ohne overload
den Namen anders gestalten zB

void XXX_switch(bool enable)
{...}
//und dann trotzdem mit enable
void XXX_enable()
{
   XXX_switch(true);
}
//und disable arbeiten wenn du magst
void XXX_disable()
{
   XXX_switch(false);
}

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)

[Walter T. (nicolas)]

In diesem Fall gibt es tatsächlich nur vier Funktionen:

    void DRV0_init();
    void DRV0_deinit();
    void DRV0_enable();
    void DRV0_disable();

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

Walter K. schrieb:
> Wenn Du bei jedem function-name in Foren nachfragst, dann wird das wohl
> ein längerdauerndes Projekt ;-)

Ich habe am Jahresendfreitag viel Zeit. Da kann man auch mal über 
nicht-dringende Sachen sinnieren.

[Einer K. (Gast)]

> 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

[sid (Gast)]

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.

[DPA (Gast)]

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

[Yalu X. (yalu) (Moderator)]

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

"Enable" steht für freigeben, aktivieren oder einschalten und ist meist
mehr als nur das Setzen eine Variable auf true oder false. Um bspw. die
automatische Belichtungseinstellung einer externen Kamera zu aktivieren,
muss eine entsprechenden Nachricht an die Kamera geschickt werden.

Selbst wenn eine Aktivierung einer bestimmten Funktionalität tatsächlich
durch eine boolesche Variable erfolgt (die dann von einem anderen
Programmteil gepollt wird), handelt es sich bei dieser Variable um ein
Implementierungsdetail, das für den Aufrufer der Enable-Funktion nicht
von Interesse ist.

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

Man kann sich natürlich alle Mühe geben, das falsch zu verstehen. Das
kann ich auch bei deinem Vorschlag:

> setXxxFlag(true);

Hier wird das Flag gesetzt und damit die Funktionalität aktiviert.

> setXxxFlag(false)

Hier lese ich, dass das das Flag nicht gesetzt (aber auch nicht
gelöscht) und die Funktionalität in ihrem gegenwärtigen Zustand
(aktiviert oder deaktiviert) belassen wird.

Um das Flag zu löschen und damit die Funktionalität zu deaktivieren,
bräuchte man eine weitere Funktion namens clearXxxFlag().


Ich würde die aktuelle Namensgebung einfach beibehalten:

Walter T. schrieb:
>     void DRV0_enable();
>     void DRV0_disable();

weil das für mich am klarsten ausdrückt, was jeweils getan wird.

> Es hat den Programmfluß deutlich übersichtlicher gestaltet, die beiden
> letzten Funktionen zu einer zusammenzufassen

Inwiefern hat das einen Einfluss auf den Programmfluss?

[Walter T. (nicolas)]

Yalu X. schrieb:
> Inwiefern hat das einen Einfluss auf den Programmfluss?

Stimmt, das ist das falsche Wort. "Lesefluss" ist gemeint.

[Jobst Q. (joquis)]

Warum nicht einfach setXXXenable(bool on) , um alle Mißverständnisse zu 
vermeiden?

[Zeno (Gast)]

Nenne sie

 void kuhliefumdenTeich()

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

[Experte (Gast)]

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:

    if (some_condition)
    {
        enableXYZ();
    }
    else
    {
        disableXYZ();
    }

...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:

> void XXX_enable(bool on)
> {...}
> //und noch n overload dazupacken
> void XXX_enable()
> {
>    XXX_enable(true);
> }
> //sowie ein disable, weil man ja bequem ist
> void XXX_disable()
> {
>    XXX_enable(false);
> }

...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:

    // Freigabe
    XXX_enable();
    XXX_enable(true);

    // Sperre
    XXX_disable();
    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.

[Experte (Gast)]

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

    XXX_enable();

immer:

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

vorziehen. Das ist halbwegs normal lesbares Englisch.

[sid (Gast)]

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?

[Stefan F. (Gast)]

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

[Radomir Friedensreich (Gast)]

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

bei negativer:
void XXX_disable_notEnable(bool disable);

[Apollo M. (Firma: @home) (majortom)]

... kurz und aussagefähig

set/clr

e.g. setPort()/port_set(), setSampleRateADC()/adc_setSampleRate()



mt

[Sven L. (sven_rvbg)]

Walter T. schrieb:
> void DRV0_init();
>     void DRV0_deinit();
>     void DRV0_enable();
>     void DRV0_disable();




Hab mir jetzt nicht wirklich alles durchgelesen, aber wieso gibt es eine 
Methode Enable mit einem Parameter bool und eine Methode Disable mit 
einem Parameter bool?

Wenn man Enable(true) aufruft, dann ist enabled und wenn man das gleiche 
mit fale aufruft, dann ist disabled. Sonst braucht man doch keinen 
Parameter?

Wenn das Ganze am Ende über eine Instanzvariable aufgerufen wird, dann 
kann man sich doch unnötiges BlaBla im Namen sparen?

MyDrv.Enable(true); oder wie auch immer.

Analog zur Elektronik, habe ich doch an einem Bustreiber oder so auch 
nur einen Eingang /en.

[Jobst Q. (joquis)]

Yalu X. schrieb:
> Ich würde die aktuelle Namensgebung einfach beibehalten:
>
> Walter T. schrieb:
>>     void DRV0_enable();
>>     void DRV0_disable();
>
> weil das für mich am klarsten ausdrückt, was jeweils getan wird.

Das macht den Aufruf aber komplizierter, wenn es laufzeitabhängig 
eingesetzt werden soll.

if( bedingung) DRV0_enable();
else DRV0_disable();

statt

setDRV0_enable(bedingung);

[Einer K. (Gast)]

> 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

[A. S. (Gast)]

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

[Carl D. (jcw2)]

A. S. schrieb:
> 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

Falls es die Sprache hergibt, kann man das noch durch einen Defaultwert 
"true" für den Parameter vereinfachen, denn der steckt ja implizit im 
Namen drin.

[Sven L. (sven_rvbg)]

A. S. schrieb:
> Nein, gibt es nicht.

Stimmt schon, war auch falsch aus gedrückt von mir.

Noch eine Überlegung ist, ob man überhaupt eine Funktion braucht oder 
das Ganze als Attribut in Form einer Varibale macht, wenn es sich um 
eine Klasse handelt

MyDrv.Enable = true / false;

finde ich eigentlich noch schöner...

[Einer K. (Gast)]

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)

[Stefan F. (Gast)]

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.

[Sven L. (sven_rvbg)]

Implementierung:

class Person
{
    private string _name;  // the name field
    public string Name    // the Name property
    {
        get => _name;
        set => _name = value;
    }
}

Auftruf:

Person person = new Person();
person.Name = "Joe";  // the set accessor is invoked here                

System.Console.Write(person.Name);  // the get accessor is invoked here

https://docs.microsoft.com/de-de/dotnet/csharp/programming-guide/classes-and-structs/using-properties

[Carl D. (jcw2)]

Stefan ⛄ F. schrieb:
> 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.

Einen ordentlichen Compiler ist das auch egal. Der kann aus

 Objekt.setVariable(42)

problemlos

mov DWord Ptr [esi],42

machen.
(Adresse von Objekt in esi vorausgesetzt, aber die bräuchte er ja für 
einen Call auch)

[A. S. (Gast)]

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. (wimalopaan)]

Stefan ⛄ F. schrieb:
> Manche
> Leute verbieten direkte Zugriffe auf Objekt-daten regelrecht.

Wenn sie non-const sind und zum internen Zustand der Objekte beitragen, 
ist das ja eines der wesentlichen Prinzipien der OOP. Insofern 
selbstverständlich.

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

Wie meinst Du das? Etwa für jedes non-const Member Modifikatoren und 
Observatoren-Elementfunkitonen? Falls dem so ist, solltest Du mal mit 
dem Verantwortlichen ein ernstes Gespräch führen.

[Stefan F. (Gast)]

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. (wimalopaan)]

Stefan ⛄ F. schrieb:
> Ich nutze die Geduld meiner Kollegen und der Geschäftsleitung zur
> Korrektur von wichtigeren Dingen.

War das jetzt ein implizites "ja" zu meiner Frage?

[Stefan F. (Gast)]

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.

[Einer K. (Gast)]

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.

[Wilhelm M. (wimalopaan)]

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

Dann würde mich mal interessieren, wie Du Klasseninvarianten zusicherst?

Bzw.: warum machst Du dann Deine Member private (falls Du das tust)?

[Experte (Gast)]

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.

[Stefan F. (Gast)]

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.

[A. S. (Gast)]

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?

[Stefan F. (Gast)]

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

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

[Carl D. (jcw2)]

A. S. schrieb:
> 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.

Auch zitieren will gelernt sein ;-)
Hint: spitze Klammer zählen.

[S. R. (svenska)]

A. S. schrieb:
> Und dann propagierst Du eine kuriose Regel, die
> Du blind befolgst und hast Dir noch keine Gedanken dazu gemacht?

Es gibt Dinge, an denen rüttelt man nicht. Schon garnicht, wenn das Team 
groß genug ist, Tiefflieger enthält (denn wegen denen macht man solche 
Regeln) und der Code dann auch noch ziemlich alt und unter Zeitdruck 
entwickelt ist.

100k LoC C++98 ohne STL konvertierst du auch nicht "mal eben so". Vor 
allem nicht, wenn zuwenig Leute dran arbeiten, die Entwicklung 
weitergehen soll, die Mitarbeiter nicht auf C++17 mit STL und den vielen 
Design-Patterns geschult sind und Verifikation teuer und langwierig ist.

Im Übrigen gibt es einen Unterschied zwischen "ich finde die Regel gut" 
und "naja, manche wollen eben auch solchen Unsinn".