Code-Optimierungen: allgemeine Fragen

[venice2]

Zitat:

Muss auf den Bildschirm passen

Na dann viel Spaß wenn du mal richtig mit Winprocs arbeitest zeig mir mal wie du diese in einzelne Häppchen verteilen willst.
Es sei denn du erstellst für jede Message eine eigene Funktion.
Seltsame Programmoptimierung die was bringt? Nichts!

[TigerLilly]

Zitat:

Zitat von venice2 (Beitrag 1459844)

Seltsame Programmoptimierung die was bringt? Nichts!

Wie so oft: für alles gibt es Ausnahmen, aber für unseren Code passen diese Regeln gut + haben sich bewährt.

[Sherlock]

Es ist schlicht so, daß Übersichtlichkeit auch in der SW-Entwicklung das A und O ist. Wenn eine Methode auf eine Bildschirmseite paßt, ist sie für jeden Menschen leichter zu erfassen als wenn es nicht so ist. Natürlich kann es Ausnahmen geben, wo es nicht anders geht. Aber man sollte es zumindest versuchen, den Code so zu restrukturieren, daß es paßt.

Sherlock

[Rollo62]

Zitat:

Zitat von Harry Stahl (Beitrag 1459834)

Wenn es Sinn macht und es geht, kann man einen Teil der Logik in mehrfach verwendbare Code-Teile aufteilen, wo es nicht geht, ist die Funktion eben auch mal 200 oder 300 Zeilen lang...

Solche festen Regeln können viel Sinn machen, das ist Richtig.
Es sollte aber auch immer mal Ausnahmen geben dürfen, so sehe ich das auch.

Was ich aber Wichtiger oder besser als Ergänzung zu solchen numerischen Beschränkungen sehe,
ist eine generelle, gut lesbare Formatierungsstruktur der Texte.
Zum Beispiel formatiere ich Texte meist so das alle ":" untereinander stehen, um Variable/Typ auch optisch sauber zu trennen.
Auch lege ich mittlerweile immer Alles mit Indent 4 tatt 2 an, weil dadurch der Code aus meiner (und Anderer) viel lesbarer wird.

Mit guter Formatierung erkennt man auf einem Blick Zusammenhänge, und auch (Tipp)fehler viel schneller und direkter.
Zusätzlich ist die "Formatierungsarbeit" eine gute Gelegenheit den Code nochmal Revue passieren zu lassen, und eventuell zu überdenken und zu überarbeiten.

Was nützt mir ein gequetschter Spaggetticode ohne Punkt und Komme auf einer Seite, wenn ich diesen dann nur schwer wieder entschlüsseln kann ?
Alternativ würde ich diesen durch saubere Formatierung viel lesbarer bekommen, auch wenn er womöglich etwas länger wird als geplant.

Es gibt ja nicht Umsonst den Beruf der Designer, welche sich mit Schriften, Layout, Darstellung beschäftigen, weil es eben gewisse physiologische/psychologische Gegebenheiten gibt die man auch im Code beachten sollte.

[TiGü]

Ich möchte dir folgende zwei Seiten/Links ans Herz legen:

https://clean-code-developer.de/

Und wenn du soweit bist ("Note that these manuals are not for beginners."):
https://www.agner.org/optimize/

[Rollo62]

Ooooh, die Bibel.
Ja wenn ich gegen das Wertesystem verstosse komme ich wohl in die Hölle :evil:

[freimatz]

Zitat:

Zitat von DieDolly (Beitrag 1459831)

20 Zeilen? Das klingt nach einem Ding der Unmöglichkeit.

In dem Beitrag davor steht ganz unten:
Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht. :lol:

Es geht. Man kann es lernen wenn man will.

Ich finde es super, dass Du schon so viel gemacht hast.

Zitat:

Zitat von TiGü (Beitrag 1459850)

Ich möchte dir folgende ... Seiten/Links ans Herz legen:
https://clean-code-developer.de/

metoo

[Hobbycoder]

Gelöscht

[jfheins]

Wir machen in letzter Zeit mehr typescript, aber da gelten eigentlich letztlich die gleichen Sachen wie überall.

Wir versuchen, Funktionen klein zu halten und Logik zu kapseln, damit es übersichtlich bleibt. Es gibt dennoch harte Limits: Wir haben den linter aktiv, sodass code Änderungen pauschal abgelehnt werden, falls die cyclomatische Komplexität einer Funktion zu groß ist oder die Datei länger ist als 300 Zeilen.

[Nersgatt]

Ich halte mich nicht strikt an irgend eine Zeilenzahl, allerdings sind meine Methoden auch eher kurz. Vor allem die Grundsatz, "eine Aufgabe, eine Methode" ist für mich wichtig. Auch wenn ich Codeteile mehrfach brauche, extrahiere ich eine Methode/Funktion, selbst wenn diese nur aus 1-2 Zeilen bestehen sollte.
Manchmal sieht man in Quellcode, dass innerhalb einer Methode bestimmt Blöcke mit Kommentaren abgetrennt werden, was irgendwie so aussieht.

// ********* Bla bla ********
Irgend ein Code

// ********* Bla blubb ********
Noch mehr Code

// ********* Schwuppdiwupp ********
Ganz viel Code

Solche Konstrukte schreien förmlich danach, refaktoriert zu werden und in einzelne Methoden überführt zu werden.