Programmierstil?

zwutz schrieb:

just another c hacker schrieb:

Sieht schön aus, ist übersichtlich, Fehler werden schnell erkannt und ein guter Editor unterstützt einen noch dazu.

ein guter Editor zeigt dir alle Funktionen und Methoden in einem extra Fenster an

Ich hasse diese ewigen Anpassungen am Codeaussehen, wenn eine Methode hinzugefügt wurde. Oder sich anderweitig die Länge geändert hat.
Der Code sollte so geschrieben werden, dass Änderungen keinen Einfluss auf die Struktur des restlichen Codes haben sollten. Ich seh in den diffs immer so Späße. Plötzlich kommt 90% der Datei als modified daher, nur weil jemand überall ein Leerzeichen hinzufügen musste, damit es wieder glatt aussieht.

Dann einigt man sich halt voher, wie das ganze auszusehen hat und wie lange Funktionsnamen, etc. maximal sein dürfen, usw. usf.

EOutOfResources

~codingstyle schrieb:

wie lange Funktionsnamen, etc. maximal sein dürfen, usw. usf.

Wer macht das?

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.