Programmierstil?

Eisflamme

Wer was haben will, muss auch was dafür tun, das ist klar. Natürlich nerven die Änderungen, aber das Codebild ist nachher besser zu lesen und das ist es mir wert.

Eisflamme schrieb:

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();

lol, nicht dein Ernst (!?)
Damit also alle Methodennamen schön untereinanderstehen machst du dir also so einen Aufwand, aber dass
{return meshHolders_;}
ohne Einrückung, ohne Whitespaces und ohne Linebreaks (dafür mit bescheuertem Unterstrich am Ende) da steht, also quasi unlesbar, stört dich nicht?
Und wenn eine neue Methode dazukommt deren Returntyp dann "const ShaderModelVectorPtr" ist gehst du wieder hin und verschiebst alle Zeilen ein paar Leerzeichen weiter nach rechts? Und die Produktivität geht gegen null...

Ernsthaft, wer hier solchen Code schreiben würde würde sofort aus dem Team fliegen, ich geh mal davon aus dass das anderswo genauso ist. Für Lesbarkeit haben alle halbwegs modernen IDEs eine Outline Ansicht und ein automatisches Code Formatier Tool. Zum hübsch Einrücken werden hier keine Leute bezahlt.
Aber wenn man das als Hobby macht und niemand anders den Code lesen muss kann man das ruhig machen wenn man dann ebsser schlafen kann...

~john schrieb:

BierzeltOmi schrieb:

Ist hier jemand ein bisschen Egozentrisch? Ich hab doch gar nicht auf dich geantwortet...

Woher weiß man das? Ohne Quotes ist die Sache nicht eindeutig, wenn Deine Antwort direkt unter meiner steht.

Eigentlich ziemlich eindeutig, da ich sowohl "Glühbirnes" Aussage als auch Code in meinem Post zitiert hab, aber egal jetzt...

Eisflamme

BierzeltOmi schrieb:

...
lol, nicht dein Ernst (!?)
Damit also alle Methodennamen schön untereinanderstehen machst du dir also so einen Aufwand, aber dass
{return meshHolders_;}
ohne Einrückung, ohne Whitespaces und ohne Linebreaks (dafür mit bescheuertem Unterstrich am Ende) da steht, also quasi unlesbar, stört dich nicht?
Und wenn eine neue Methode dazukommt deren Returntyp dann "const ShaderModelVectorPtr" ist gehst du wieder hin und verschiebst alle Zeilen ein paar Leerzeichen weiter nach rechts? Und die Produktivität geht gegen null...

Ernsthaft, wer hier solchen Code schreiben würde würde sofort aus dem Team fliegen, ich geh mal davon aus dass das anderswo genauso ist. Für Lesbarkeit haben alle halbwegs modernen IDEs eine Outline Ansicht und ein automatisches Code Formatier Tool. Zum hübsch Einrücken werden hier keine Leute bezahlt.
Aber wenn man das als Hobby macht und niemand anders den Code lesen muss kann man das ruhig machen wenn man dann ebsser schlafen kann...

Das mit {} ist genau so eingerückt, hatte nur keine Lust mehr das hier im Forum geradezubiegen. Whitespaces sind ja umstritten. Und der Codeblock ist wesentlich besser lesbar als der darunter. Linebreaks habe ich probiert, die helfen so gut wie gar nicht. Die Produktivität dabei lass Mal meine Sorge sein. :p

Wenn bei euch Leute wegen so was aus dem Team fliegen, sind sie anscheinend wie Du genau so stur wie uneinsichtig, für Argumente schon im Voraus nicht offen, dafür aber lockerer mit der Zunge, wenn es um vorschnelle unsachliche Abwertungen mit "bescheuert" gibt. Deine Firma muss große Umsätze machen neben dem gegenseitig Köpfe einschlagen, denn was ich von den mir bekannten Unternehmen kenne, sollte so was nicht gerade im Kern der hitzigen Diskussionen stehen.

Und wenn Du jetzt vor lauter Wut schon deinen PC einschlägst, dann tut es mir Leid. Aber sobald Du einen neuen gekauft und meine Argumente angeschaut hast, bist Du herzlich dazu eingeladen sachliche Antworten dazu zu geben oder den Thread wieder zu verlassen.

Eisflamme schrieb:

Die Produktivität dabei lass Mal meine Sorge sein. :p

Gern, so lang andere Leute nicht mit dir zusammenarbeiten müssen ist das ganze auch gar kein Problem.

Eisflamme schrieb:

[...]sollte so was nicht gerade im Kern der hitzigen Diskussionen stehen.

Es gibt über sowas hier auch keine "hitzigen Diskussionen". Wie in jeder anderen Firma gibt es auch hier guidelines wie Code auszusehen hat. Wer sich nicht dran hält wird ermahnt/abgemahnt/rausgeworfen, da besteht genausowenig Diskussionesbedarf wie wenn einer in der Badehose ins Büro kommt.

Eisflamme schrieb:

Und wenn Du jetzt vor lauter Wut schon deinen PC einschlägst, dann tut es mir Leid. Aber sobald Du einen neuen gekauft und meine Argumente angeschaut hast, bist Du herzlich dazu eingeladen sachliche Antworten dazu zu geben oder den Thread wieder zu verlassen.

Ja, putzig, keine Sorge, da dein Beitrag relative inhaltsleer war was Argumente anging, außer "damit kann man die Methodennamen und Rückgabetypen besser lesen", was ja schon durch jede Outline View zerstört wurde, musst du noch ein bisschen stärker trollen bis ich meinen Kaffee vor lachen in die Tastatur rotze

Eisflamme

Und wenn es Code-Richtlinien gibt, halte ich mich auch daran. Aber was wir hier tun, ist diskutieren. Klingt, als hättest Du etwas zu tief ins Glas der Code-Richtlinien geschaut, wenn Du die mit dem Weisheits letzten Schluss gleichsetzt.

Wenn ich den Code wie oben schreibe, kann man ihn besser lesen als die nicht-formatierte Variante, also tue ich das. Eigentlich braucht es schon gar nicht mehr Argumente. Bestreitet hier jemand, dass man das besser lesen kann? Dass ich diese Auto-Codeformatierungs-Tools nicht nutze, hatte ich ja schon gesagt, da lasse ich mir auch gerne Ratschläge erteilen.

Ja, man kann den Code besser legen. Aber das auch nur so lange, wie die Einstellungen für Tab-Breite, etc. auf den Entwicklungssystemen gleich sind. Ist das mal nicht der Fall, dann hat man ein Problem.

Und was soll der Sinn des ganzen sein? Es gibt Dokumentationstools, die das weitaus besser darstellen können. Und nicht zuletzt macht die IDE selbst die Dokumentation (bei entsprechend gut gewählten Funktionsnamen) überflüssig.

Michael E.

Eisflamme schrieb:

Wenn ich den Code wie oben schreibe, kann man ihn besser lesen als die nicht-formatierte Variante, also tue ich das. Eigentlich braucht es schon gar nicht mehr Argumente. Bestreitet hier jemand, dass man das besser lesen kann?

Ich bestreite, dass die Methoden nötig sind, aber das ist ne andere Geschichte

Eisflamme

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.

volkard

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.

Michael E.

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.

Eisflamme

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.

Michael E.

Eisflamme schrieb:

Michael E.:
Dann sprichst Du sämtlichen Erzeuger-Pattern den Sinn ab?

Nö (sorry, hab grad keine Zeit, das weiter auszuführen).

volkard

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;

hustbaer

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 des inline Keywords nach der Klasse im selben Header File zu schreiben.

Eisflamme

Okay, das sind wirklich gute Argumente, überzeugt.

Ich bin nur stur, wenn man mich überreden will und dabei noch beleidigend ist.

abc.w

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.

Eisflamme

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.

hustbaer

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.

*Rewind*

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.