Programmierstil?
-
Wurde bereits diskutiert und das habe ich wie gesagt ja bereits geändert. Da das Beladen der Klasse durch eine andere geschieht, brauch ich Zugriff. Entweder biete ich getter an oder friend, wobei die Ladeklasse vererbbar ist, sodass ich friend letztlich dieser gegeben habe, die die Getter protected für ihre vererbten Klassen anbieten konnte. Aber ja, ist ne andere Geschichte.
Tabbreite der IDE != 4 sehe ich halt selten, aber wäre natürlich schade. Dokumentationstools bringen nicht viel, wenn man im Code herumwühlen muss, oder? Wenn man die Klassen einfach nutzt, braucht man das natürlich nicht.
-
MeshHolderVector & GetMeshHolders () {return meshHolders_;} Mesh & GetMesh () {return aggregatedMesh_;} MaterialMap & GetMaterialMap () {return materialMap_;} TextureMap & GetTextureMap () {return textureMap_;} AnimationMap & GetAnimationMap () {return animations_;} ModelNodePtr /***/GetRootNode () {return rootNode_;} const ModelNodePtr /***/GetRootNode () const {return rootNode_;} void SetRootNode (const ModelNodePtr node) ; void CacheNodes () ;
Aber irgendwo muß das auch ein Ende haben.
Bei mir ist das Ende sehr früh.
Da kann ich mir zwar denken, daß es Vorteile haben könnte, aber regelmäßig fühle ich, daß es irgendwie doch nicht so ist.
-
Eisflamme schrieb:
Wurde bereits diskutiert und das habe ich wie gesagt ja bereits geändert. Da das Beladen der Klasse durch eine andere geschieht, brauch ich Zugriff. Entweder biete ich getter an oder friend, wobei die Ladeklasse vererbbar ist, sodass ich friend letztlich dieser gegeben habe, die die Getter protected für ihre vererbten Klassen anbieten konnte. Aber ja, ist ne andere Geschichte.
Wenn jede Klasse sich um ihr eigenes Zeug kümmert (inklusive "Beladen"), braucht man fast keine Getter und Setter, sodass ich eigentlich nie eine solche Ansammlung von Minifunktionen habe, was dein Argument nichtig macht.
-
volkard:
Ja, vielleicht gewöhne ich mir das auch ab. Aber guten Einblick erhält man so oder so nicht. Ich muss mich wohl echt Mal um dieses Tool kümmern.Michael E.:
Dann sprichst Du sämtlichen Erzeuger-Pattern den Sinn ab? Die entsprechende Klasse ist komplex, aber sie wird durch verschiedene Dateiformate geladen, zu denen es jeweils verschiedene Ladeklassen/Funktionsansammlungen gibt. Die Verwendung möchte ich daher von der Initialisierung trennen, da letztere komplex und austauschbar sein soll.
-
Eisflamme schrieb:
Michael E.:
Dann sprichst Du sämtlichen Erzeuger-Pattern den Sinn ab?Nö (sorry, hab grad keine Zeit, das weiter auszuführen).
-
Allerdings kam ich auch schon aus anderen Gründen auf den Gedanken, den Typ gelerell nach hinten zu schubsen.
auto GetMeshHolders() -> MeshHolderVector& {return meshHolders_;} auto GetMesh() -> Mesh& {return aggregatedMesh_;} auto GetMaterialMap() -> MaterialMap& {return materialMap_;} auto GetTextureMap() -> TextureMap& {return textureMap_;} auto GetAnimationMap() -> AnimationMap& {return animations_;} auto GetRootNode() -> ModelNodePtr {return rootNode_;} auto GetRootNode() const -> ModelNodePtr const {return rootNode_;} auto SetRootNode(const ModelNodePtr node) -> void; auto CacheNodes() -> void;
-
z.T. Einrückung/Alignment von Code:
Ich habe mir das abgewöhnt. Es braucht einfach zu viel Zeit beim Schreiben. Bei jeder 2. Änderung darf man wieder nachbessern = alle Einrückungen anpassen weil die neu hinzugekommene Funktion nen längeren Returntyp hat, nen längeren Namen oder was weiss ich.
Und wenn man anfängt mit diversen Tools zu refactoren (z.B. Funktionen oder Klassen umzubenennen), dann gehen die "schönen" Einrückungen sowieso kaputt, ohne dass man die betroffenen Stellen überhaupt sieht. Ich benenne z.T. ohne mit der Wipmer zu zucken Klassen um die an 1000+ Stellen im Programm verwendet werden. Wenn ich da überall die Einrückung nachbessern müsste wäre das eine Aktion auf Stunden. So dauert es ein paar Sekunden. (Cursor platzieren -> Alt+R -> neuen Namen tippen -> paar Sekunden warten bis VAX alle Stellen gefunden hat -> Rename drücken -> fertig)
So führt in dieser Art eingerückter Code auch zu schlechterem Code, da man sinnvolle Refactorings erst viel später oder gar nicht durchführt, weil man immer an den damit verbundenen Aufwand denkt. Bzw. daran, dass, wenn man sich den Aufwand spart, die ganzen hübschen Einrückungen "kapput" sind.
Gibt es dagegen diese "hübschen" Einrückungen gleich gar nicht, dann kann man auch nix kaputt machen.
BTW: Visual Assist X kann Typen (Klassennamen) einfärben. Der Returntype einer Funktion hat dann immer ne schöne Farbe, der Funktionsname dagegen wird anders eingefärbt (bei mir Schwarz). Hilft auch um schnell nen Überblick zu bekommen.
Und natürlich hilft es
inline
Code nicht mit in die Klasse zu schreiben, sondern mit Hilfe desinline
Keywords nach der Klasse im selben Header File zu schreiben.
-
Okay, das sind wirklich gute Argumente, überzeugt.
Ich bin nur stur, wenn man mich überreden will und dabei noch beleidigend ist.
-
Eisflamme schrieb:
... aber das Codebild ist nachher besser zu lesen und das ist es mir wert.
Das ist interessant, denn offensichtlich hast du es dir beigebracht, den Text von oben nach unten zu lesen... was ja nicht schlimm ist. Du musst bedenken, dass die meisten Menschen den Text von links nach rechts lesen. Es wird jedem von uns seit der Grundschule beigebracht und im Laufe der folgenden Schul- und Lebensjahre machen wir nichts anderes als von links nach rechts zu lesen, sei es in unserer Freizeit, unter Stress oder wie auch immer. D.h. jeder, oder zumindest die meisten, die deinen Quellcode verstehen möchten, werden bei jeder Zeile versuchen, diese von links nach rechts zu lesen, ob sie es wollen oder nicht, und zusätzlich noch bei jedem Wort über die großen Abstände stolpern... denn es kommen noch die "biologischen Limitierungen" (nennt man es so
) hinzu, d.h. das menschliche Auge erfasst beim Lesen ganze Wörter und "braucht" kurze Abstände, Leerzeichen, um die nächsten Wörter zu erfassen. Das bedeutet u.a., dass so was hier:
for(i=0;i<N;++i)
genauso "schlimm" ist wie das hier
for ( i = 0; i < N; ++i )
Im ersten Fall erfasst das Auge bei den meisten Lesern ganze Zeile, diese enthält zu viel Information, um sie auf Anhieb zu verstehen, man muss genauer hinschauen, was mitten drin steht, das ist "anstrengend". Im zweiten Fall erfasst das Auge nur einzelne Zeichen, "for", "(", "i" usw. weil große Abstände, einzelne Zeichen allein enthalten wenig Information, man muss sich wieder anstrengen und aus einzelnen Zeichen etwas zusammensetzen.
-
Das ist ein sehr schlechtes Argument.
Wer in dem oben geposteten Code eine Methode sucht, indem er alle Zeilen von links nach rechts durchgeht, der ist ein Idiot.
-
Ich "lese" Code, wenn er ausreichend einfach ist, weder von links nach rechts noch von oben nach unten, sonder eher in Blöcken.
Wenn man es lange genug macht (programmieren), kommt diese Fähigkeit irgendwann (*).Genauso wie, wenn man viel liest, man "quer" über Seiten drüberlesen kann, wenn man nur eine bestimmte Stelle sucht, oder nur rausbekommen will ob ein bestimmtes Thema in dem Text vorkommt.
Natürlich ist diese Methode nicht 100% sicher, man kann dabei auch mal was übersehen. In den meisten Fällen findet man aber was man sucht, und wenn nicht, dann muss man halt nochmal drübergehen, und beim 2. oder 3. mal dann wirklich alles "lesen" statt nur "drüberzuhuschen".
Und bei dieser Art zu "lesen" stört es sogar, wenn alles "hübsch" eingerückt ist. Zumindest bei mir. Hängt vermutlich auch davon ab welche Einrückungsart man gewöhnt ist. Der überwiegende grossteil von Code den ich lese (auch fremder Code, der nicht bei uns im Haus entstanden ist), ist allerdings "normal" eingerückt und nicht "aligned".
*:
Nicht bei allen wie ich festgestellt habe. Aber das ist so wie es auch nicht alle checken dass mit Shift+Cursortasten markieren und mit Ctrl+C - Ctrl+V kopieren schneller ist als mit der Maus zu markieren und dann übers Edit Menu erst Copy und dann Paste auszuwählen (auch mit der Maus, und die Maus dabei noch mit zwei Fingern schieben und vor jedem Klick absetzen und extra langsam Klicken damit man nicht "verreisst"). Hab ich auch Programmierer gesehen die das nach 10+ Jahren im Job immer noch so gemacht haben.
(Ctrl+Ins - Shift+Ins ist auch OK für Copy-Paste, geht mir nur darum dass mit Tastatur schneller ist als mit Maus)----
Was
for(int i=0;i<10;i++)
vs.for (int i = 0; i < 10; i++)
angeht hab' ich mir letzteres angewöhnt, weil ich es leichter zu lesen finde. Space nach Keywords (if, for, while, switch etc.) und zwischen binären Operatoren. Kein Space vor und nach Klammern (ausser eben vor Klammern die auf ein Keyword folgen). etc.
"Objektive" Argumente dafür kann ich keine anführen, ausser dass es sich - ich habe zumindest den Eindruck - als quasi-Standard durchgesetzt hat. Und ich persönlich (aber das ist ja nicht objektiv) es leichter zu lesen finde.
-
So etwas wie der ganz unten stehende Code (siehe Link) ist für mich der absolute Horror zu lesen. Das Witzige daran ist, dass der Autor diesen Stil sogar im Tutorial verwendet.
-
[Rewind] schrieb:
So etwas wie der ganz unten stehende Code (siehe Link) ist für mich der absolute Horror zu lesen. Das Witzige daran ist, dass der Autor diesen Stil sogar im Tutorial verwendet.
Was zum? Schrecklich
-
Eisflamme schrieb:
Das ist ein sehr schlechtes Argument.
Wer in dem oben geposteten Code eine Methode sucht, indem er alle Zeilen von links nach rechts durchgeht, der ist ein Idiot.
Die Mehrheit der Leser wird es wohl so versuchen...
-
hustbaer schrieb:
Ich "lese" Code, wenn er ausreichend einfach ist, weder von links nach rechts noch von oben nach unten, sonder eher in Blöcken.
Wenn man es lange genug macht (programmieren), kommt diese Fähigkeit irgendwann (*). ...Es gibt verschiedenste Techniken, es soll sogar Leute geben, die die erste Zeile von links nach rechts lesen und die zweite gleich von rechts nach links. Damit soll die Zeit gespart werden, die die Augen brauchen, um vom Ende der ersten Zeile auf den Anfang der zweiten zu schauen.
Meine Einstellung ist so, dass ich von anderen Entwicklern keine solche oder ähnliche Fähigkeiten erwarte und schreibe und formatiere den Quelltext so, dass er ohne größere Anstrengung von link nach rechts zu lesen ist. Dieses "Schreiben" und "Formatieren" ist vielleicht falsch ausgedrückt, denn vieles wird von meinem Editor (gvim) quasi automatisch erledigt... das geht soweit, dass ich z.B. die "Copy-Paste"-Funktionalität der anderen Editoren als zu primitiv empfinde, weil gvim mehrere benannte Zwischenablagen (sog. Register) bietet, man kann verschiedenste Textausschnitte in diese Register kopieren und dann den Inhalt dieser Register in beliebiger Reihenfolge einfügen. Das soll jetzt aber nicht die Leute verunsichern, die gerne mit der Maus "copypasten"
-
abc.w schrieb:
Eisflamme schrieb:
Das ist ein sehr schlechtes Argument.
Wer in dem oben geposteten Code eine Methode sucht, indem er alle Zeilen von links nach rechts durchgeht, der ist ein Idiot.
Die Mehrheit der Leser wird es wohl so versuchen...
Wenn er nach Methodennamen sucht von links nach rechts? Aber links und rechts steht der Methodenname nicht, der steht in der Mitte, also geht man doch nur von oben nach unten. Das ergibt für mich keinen Sinn.
Nicht, dass ihr mich falsch versteht: Ich bin bereits überzeugt und gewöhne mir diese Formatierung jetzt wieder ab (wenn ich in einigen 100 Jahren wieder Mal was programmiere). Aber in meinem oben geposteten Stil Methodennamen mit "links nach rechts" lesen zu durchforsten, ist schon wenig intelligent.
-
Eisflamme schrieb:
Wenn er nach Methodennamen sucht von links nach rechts?
Wenn ich nach Methodennamen suche dann guck ich auch erst gar nicht in den Quelltext sondern benutz die Suchfunktionen und Ansichten meiner IDE ...