Code Complexity reduzieren



  • Hi zusammen

    ich stehe gerade kurz vor einem größeren Release und möchte die Zeit nutzen, um die Komplexität der Applikation zu reduzieren. Zum Messen der Komplexität habe ich das Tool "SourceMonitor" verwendet und mir den entsprechenden Kiviat-Graph dargestellt.

    Eine Untersuchung ergab, dass es eine Funktion mit einer Komplexität von 43 gibt, die eigentlich im Prinzip daraus besteht:

    switch ( msgtype )
    {
        case MSG_TYPE_A : Tu etwas; break;
        case MSG_TYPE_B : Tu etwas anderes; break;
        case MSG_TYPE_C : Tu etwas ganz anderes; break;
        ...
        ...
        ...
    }
    

    Es handelt sich dabei um die Eingangsseite des Servers, wo die Requests vom Client aufschlagen.

    Mir fallen hier allerdings keine großartigen Verbesserungsmöglichkeiten ein, die die Komplixität reduzieren würden...

    Jemand ne Idee? Oder mach ich mir hier grundlos Gedanken?



  • Wenn sie im Rahmen der Anwendung einfach zu verstehen, einfach zu reparieren und einfach zu erweitern ist, würde ich sie so lassen.
    Da traue ich dem jeweiligen Entwickler mehr als einem Tool.



  • man könnte eine map<int, fct_type> nehmen, die dem msgtype einen passenden Funktionszeiger zuordnet. Dann statt switch ... case den Funktionszeiger aus der map holen und ausführen. Das setzt natürlich voraus, daß die Befehle hinter case ... uniform sind, was Variablenabhängigkeiten angeht.

    Falls der log Suchaufwand in der map nicht akzeptabel ist: Array fct_type[]. Schneller als switch ... case wird es dadurch aber nicht.



  • Wahrscheinlich bewertet SourceMonitor intern das wie eine große if-else Kaskade, die dann zu der Komplexität führt. Im Sinne von Wartbarkeit finde ich das Case-Konstrukt aber besser zu verstehen als maps mit Funktionszeigern (macht der Compiler intern ab einer gewissen Größe eh daraus).

    Das einzige, was Du überlegen könntest wäre, größere "Tu-Was"-Blöcke in separate funktionen/methoden zu verlagern



  • Ich weiß nicht, was im jeweiligen tuwas steht. Evtl kann es sonnig sein, diese Blöcke in eigene Funktionen auszulagern.

    switch ( msgtype )
    {
        case MSG_TYPE_A : tuwas_A(); break;
        case MSG_TYPE_B : tuwas_B(); break;
        case MSG_TYPE_C : tuwas_C(); break;
        ...
        ...
        ...
    }
    

    Falls das Tool dann immer nochg weint, isses kaputt.
    Mit

    tuwasTable[MSG_TYPE_A]();
    

    kannste es zwingen, die Klappe zu halten. Aber ob das noch sonnig ist?



  • Ich kann es leider nicht zwingen, diese Funktion einfach zu ignorieren, aber ich werde das so hinnehmen, denn ein switch ist so ziemlich die einfachste Konstruktion überhaupt. Die Lesbarkeit / Wartbarkeit des Quellcodes ist ja hier nicht gefährdet.

    Vielen Dank für eure Meinungen. Gut zu wissen dass ich, was das angeht, nicht total auf dem Holzweg bin 😉



  • Ich denke solche Code-Metriken haben hauptsächlich Sinn potentiell problematischen Code in großen Codebases ausfindig zu machen.
    Den Code wider besseres Wissen anzupassen, nur damit die Metrik einen niedrigeren Wert ausspuckt ist garantiert eine schlechte Idee.
    Wie sollte so ein einfaches Verfahren auch bei all der Komplexität der Programmierkunst für alle Fälle "den besten Code" bestimmen, und ihn auf eine einzige Zahl eindampfen können?

    Finnegan



  • Wikipedia meldet, daß beim switch noch mehr Leute wisersprechen...
    https://de.wikipedia.org/wiki/McCabe-Metrik#Kritik

    edit: welche Sprache ist das im Link?



  • asdfghj schrieb:

    Wahrscheinlich bewertet SourceMonitor intern das wie eine große if-else Kaskade, die dann zu der Komplexität führt

    Siehe Link von volkard.

    Ich finds echt blödsinnig, hier irgendwas umbauen zu wollen, weil ein Tool meint, dass es komplex wäre. Vor allem wenn der Code so offensichtlich völlig in Ordnung ist.
    Und überhaupt finde ich diese Metriken sehr selten sinnvoll. Die Komplexität einzelner Methoden ist selten großartig interessant. Und komplexe Zusammenhänge zwischen Modulen erkennen solche Tools nicht. Und selbst wenn Entwickler selbst die Komplexität erkennen, ist das auch noch lange kein Grund, sofort irgendwas umzubauen.


Log in to reply