Methode zu lang - Toxizitäts Metriken - FixInsight

[creehawk]

Moin.

Da programmiere ich so vor mich hin und entdecke in den Tools/Optionen Toxizitäts-Metriken.

Hübsch. Da google ich dann mal rum, was das eigentlich sein soll. So in etwa habe ich das begriffen. Dann die Software FixInsight, TMS, Trial - mal über das aktuelle Programm laufen lassen.
Au weia. Aber bitte, das meiste kann ich nachvollziehen, ist im wesentlichen immer das Gleiche:

'Unneeded boolean comparison' oder 'Variable is assigned twice successively'. Kein Problem.

Aber was ist bitte 'C101 Method 'TradeRouteCircle_2' is too long (64 lines)'

Leider klappt der Download der Dokumentations PDF nicht, ich kann nicht nachlesen was das bedeuten soll.
Aber was bitteschön kann an einer Methode zu lang sein? Diese Funktion baut aus 40 ArrayFeldern einen String zusammen der dann als Result zurückgegeben wird. Tja. Was bedeutet kruzifix 'zu lang'?

Das Programm läuft übrigens völlig problemlos. Seit 2005, mit laufenden Ergänzungen 2009, 2007, 2010, 2013, 2016. Momentan schrauben wir an Version 2018. Und die angegebene Funktion ist immer dabei, unverändert.

Wat nu? Egal? Nicht egal?

creehawk

[Der schöne Günther]

Du kannst einstellen was für deinen Geschmack zu lang ist. Du kannst das auch abschalten. Du kannst es auch für diese Methode einzeln den Hinweis unterdrücken indem du ans Ende der entsprechenden Zeile

Delphi-Quellcode:

//FI:C101

schreibst

[hoika]

Hallo,
der Entwickler des Tools ist halt der Meinung, dass eine Methode maximal 64 Zeilen lang sein soll.
Längere Methoden sollen aufgesplittet werden.

Vielleicht druckt er sich die Methode in Courier mit 4-er Schrifthöhe auf A4 aus
und es passen eben nur 64 Zeilen drauf? ;)

Ein anderes Tool zur Code-Analyse ist der Pascal Analyzer (PAL).
Der ist richtig gut, kostet aber was.

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1412496)

der Entwickler des Tools ist halt der Meinung, dass eine Methode maximal 64 Zeilen lang sein soll.
Längere Methoden sollen aufgesplittet werden.

Im Prinzip heißt das, dass man im Codeeditor eine Methode komplett sehen/überblicken soll, ohne scrollen zu müssen. (auch noch auf einem 15"-Monitor mit 800x600)

[Stevie]

Das Thema Methodenlänge ist höchst subjektiv - aber hier ein bisschen was zum Lesen:

https://softwareengineering.stackexc...method-for-you

https://martinfowler.com/bliki/FunctionLength.html

[creehawk]

Aha.

Danke für die Antworten Links, habe ich gelesen.

Zusammengefasst: Taten sind eher nicht notwendig. Was ich am meisten gelesen habe ist das Thema Übersichtlichkeit und aussagekräftige Benennung von Funktionen. Das die Teile dann ~ 80 Zeilen lang werden tut in unserem Fall der Sache keinen Abbruch. Zumal wir uns die Mühe machen - nicht zuletzt damit wir es auch noch nächstes Jahr verstehen - ausgiebig Kommentare zu verwenden. Auch die Namensgebung haben wir an die Lesbarkeit angepasst. Unser geprüftes Programm dient zur Erzeugung von Spielkarten Skripten für ein Computerspiel (Age of Empires), die angesprochene Function ist vom Namen her für jeden, des sich Programm ansieht und das Spiel kennt, völlig klar.

Wenn es also nur darum geht ob ich mal scrollen muss kann es mir also egal sein.

Ich hatte den Begriff Funktion bisher so aufgefasst: Bündeln einer öfter wiederkehrenden Aufgabe. Oder bündeln eines Abschnittes (bzw.mehrere Abschnitte) die man nach Bedarf einmal aufruft oder nicht. Beispiel: Winterlandschaft oder Sommerlandschaft.

Jedenfalls gehe ich davon aus das es Delphi wurscht ist ob die Funktion nun 20 oder 150 Zeilen lang ist. Oder liege ich falsch?

Toxizitäts Metriken lege ich jedenfalls unter 'Brauch` ich nicht' ab. In unserem Falle. Sollte ich mal ein Programm schreiben sollen für die Steuerung eines Raumschiffes kann ich mir das ja nochmal ansehen.

creehawk

[himitsu]

Jupp, Delphi ist es egal ... da kann am Ende auch der ganze Code nur in einer einzigen Funktion liegen. (z.B. bei einem Konsolenprogramm alles in der DPR nach dem BEGIN)

Es geht da wirklich nur um die Übersichtlichkeit/Wartbarkeit des Codes.
Im weiteren Sinne auch im die Testbarkeit. Ist eine große Methode nochmal unterteilt, dann kann man die Einzelteile auch getrennt testen.





Und notfals macht man sich eine {$REGION} in die Methode und faltet alles zu einer Zeile zusammen. :stupid:

[OlafSt]

Ja, hier hat sich einer einen Dreck um sowas geschert... Eine DLL, dient dem Ausdruck von Angeboten, Gesamt-, Zwischen- und Endrechnungen, Gutschriften, Mahnungen, Sammelrechnungen, Stornierungen und so weiter. Eben alles, was an Ausdrucken in einem Geschäft so anfällt. Außerdem werden diese Dokumente in PDF's übertragen, in der Datenbank wird alles sauber verbucht, dann für SAP zusammengestellt und in die benutzerabhängigen Dokumentablagen kopiert.

Alles in einer (in Zahlen: 1), 11k Zeilen langen Methode.

Darin einen Fehler zu suchen oder was zu ändern entfärbt die Haare besser als jeder Wasserstoffperoxid.

[Der schöne Günther]

Rekordverdächtig.

Da lobt man sich doch Refactoring-Tools wie MMX das einen einfach Text markieren und mit einem Hotkey in eine neue Methode auslagern lässt :-)

[OlafSt]

Habe ich schon versucht. Von den MMX-Tools habe ich erst kürzlich was mitbekommen und bin begeistert. Aber gegen sowas hier:

Delphi-Quellcode:

if (s_Art='Rechnung') or (s_Art='Endrechnung') or (s_Art='Gutschrift') then
begin
   //900 Zeilen Code
   if (s_Art = 'irgendwas') then
      ...
end;

if (s_Art='Angebot')  then
begin
   //300 Zeilen Code
end;

Da ist nix mit Refactoring und/oder Auslagern in extra Methoden. Das Ding ist ein Meisterwerk des unentwirrbaren Spaghetti-Codes.

[himitsu]

Delphi-Quellcode:

if MatchStr(s_Art, ['Rechnung', 'Endrechnung', 'Gutschrift']) then
   MethodeFürRechnungen(...);

if s_Art = 'Angebot' then
   MethodeFürAngebote(...);

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1412533)

Delphi-Quellcode:

if MatchStr(s_Art, ['Rechnung', 'Endrechnung', 'Gutschrift']) then
   MethodeFürRechnungen(...);

if s_Art = 'Angebot' then
   MethodeFürAngebote(...);

oder

Delphi-Quellcode:

if IsRechnungsArt(s_Art) then
   MethodeFürRechnungen(...);

if IsAngebotsArt(s_Art) then
   MethodeFürAngebote(...);

oder, wenn es sich gegenseitig ausschließt

Delphi-Quellcode:

if IsRechnungsArt(s_Art) then
   MethodeFürRechnungen(...)
else if IsAngebotsArt(s_Art) then
   MethodeFürAngebote(...);

oder

Delphi-Quellcode:

case GetArt(s_Art) of
  artRechnung: MethodeFürRechnungen(...);
  artAngebot: MethodeFürAngebote(...);
  ...
else
  raise EInvalidArtExcetion.Create('unbekannte Art: ' + s_Art);
end;

Auch der weiteste Weg beginnt mit einem ersten Schritt. (Konfuzius)

[sh17]

Zitat:

Zitat von OlafSt (Beitrag 1412527)

Habe ich schon versucht. Von den MMX-Tools habe ich erst kürzlich was mitbekommen und bin begeistert. Aber gegen sowas hier:

[Delphi]
if (s_Art='Rechnung') or (s_Art='Endrechnung') or (s_Art='Gutschrift') then
begin
//900 Zeilen Code
if (s_Art = 'irgendwas') then
...
end;
Da ist nix mit Refactoring und/oder Auslagern in extra Methoden. Das Ding ist ein Meisterwerk des unentwirrbaren Spaghetti-Codes.

Ablaufsteuerung durch casesensitive Strings - krass - nicht mal Konstanten verwendet, ich hoffe es gibt wenigstens ein Handbuch zur Funktion

[OlafSt]

Nope. Das ganze ist auch absolut hervorragend dokumentiert und kommentiert. Kommentare sind drin, jede Menge: Auskommentierter Code, weil geändert und Fehlerbehebungen mit Kürzel wer und wann.

Kommentare mit erklärender Funktion gibt es - wenn man meine hinzugefügten abzieht - genau gar keinen.

Wäre die Routine so aufgebaut, wie die Vorschreiber es sich vorstellen, hätte ich mich da auch mal dran gewagt. Ihr geht davon aus, das das ganze logisch nach Funktion gegliedert ist. Das würde das Refactoring tatsächlich vereinfachen. Aber so ist das Ding nicht gebaut.

Das Teil ist so strukturiert, wie ein Drucker arbeitet :shock:. Am Anfang des Blattes gibt es [Code]. Die Zeile darunter ist aber für Kunden "BCD" anders, also [Code mit Ausnahme]. Dann muß da ja n Firmenlogo kommen, also [Je nach s_Art [je nach Kunde [Code]]. Hab ich schon das Seitenende erreicht ? Ach ja, englische Texte brauchen wir ja auch noch... Und so weiter. Zusätzlich wird etwa ein dutzend SQL-Queries geöffnet, je nach s_Art und Kunde mit anderen Statements versehen; da werden Formulare geöffnet (weil die nicht wußten, wie man sonst Klassen erzeugt) und in versteckte Edit-Felder Werte eingetragen (keine Ahnung von Properties gehabt) und dann im OnChange-Handler jeweils s_Art- und Kunde-Abhängige Dinge gemacht. Wirklich benutzt wird das dann 5k Zeilen weiter unten...

Wie schon gesagt, Spaghetti-Code vom allerfeinsten. Das auseinander zu sortieren hat schon mal einer versucht und es nach 3 Monaten aufgegeben, weil die zahllosen Seiteneffekte einfach nicht mehr beherrschbar waren.

Letztlich geht es aber nicht um dieses "Meisterwerk der Software-Entwicklung". Man kann tatsächlich Code produzieren, mit dem man nur noch eines machen kann: Löschen, weil selbst so coole Tools wie MMX einfach nicht mehr gegenan kommen. Zum Glück ersetzen wir diesen Müll sukzessive durch wartbaren und besser dokumentierten (weil meinen :-D) Code.

[Schokohase]

Zitat:

Zitat von OlafSt (Beitrag 1412550)

Kommentare mit erklärender Funktion gibt es - wenn man meine hinzugefügten abzieht - genau gar keinen.

Das ist das eigentliche Problem, warum so ein Moloch auch nicht mal eben so komplett neu geschrieben werden kann.

Niemand weiß ganz genau was da so passiert/passieren muss.

Das kann man nur in das Nachtgebet einschließen und hoffen ...

[p80286]

Zitat:

Zitat von OlafSt (Beitrag 1412550)

Letztlich geht es aber nicht um dieses "Meisterwerk der Software-Entwicklung". Man kann tatsächlich Code produzieren, mit dem man nur noch eines machen kann: Löschen, weil selbst so coole Tools wie MMX einfach nicht mehr gegenan kommen. Zum Glück ersetzen wir diesen Müll sukzessive durch wartbaren und besser dokumentierten (weil meinen :-D) Code.

MMMM.
Da ich weiß, wie es zu solchen Monstern kommen kann (mach doch mal eben schnell), würde ich nicht so hart urteilen. Was Du da vor Dir hast, ist das Ergebnis jahrelangen Bastelns ohne ein eigentliches Konzept. Um mit Klassen zu arbeiten muß, man erst einmal entsprechende Denkstrukturen entwickeln. Und wer nicht "strukturiert" denken kann ist da wohl erst einmal vollkommen überfordert.

Gruß
K-H

[dummzeuch]

Zitat:

Zitat von OlafSt (Beitrag 1412550)

Zum Glück ersetzen wir diesen Müll sukzessive durch wartbaren und besser dokumentierten (weil meinen :-D) Code.

LOL, der war gut!

Ich schätze mal, in diese Situation kommt jeder, der den Code anderer warten muss. Selbst ein genialer Softwareentwickler hat mal einen schlechten Tag (der wird unter Zeitdruck gesetzt) und produziert dann Müll, den er nach ein paar Monaten selbst nicht mehr versteht.

Mir zumindest passiert das, aber ich bin ja auch nicht genial.

[Stevie]

Zitat:

Zitat von dummzeuch (Beitrag 1412585)

Zitat:

Zitat von OlafSt (Beitrag 1412550)

Zum Glück ersetzen wir diesen Müll sukzessive durch wartbaren und besser dokumentierten (weil meinen :-D) Code.

LOL, der war gut!

Ich schätze mal, in diese Situation kommt jeder, der den Code anderer warten muss. Selbst ein genialer Softwareentwickler hat mal einen schlechten Tag (der wird unter Zeitdruck gesetzt) und produziert dann Müll, den er nach ein paar Monaten selbst nicht mehr versteht.

Mir zumindest passiert das, aber ich bin ja auch nicht genial.

Ich hab mal irgendwo ein Zitat gelesen, was ungefähr so lautete: "Wenn man seinen Sourcecode von <irgendwann in der Vergangenheit> heute nicht für verbesserungswürdig hält, dann hat man sich nicht weiterentwickelt/verbessert". Also auf alle, die ihren Sourcecode von vor drei Monaten heute sch*** finden. :cheers:

[jaenicke]

Das Gefühl kenne ich nur zu gut...
"Ach du Sch***, was hast du denn damals da gemacht..."

Leider hilft das Wissen darüber nichts dagegen, dass es ein Riesenaufwand ist das ganze heute dann in besseren Code zu verwandeln. :|

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1412603)

Das Gefühl kenne ich nur zu gut...
"Ach du Sch***, was hast du denn damals da gemacht..."

Leider hilft das Wissen darüber nichts dagegen, dass es ein Riesenaufwand ist das ganze heute dann in besseren Code zu verwandeln. :|

Aber besser heute anfangen da aufzuräumen, denn im Allgemeinen wird sowas mit der Zeit nur noch viel schlimmer.

Es muß auch nicht auf biegen und brechen sofort perfekt werden.
> Die eine übergroße schlimme Funktion in ein paar kleinere weniger Schlimme, das ist auch schon ein Fortschritt.

[p80286]

Zitat:

Zitat von dummzeuch (Beitrag 1412585)

Mir zumindest passiert das, aber ich bin ja auch nicht genial.

Du mußt Dich entscheiden, unverständlich und genial
oder
temporär umnachtet und (schwer) nachvollziebar ........

:wink:

Gruß
K-H

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1412603)

Das Gefühl kenne ich nur zu gut...
"Ach du Sch***, was hast du denn damals da gemacht..."

Oft auch: "Welcher Vollidi..." *klick auf blame* "... oh, ich, ach das hatte bestimmt einen Grund!..." :oops:

[Rollo62]

Zitat:

Wenn man seinen Sourcecode von <irgendwann in der Vergangenheit>

Das hast du in 95% der Fälle Recht.

<Ohne Eigenlob>
Mir passiert es aber auch manchmal das ich sage: Wow, das habe ich damals aber ziemlich cool gelöst :stupid:
</Ohne Eigenlob>

Rollo

[OlafSt]

Ich habe nie behauptet, das ich genial sei :-D Schaue ich mir meinen Code von vor 10 Jahren (oder noch älter) an, schüttel ich auch manchmal nur den Kopf :P

Ich laufe der Jahre und Jahrzehnte habe ich aber eines sehr einprägsam gelernt: Mein Code verfolgt mich über Jahre und kommt immer wieder auf den Tisch. Wenn du dann nicht mehr kapierst, was das mal werden sollte, ist das nicht so toll :-D

Aber so einen Abgrund wie diese DLL ist mir das letzte Mal ~1987 passiert - das war ein BASIC-Programm für den C64, das ich irgendwann einfach nicht mehr durchstiegen habe. War eine lehrreiche Erfahrung :lol:

[Jumpy]

[Offtopic]
Ich vertrete jetzt mal mit einem Augenzwinkern die Gegenposition:

Genial waren eigentlich die Leute, die diese Mamut-Funktionen entwickelt und beherrscht haben. Bei uns sind da auch die letzten mittlerweile in Rente. Das waren noch Leute, die auf Großrechnern groß geworden sind und die bestimmte Zeitfenster an Prozessorzeit für ihre Programme bekommen haben. Es wurde funktional alles in einem rutsch runter programmiert. War ein Fehler drin, musste man das im Kopf anhand der Ausgabe debuggen und konnte es am nächsten Tag vielleicht nochmal neu probieren. Als folge lernte man schnell alles im Kopf durchzuspielen und zu bedenken und machte weniger Fehler.

Was wir da heute an Tools und Möglichkeiten haben erleichtert uns das alles sehr, macht uns aber umgekehrt auch dümmer. Das mein ich jetzt vielleicht weniger auf die einzelne Person bezogen, mehr auf die Gesellschaft oder Generationen als Ganzes.
Beispiel: Drück mal einem 25jährigen Autofahrer einen Shell-Atlas in die Hand und sag ihm er soll damit mal von Köln nach Buxtehude fahren (Ausnahmen bestätigen die Regel).

In dem Sinne: Schönes Wochenende

[/Offtopic]

[Rollo62]

Das meine ich.
Es gibt eben auch Dinge die waren damals richtig, und sind es heute auch noch.

Man muss nicht immer den letzten Trend hinterherjapsen, denn die einfachen, soliden Lösungen sind of die Besten, zumindest für mich (StateMachine wäre so ein Konzept was ich schon seit Urzeiten benutze).

Rollo

[freimatz]

Zitat:

Zitat von p80286 (Beitrag 1412560)

Da ich weiß, wie es zu solchen Monstern kommen kann (mach doch mal eben schnell), würde ich nicht so hart urteilen.

Ich schon. Sorry. Ich weiß auch wie es zu langen Methoden kommt. Aber eine Methode mit 11k macht man nicht mal so eben.

Zitat:

Zitat von p80286 (Beitrag 1412560)

Was Du da vor Dir hast, ist das Ergebnis jahrelangen Bastelns ohne ein eigentliches Konzept. Um mit Klassen zu arbeiten muß, man erst einmal entsprechende Denkstrukturen entwickeln. Und wer nicht "strukturiert" denken kann ist da wohl erst einmal vollkommen überfordert.

Ja schon, aber nur "erst einmal". Dann soll man sich halt mal Hilfe holen. (Mache ich ja auch immer wieder) Wenn man nicht voll blöd ist kommt man ja auch mal auf die Idee nach "Delphi Forum" zu googeln. :wink:
Auch ich stimme den Vorredner zu: Jeder hat mal nen schlechten Tag, jeder findet seinen alten Code teilweise schlecht...
Aber es geht ja auch darum etwas daraus zu lernen und es dann besser zu machen.
Und die Zeiten wo die Ressourcen knapp waren sind nun ja wirklich vorbei.