Programmierstil?

-1 und das Spiel ist gekehrt

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

Für das Beispiel von Jockelx tippt man

bla     = "bla");
blubbe  = "bla");
blubbla = "blubbla");
M-b C-<SPC> C-p C-p C-x r t getValueOf("<RET>

(letzeres ist ein Editor-Command in Emacs. M=Alt, C=Control)

Dass das Problem von Eisflamme auch in gutem Code auftritt zeigt folgender Code aus GTK+ (ist halt C):

gboolean   gtk_widget_activate               (GtkWidget        *widget);
gboolean   gtk_widget_set_scroll_adjustments (GtkWidget        *widget,
                                              GtkAdjustment    *hadjustment,
                                              GtkAdjustment    *vadjustment);

void	   gtk_widget_reparent            (GtkWidget           *widget,
                                           GtkWidget           *new_parent);
gboolean   gtk_widget_intersect           (GtkWidget           *widget,
                                           const GdkRectangle  *area,
                                           GdkRectangle        *intersection);
GdkRegion *gtk_widget_region_intersect    (GtkWidget           *widget,
                                           const GdkRegion     *region);

void	gtk_widget_freeze_child_notify    (GtkWidget           *widget);
void	gtk_widget_child_notify           (GtkWidget           *widget,
                                           const gchar         *child_property);
void	gtk_widget_thaw_child_notify	  (GtkWidget	       *widget);

*Rewind*

Wie du das machst ist am Ende dir überlassen. Es soll nur möglichst übersichtlich und konsistent sein. Ich bevorzuge diese Variante (mit Leerzeichen und line breaks):

int main()
{
    int a=3, b=5;
    for (int i = 0; i < b; i++)
    {
        if (a--)
            break;
        else
        {
            a++;
            b--;
        }
    }
    return 0;
}

Da wäre es ja glatt schön, wenn der Funktionsname zuerst käme:

GetMeshHolders: () -> MeshHolderVector&;
GetMesh: () -> Mesh&;
GetMaterialMap: (int Par1, string Par2) -> MaterialMap&;

Oder so.

P.S.: +1

int main()
{
    int a=3, b=5;

    for (int i=0; i<b; i++) {
        if (a--) {
            break;
        } else {
            a++;
            b--;
        }
    }
}

[/quote]

Eisflamme

asdgg, das zählt nicht.

zwutz

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.

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.