ZFX + Developia

Hallo,

ich habe mal eine Frage, die wohl eher zügig beantwortet werden kann; aber ich möchte mal nach den Erfahrungen und Vorgehen anderer Programmierer fragen.

Wenn ich Klassen schreibe, dann versuche ich so gut es geht auf Membervariablen zu verzichten.

Grund meiner Bemühung:
Ich finde es nervig beim debuggen, oder auch lesen des Codes, wenn ich erst woanders suchen muss um zu sehen wann eine Variable wie gesetzt wird. Außerdem denke ich, das lokaler Code besser für Multithreading geeignet ist, da die Variablen nur innerhalb des Threads existieren; okay... abgesehen eben vom Ergebnis des Threads..

Ich habe versucht das durch HelperFunktionen, Funktionen die ausschließlich in der CPP-File deklariert und definiert werden, umzusetzen.
Aber irgendwie wird das nicht sehr übersichtlich auf Dauer :/

Ich könnte es auch noch über statische Memberfunktionen umsetzen, durch die ausgeschlossen werden kann das ich nicht statische Member benutze; aber irgendwie habe ich das Gefühl das das auch nicht schön wird.

Es gibt ja auch noch Lambdas, finde ich aber auch unschön wenn diese dann etwas länger werden.


Wie macht ihr das?
Ist das überhaupt ein Thema für euch?
Also wie könnte ich ausschließen, dass bestimmte Memberfunktionen auf Membervariablen zugreifen?

Nein, ist für mich kein Thema. Wenn ich State (in Membervars) brauche, dann brauche ich ihn. Im Laufe der Jahre komme ich immer mehr davon ab, darin jetzt mit private, public Gettern, Settern usw. künstliche Grenzen einzuziehen, die eh niemand anderen als mich selbst aufhalten.

Es gibt speziell in C++ das Problem, dass man in Klassen die Vars definieren muss, die Nutzerinnen der Klasse aber nur die Schnittstelle sehen wollen. Die Membervars brauchen dann auch wieder weitere Includes, und *das* ist tatsächlich ein Ärgernis. In der C++-Welt hat man dagegen das Private Implementation-Idiom etabliert, kurz PImpl. Da vorwärts-deklariert man in der Klasse als einzigen Member eine struct PImpl und eine einzige Membervar std::unique_ptr<PImpl> und die kann man dann in der CPP definieren und benutzen. Das verdreckt dann auch nicht den Space der Includierenden. Aber es gibt hässliche Fallstricke, und man tritt sich halt mit jeder Instanz dieser Klasse eine Allokation ein, daher sollte man das nur für große komplexe Objekte tun.

Ich bin zwar auch noch Anfänger, aber ich stelle allen meinen Membervariablen ein "m_" vor. Damit weis ich sofort das es eine Membervariable ist.

Beispiel: float m_Variablenname;

Okay, danke erstmal für euren Input.

Anscheinend ist das nur für mich ein Thema...
Ich denke aber ich bleibe bei dem Ansatz, wo immer es geht lokalen Code zu schreiben.

@private/public/get/set
Nennt mich altmodisch, aber ich verwende die immer und häufig^^

Mirror hat geschrieben: ↑22.07.2021, 10:56 Ich bin zwar auch noch Anfänger, aber ich stelle allen meinen Membervariablen ein "m_" vor. Damit weis ich sofort das es eine Membervariable ist.

Beispiel: float m_Variablenname;

Und ich schreie, wenn ich das sehe. Das ist nur ein this->Variablenname in Grün, und meine Variablen sehen dann alle Scheiße aus

Zudem ist this-> sehr sehr eindeutig, worauf der Zugriff ist und ich muss nicht erst gucken, ob jetzt m_fPoint wirklich ein Member ist

xq hat geschrieben: ↑22.07.2021, 11:41

Mirror hat geschrieben: ↑22.07.2021, 10:56 Ich bin zwar auch noch Anfänger, aber ich stelle allen meinen Membervariablen ein "m_" vor. Damit weis ich sofort das es eine Membervariable ist.

Beispiel: float m_Variablenname;

Und ich schreie, wenn ich das sehe.

Dann wirst du bei mir auch schreien^^
Also auf Arbeit bei uns ist das Pflicht. Und ich habe mich auch daran gewöhnt.
Auch bei vielen OpenSource Projekten die ich auf Git oder sonstwo sehe machen die das; bestes Beispiel: Qt

Also Visual Studio 2019 färbt in den Standardeinstellungen lokale Variablen und Member-Variablen unterschiedlich ein. Da erkennt man also schon an der Farbe wo sie definiert sind.

Das Header/Source Files in C++ sehr wenig mit "Interface und Implementierung" zu tun haben (weil in der Headerdatei haufenweise Implementierungsdetails stehen müssen) ist wirklich bedauerlich, aber halt schwer zu ändern. Lösungen wie Pimpl haben ja nicht nur das Problem, dass man beim Anlegen eine zusätzliche Allokation hat, sondern auch bei jedem Zugriff eine zusätzliche Indirektion. Und man eine unfassbare Menge super nervigen Boilerplate-Code schreiben muss. Ich habe damit früher experimentiert, fand es aber so nervig dass ich beschlossen habe die langen Compilierzeiten in Kauf zu nehmen und darauf zu hoffen, dass sich C++-Module möglichst schnell durchsetzen.

Pimpl würde *mein* Problem (Wenn man es als Problem sehen will) auch nur verschieben.

Mir geht es bspw. ums debuggen. Beispiel:
Es crasht in irgend einer Funktion, oder die gibt mir einen falschen Wert aus (mal angenommen es handelt sich nicht um ganz trivial Typen (int, float, bool,...)).
Ich setze einen Breakpoint an der Stelle und hangel mich stück für Stück den Callstack nach oben und schaue mit die Variablen an.
Und ich weiß eben, dass alle diese Variablen im Callstack niemals an einer anderen Stelle gesetzt werden konnten. Also die konnten nur im Durchlaufen des Callstack gesetzt/verändert werden.

Ich finde, das erleichtert mir das debuggen ungemein.
Oder mein Hirn ist so simple gestrickt, dass ich nur lineare Pfade verarbeiten/(ver)folgen kann :/ Dann ist das wie gesagt nur ein Thema für mich^^

Hä? Entweder Du möchtest Deine Methode const haben, dann kann sie alle Membervars lesen, aber nicht ändern. Oder Du willst eine lokale Variable, die überhaupt nur in dieser Funktion gebraucht wird, dann sollte es natürlich gar nicht erst ne Membervar werden. Ich muss aber ehrlich zugeben, dass ich gar nicht mehr sicher bin, was eigentlich Deine Sorge ist.

Ich auch gerade nicht.

Ich schaue mal, ob ich das an einem Code-Beispiel erklären kann.
Wenn nicht, dann ist das Thema abgehakt und const ist die Lösung...

joggel hat geschrieben: ↑22.07.2021, 12:50 Ich setze einen Breakpoint an der Stelle und hangel mich stück für Stück den Callstack nach oben und schaue mit die Variablen an.
Und ich weiß eben, dass alle diese Variablen im Callstack niemals an einer anderen Stelle gesetzt werden konnten. Also die konnten nur im Durchlaufen des Callstack gesetzt/verändert werden.

Hm, aber das klingt auch für mich nach einer eher seltenen Art von Problem. Mit der Aufteilung, wo welcher Code steht kriegst du da ja auch irgendwie höchstens eine Stufe mehr oder weniger rein. Wenn ich das Problem habe, dass der Code abstürzt, weil Variablen falsche Werte haben und ich nicht weiß, wo diese herkommen, dann eher bei komplexeren Algorithmen. Z.B. ein A* für Wegfindung. Aber sowas wird man doch auch nicht damit los, dass man all seine Klassen anders implementiert. Das wirklich nur für eine Fehlerklasse zu tun, erscheint mir nicht lohnend.

Was ich aber gerne mal mache ist, dass wenn ich zu lange / komplexe Funktionen habe, ich einen Teil davon in eine weitere Funktion auslagere, die von außen nicht sichtbar ist. Alle benötigten Werte als Parameter zu übergeben hilft enorm dabei, Seiteneffekte zu vermeiden und sich klar zu werden, welcher Code was benötigt.

Jonathan hat geschrieben: ↑22.07.2021, 13:31 Was ich aber gerne mal mache ist, dass wenn ich zu lange / komplexe Funktionen habe, ich einen Teil davon in eine weitere Funktion auslagere, die von außen nicht sichtbar ist. Alle benötigten Werte als Parameter zu übergeben hilft enorm dabei, Seiteneffekte zu vermeiden und sich klar zu werden, welcher Code was benötigt.

💓💓💓

Genau das meine ich, und tue ich eben auch. Und das ist mein...naja... "Problem" was ich habe.
Habe ich sehr viele von diesen AuslagerungsFunktionen, dann wird es irgendwie unschön und hässlich. Ich habe die eben oft als HelperFunktionen in der CPP-File.
Weil ich diese Helperfunktionen dann auch oft noch aufteile, in schön simple Bausteine. Und dann werden das aber auch mal etwas mehr.

Also wenn ich so darüber nachdenke, dann gibt es da wohl kaum eine angenehmere Lösung.

Ich schaue trotzdem mal ob ich ein CodeBeispiel zusammen bekomme, was mein Anliegen beschreibt...

Ich finde du musst konkreter werden. Poste doch mal eine Klasse... einmal so programmiert, dass du unzufrieden bist, einmal so umgeschrieben, dass zu zufriedener bist und markiere zusätzlich die Stelle, wo du gern noch zufriedener werden würdest.

Vieles was du schreibt klingt nach ästhetischen Vorlieben die du mit der Lösung eines Problem verkoppelst. Das kann so weit führen, dass man nur noch stolpert, weil man versucht exta-elegant zu gehen.
Oft sind hässliche / stark verworrene Lösungen ein Strukturproblem im Code.

Wenn in deinem Code z.B. Members von lokalen Variablen nicht zu unterscheiden sind, sind deine Funktionen wahrscheinlich zu lang. Wenn du soweit scrollen kannst, dass die lokale Deklaration ausm Bild verschwindet, klammer den Code-Block aus und gib ihn einen sinnvollen Funktions-Namen. Wenn man Umwege wie "m_Member" nehmen muss, hat man das Problem ggf. an der falschen Stelle gelöst. (Behandlung von Krankheit vs. Symptom)

Ich schaue mal nach einem Beispiel.
Kommt aber erst später (heute Abend oder so...)

Auch wenn es viele versucht haben, ich glaube nicht, dass es allgemeingültige Regeln geben kann, die Programmieren auf einmal "leicht" machen, wenn man sie nur befolgt. Bzw. ich glaube nicht dass es genug Programmierer gibt, die solche Regeln gut genug verstehen würden, dass es praktikabel wäre sie durchzusetzen. Quelle: Ich habe schon sehr viel Code gesehen, der sich offensichtlich an die Worte bekannter Regeln hält ohne deren Sinn im Ansatz verstanden zu haben.

Das gesagt habend hier ein paar einfache Prinzipien, die für mich in einer realen Codebase real das beschriebene Problem kleiner machen:

1) Nur gültige Objekte erzeugen. D. h. das Objekt sollte nach Konstruktoraufruf in einem gültigen Zustand sein und nicht noch auf irgendwelche zwingenden inits oder sets warten. Also z. B. nicht Member auf null initialisieren wenn null im weiteren kein gültiger Wert ist.

Wenn du wirklich gar keine Idee hast wie das gehen soll und zwingend Konstruktion in mehreren Schritten brauchst, dann ist ein Builder Pattern mMn immer noch gegenüber einem ungültigen Objekt zu bevorzugen.

2) Die Objekte nach Möglichkeit immutable machen. Immutable ist ein Java Konzept, weil Java kein äquivalent zu C++ const hat, aber man kann es natürlich via const implementieren.

3) Fertig, es gibt keinen Schritt drei. Das Objekt war bei Konstruktion gültig und weil es immutable ist bleibt es für immer gültig, Problem gelöst ... Just Kidding. In der Praxis geht das halt nicht immer oder nur mit großem Aufwand. Es geht aber meiner Erfahrung nach öfter als "die Leute" es versuchen, und deswegen ist mein Rat zuerst diese niedrig hängende Frucht zu pflücken.

Ich gehe mal auf das Neuste ein:

Weil ich diese Helperfunktionen dann auch oft noch aufteile, in schön simple Bausteine. Und dann werden das aber auch mal etwas mehr.
Also wenn ich so darüber nachdenke, dann gibt es da wohl kaum eine angenehmere Lösung.

Gut möglich, dass du ein Sprach-/Kommunikationsproblem an dieser Stelle hast. Mit Sprache meine ich, dass du dir nicht genügend Gedanken machst, wie man etwas nennt oder wann etwas wirklich Sinn macht auszulagern.
"Helper" sollten wirklich nur Funktionen sein, die Parameter schlucken und etwas zurückgeben. Du sollst NICHT in Helpern (schreibend) auf Members zugreifen oder Members nutzen, um in Helpers "hinein zu kommunizieren".
Eine gute Auslagerung von Code hat einen beschreibenden Namen und klare Parameter (nicht zu viele).
Nach der Auslagerung des Codes schaust du die Funktion NIE wieder an. Denn sie ist einfach, kurz und so trivial, dass du niemals irgendwas hättest falsch machen können. Wenn der Funktionsname irgendwo im Code steht, musst du drauf vertrauen können, dass die Funktion tut was sie soll und dann ist auch der Inhalt der Funktion egal - der Funktionssame sagt exakt, was dort passiert.

Wenn du soweit bist, kannst du dich um die wahren Probleme deines Codes kümmern. Und in diesen Zustand zu geraten, dass man eine Programmstruktur hat, die meinen Ausführungen genügt, brauchst man manchmal Zeit und bisschen Geduld.

Du wählst für deine Daten immer den kürzesten passenden Lebensraum.
Andere Überlegungen gibt es nicht.
Präfixe oder Suffixe auch nicht. Kaufe eine IDE ;)
Dasselbe gilt für das "Finden" einer Definition. F3 drücken, oder wohin auch immer das "Goto Definition" bei dir gebunden ist.
Wenn dein Debugger kein Goto Definition kann, musst du mehr Geld ausgeben ;)
Alles andere ist Unsinn, der zur Situation des letzten Jahrtausends passt.

Sorry, dass das jetzt vielleicht sehr drastisch formuliert ist, aber das ist ein Thema, bei dem es keine Diskussion gibt, wenn die Anforderungen an den Code klar sind.

Nicht böse sein, aber mit genau so Code ärger ich mich jeden Tag in Blender rum. Da musst du erst mal ewig forschen musst was jetzt wo steckt und wie das alles zusammenspielt. Aber selbst die hatten ein Einsehen. So hat zum Beispiel ein Panel einen Prefix PT. Und ein Menü MT.

Ich bin da eher pragmatisch veranlagt. Erlaubt ist für mich alles was funktioniert und irgendwie hilft. Und das heisst für mich auch sinnvolle Variablennamen. Aber gut, ich mache das auch nicht professionell. Da herrschen natürlich andere Regeln :)

Ja, stimmt schon: es ist ne rein ästhetische Sache. Es gibt eigentlich kein Problem.
Ich finde es nur sehr hübsch wenn meine Funktion, die vlt etwas komplexer ist, keine Membervariablen hat, weile diese eben zu anderen Zeiten und anderen Stellen gesetzt bzw geändert werden.

Wenn ich meinen lokalen Code habe, dann weiß ich eben, dass alle Vars darin entweder über die Parameter gesetzt werden (natürlich const) oder nur während der Funktion leben. Thats all...

Also: Thema abgehakt!!1^

Eh klar, aber wenn irgendwo weiter oben (bzw. eigentlich unten) im Call-Stack dann die Stelle kommt wo du eine Member-Variable reinreichst und die enthält Bullshit, hast du nichts gewonnen.

Eh klar, aber wenn irgendwo weiter oben (bzw. eigentlich unten) im Call-Stack dann die Stelle kommt wo du eine Member-Variable reinreichst und die enthält Bullshit, hast du nichts gewonnen.

Ja, klar....

Du solltest dir mal Haskell anschauen. Das passt vermutlich besser zu deinem Stil als eine OOP-Sprache.

Aber nochmal man "sucht" nicht. Man fragt die IDE. Es gibt keine Alternative dazu. Und ja, vielleicht ist meine Position dazu etwas drastisch, weil ich eigentlich nur noch an Projekten arbeite die nicht mehr durchsuchbar sind.

How Non-Member Functions Improve Encapsulation:
http://www.drdobbs.com/cpp/how-non-memb ... /184401197

Bin grad aufm weg zur Ostsee.
Lass das mal hier liegen; weiß sonst ni wo...
Aber ohne damit etwas sagen zu wollen ;)

Generell versuchen den Gültigkeitsbereich so eng wie möglich zu halten
und nach Möglichkeit alles immutable.

Ich kenne aber die Siutation wo beim Debuggen oder vorallem bei der Fehlerbehandlung
weitere Infos (=Variablen) wünschenswert sind. In der erwarteten Ausführung sind
diese Infos aber nicht notwendig. Damit nun nicht zahlreiche Parameter immer
durch den ganzen Stack "durchgegeben" werden müssen, nur um dann eine hilfreiche Fehlermeldung
zu erzeugen im Ausnahmefall, kann man zB Context-Objekte erzeugen zB "ImportJobContext"
mit getter/setter (zB aktueller Filename) für alle Infos.
Dann muss man nur genau ein Parameter "durchschleusen".

Eine andere Situation gibt es oft wenn komplexe Objekte erzeugt werden müssen welche viele (optionale)
Parameter haben können und oder während der Erstellung viele temporäre Variablen benötigen.
Dazu bietet sich der "Builder Pattern" an.
Da kann man dann auch Membervariablen im Builder-Objekt machen und die sind
dann auch nur gültig bis das Objekt erzeugt wurde.

Das Wort "Helper" in Code stört mich btw generell und ist ein Zeichen
dass der Programmierer nicht viel Erfahrung hat und den Code nicht gut strukturiert hat.
Ich selber habe das Wort sicher schon über 15 Jahre nicht mehr im Code verwendet,
kenne es aber natürlich aus den Anfangszeiten dass man mal eben ein "FileHelper" oder so macht.
Ob man Prefixe zB für Members verwendet kommt auf die bestehende Codebasis an.
Bei neuem Code halte ich davon nix, das ist unnötiges Relikt, selbst Codereviewtools
haben Highlighting und Farbschemas.

Ich hab nicht alles gelesen, nur überflogen.
Werde mir deine Gedanken also noch zu Gemüte führen...

Hier stand mist..
[...]

Aber interessante Punkte sprichst Du an.
Ich werd mir mal das Builder Pattern anschauen.

Zu diesen Nicht-Member-Funktionen:
Ist auch hilfreicher/bequemer für das schreiben von Tests.

Okay,

Ich will mich mal hier etwas erklären oder rechtfertigen!

Ich sehe mich nicht als Anfänger in der Entwicklung.
Des wegen triggert mich das auch, wenn ich hier so etwas lese, oder das ich die falsche Sprache verwende, oder das mein Design ein "falsches" ist.
Das ich etwas Probleme mit der Kommunikation habe, im Kontext der SW-Entwicklung, muss ich leider zugeben...

Mir ging es aber in diesem Thread um "Kapselung"; und ich wollte das eben auch auf der Ebene der Funktionen durchziehen.

Ich halte den Ansatz trotzdem *nicht unbedingt* für ein Zeichen schlechten Codes...

What ever...
Ich werd mir den Artikel von Onkel Bob mal durchlesen.
Scheint nur so, dass sich auch schon andere darüber Gedanken gemacht haben - und ich mich da bestätigt sah.

Ist aber, bei mir zumindest, eher experimentell bis jetzt und werd sehen ob das für mich ein "improvement" ist...

Sorry um das klarzustellen: war nicht die Absicht jemand zu triggern.
Das Wort "Helper" ist nichtssagend darum macht es (meiner Meinung) keinen Sinn es zu verwenden.
Methoden, Members und Objekte sollten so benannt werden für was sie sind oder was sie tun.
Wenn Du ein konkretes Beispiel nennst können wir ja über das konkrete Beispiel reden.
Wir reden hier aber über Details, vorallem wenn in einem Projekt nur <10 Programmierer involviert sind
und es keine Lib ist, ist die Namensgebung Detail. Ich selber arbeite an "Core Libs" bei einer über 30 Jahre alten
Codebasis wo Programmierer im 3stelligen Bereich daran arbeiten.
Da überlege ich schon 2-3mal ob ich zB "export", "write", "save", "store" oder den Begriff "dump" verwende.
Ich möchte nach Möglichkeit ein simples und einheitliches "Vokabular" in der Programmierung verwenden
und das "Helper" ist eben so ein Klassiker wo ich dagegen bin es zu nutzen.
Früher hatte ich, ich nenne es mal "Fetisch" ;) das nicht so ausgeprägt. Das hat sich über die Jahre so entwickelt.
Ist aber nicht so dass ich ein Programmierer deswegen röste, weil wie gesagt Detail.
Ich weise bei Codereviews einfach drauf hin dass solche Wörter (m.M nach) für den Lesenden keinen Nutzen haben.
Zum Thread selber habe ich ja bereits geschrieben: Stichwort Context-Object und Builder Pattern.

Btw Namensgebung und so, sehr netter Talk: https://youtu.be/QYG7dFPwSrM

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

Ich bin kein Martin-Fowler-Fan, aber ich hörte neulich eine Variante, die wahrscheinlich auch nicht neu ist aber da noch nicht steht:

There are only two hard things in Computer Science: cache invalidation and naming things. ... With that being said, let me introduce you to DNS.

Genau mein Humor.