Reduzieren iterative Methoden die zyklomatische Komplexität und verbessern sie die Unterstützbarkeit?

Reduzieren iterative Methoden, wie sie üblicherweise in modernen Sprachen wie C #, JavaScript und (hoffentlich) in Java 8 zu finden sind, die Auswirkungen der zyklomatischen Komplexität auf die Verständlichkeit und Unterstützbarkeit von Code?

Zum Beispiel könnten wir in C # den folgenden Code haben:

List<String> filteredList = new List<String>();

foreach (String s in originalList){
   if (matches(s)){
      filteredList.add(s);
   }
}

Dies hat eine einfache zyklomatische Komplexität von 2.

Wir könnten dies leicht umschreiben als:

List<String> filteredList = originalList.where(s => matches(s));

Welches hat eine einfache zyklomatische Komplexität von 0.

Führt dies tatsächlich zu mehr unterstützbarem Code? Gibt es aktuelle Forschungsergebnisse zu diesem Thema?

Ich vermute, dass Sie gerade die Komplexität geteilt / verschoben haben. Es wurde verringert, weil Sie die Implementierung .where()in Ihrem CC nicht zählen .

Der Gesamt-CC hat sich nicht wirklich verschoben, der CC Ihres eigenen Codes hat sich verringert, nur weil er jetzt in den Code des Frameworks verschoben wurde.

Ich würde sagen, es ist wartbarer. Wenn es ein Merkmal der Sprache ist, verwenden Sie es. Es ist kein "ohh, ich verstehe, es ist ein cleverer Trick" , den Sie verwenden, sondern nur eine einfache Inline-Reduktionsfunktion.

Alles, was Sie tun, ist, einen Fehler in der zyklomatischen Komplexität als Metrik hervorzuheben. Die Komplexität des Codes hat sich wirklich nicht geändert. Sie haben im ersten Beispiel einen expliziten Zweig und müssen verstehen, dass im zweiten ein impliziter Zweig vorhanden ist. Die zweite ist klarer und leichter zu verstehen, vorausgesetzt, Sie verstehen die Syntax und da sie weniger grundlegende Syntax verwendet, kann dies ein Problem sein.

Um die Frage objektiv zu beantworten, benötigen wir eine Art Metrik für die Wartbarkeit. Die zyklomatische Komplexität selbst ist kein Maß für die Wartbarkeit, aber sie ist Bestandteil einiger Metriken, die vorgeben, die Wartbarkeit zu messen. Die Formel für den Wartbarkeitsindex lautet beispielsweise:

MI = 171 - 5.2 * ln(V) - 0.23 * (G) - 16.2 * ln(LOC)

Wo Gist die zyklomatische Komplexität des betreffenden Codes? Daher verbessert das Reduzieren der zyklomatischen Komplexität eines Codeteils per Definition den Wartbarkeitsindex des Codes und andere Metriken, die ebenfalls die zyklomatische Komplexität verwenden .

Es ist schwer zu sagen, ob die Art der Änderung, die Sie vorschlagen, das Programm für Programmierer wartbarer erscheinen lässt . Das hängt wahrscheinlich davon ab, wie vertraut sie (in Ihrem Fall) mit der whereMethode sind.

Weil gezeigt wurde, dass die zyklomatische Komplexität (CC) sehr stark mit der Codegröße korreliert, "so sehr, dass man sagen kann, dass CC absolut keine eigene Erklärungskraft hat". Was Sie wirklich fragen, ist, ob "iterative Methoden, wie sie üblicherweise in modernen Sprachen wie C #, JavaScript und (hoffentlich) in Java 8 zu finden sind, die Auswirkungen der Codegröße auf die Verständlichkeit und Unterstützbarkeit von Code verringern."

An diesem Punkt würde man hoffen, dass die Antwort offensichtlich wäre. Es ist seit Jahrzehnten bekannt, dass kürzerer Code im Allgemeinen leichter zu verstehen, zu warten und zu unterstützen ist.

Wenn Sie über den Rohzustand der zyklomatischen Komplexität sprechen, sicher. Sie haben es nur von 2 auf 0 gebracht. Wenn Sie nach Zahlen gehen, dann nach reinem Gewinn.

Aus praktischer (sprich: menschlicher) Perspektive würde ich jedoch argumentieren, dass Sie die Komplexität tatsächlich um 2 erhöht haben . Ein Punkt davon ist die Tatsache, dass jetzt ein anderer Programmierer Kenntnisse über die fließende Syntax LINQ mitbringen oder erwerben muss, um dies zu verstehen Code.

Ein weiterer Punkt mit erhöhten Schwierigkeiten ergibt sich aus dem Verständnis der Lambda-Ausdrücke. Obwohl ein Lambda in diesem Fall ziemlich einfach ist , müssen einige Paradigmenwechsel vorgenommen werden, um sie vollständig zu würdigen.

In diesem Fall ist die Verwendung a.where(x => matches(x, arg))nicht schrecklich, und ehrlich gesagt ist dies eine großartige Möglichkeit, um Mitarbeiter dazu zu bringen, LINQ- und Lambda-Ausdrücke zum ersten Mal zu sehen und damit zu arbeiten (ich habe einigen ehemaligen Mitarbeitern, die dies verwenden, tatsächlich ein Tutorial zu LINQ / Lambdas vorgestellt und andere Codesätze mit großer Wirkung.) Die Verwendung dieser erfordert jedoch einige Kenntnisse.

Ich empfehle Vorsicht, da ich Fälle gesehen habe, in denen der LINQ-Refaktor tatsächlich wesentlich schlechter zu lesen ist als das, was diese foreachSchleife wird.

Subjektiv hängt es vom Entwicklerpublikum ab, ob es Lambda-Ausdrücke versteht.

List<String> filteredList = originalList.where(s => matches(s));

ist schneller zu verstehen und vielleicht etwas einfacher. Ich wäre mehr besorgt über die Verwendung von s und Übereinstimmungen (). Weder ist selbstbeschreibend, so etwas wie;

List<String> filteredList = 
    originalList.where(stringToBeTested => matchesNameTest(stringToBeTested));

Oder

List<String> filteredList = 
        originalList.where(originalListString => matchesNameTest(originalListString));

gibt dem Entwickler aussagekräftigere Informationen und ist einfacher zu analysieren, ohne in die Funktion match () eintauchen zu müssen, um festzustellen, welche Übereinstimmung ausgeführt wird.

Bei der Wartbarkeit geht es nicht nur um die Fähigkeit, den Code zu verstehen, sondern hauptsächlich um die Geschwindigkeit und Genauigkeit, mit der man den Code verstehen kann.