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.