PyDay: Statische Codeanalyse für Python

Letzte Änderung am 7. März 2016 by Christoph Jüngling

Es gibt eine Binsenweisheit, die wohl jeder Programmierer kennt: Es gibt keinen fehlerfreien Code, höchstens fehlerarmen. In dem Bestreben, unseren Code möglichst fehlerarm zu schreiben, haben wir nicht nur in der Pyday-Artikelserie bereits einige Methoden kennengelernt:

  • Modularisierung führt zu größerer Übersicht
  • Unit-Tests überprüfen ständig das gewünschte Ergebnis
  • Code-Reviews helfen uns, vom Erfahrungsschatz und dem unverstellten Blick der Kollegen zu profitieren

Diese Kriterien und Tests haben das Ziel, dass unser Programmcode das gewünschte Ergebnis liefert. Tests können aber auch ganz andere Baustellen adressieren. Ein wichtiger Punkt dabei ist die Frage, ob unser Code gut lesbar ist. Dabei kann uns die Codeanalyse helfen.

Warum muss Programmcode “schön” sein?

Frage einen Kaufmann, ob du Zeit bekommst, um den Code “schön” zu machen, und er wird vermutlich antworten: “Was soll der Blödsinn, es funktioniert doch, oder?” Sobald du aber den Spaghetti-Code eines Kollegen stunden- oder tagelang analysieren musst, um festzustellen, was er damit bezwecken wollte, wirst du dich dafür ohrfeigen, dem nicht eher entgegengetreten zu sein. Und dein Chef ebenfalls, denn so etwas kostet Zeit. In diesem Artikel habe ich das noch abgewertet, aber letzten Endes gibt es doch einen Grund, dass Programmcode schön sein sollte.

Für die Codeanalyse von Python-Code gibt es das Werkzeug PyLint, das von unserer verwendeten Entwicklungsumgebung (PyDev unter Eclipse) bereits hervorragend unterstützt wird. Doch lassen wir zunächst Wikipedia zu Wort kommen (Quelle):

Lint war das erste einer ganzen Reihe von Werkzeugen zur statischen Code-Analyse von Quelltext von Computerprogrammen. Sein hauptsächlicher Verwendungszweck war es, die Schwächen der damals existierenden Compiler auszugleichen. Diese setzten über weite Strecken richtigen Quellcode voraus und führten nur rudimentäre Prüfungen durch.

Neben dem Aufspüren von gefährlichen Konstrukten (…) legte Lint auch großes Gewicht auf die Überprüfung eines einheitlichen Layouts des Quelltextes und auf das Erkennen nicht portabler Konstrukte, wie etwa Abhängigkeiten vom Betriebssystem oder vom Compiler.

Der Name Lint leitet sich von der englischen Bezeichnung für unerwünschte Anteile an Fasern und Flaum in Schafwolle ab.

Installation

Um PyLint für unsere Projekte nutzbar zu machen, müssen wir es zunächst installieren. Das geht recht einfach:

pip install pylint
Einstellung des Pfades zur PyLint-Datei (statische Codeanalyse)

Einstellung des Pfades zur PyLint-Datei

Dann müssen wir in den Eclipse-Preferences einstellen, wo sich die ausführbare Datei von PyLint befindet. Diese wird unter Windows (als pylint.exe) im Unterverzeichnis “site-packages” des Installationsordners von Python sein. Unter Linux habe ich die Quellcodedatei (auch die darf es sein) unter “/usr/local/lib/python3.4/dist-packages/pylint/lint.py” gefunden. Wenn das alles nicht hilft, öffne eine Python-Konsole und führe folgende Befehle aus:

import site
site.getsitepackages()

Dies gibt eine Liste mit den Ordnern aus, in denen Python nach solchen Programmen sucht. In einem davon sollte pylint zu finden sein.

Codeanalyse in der Anwendung

Für die Anwendung müssen wir kaum noch etwas machen. In dem oben erwähnten Preferences-Dialog haben wir hoffentlich bereits das Häkchen bei “Use PyLint” gesetzt. Die Einstellung “Redirect PyLint output to console” müssen wir nicht aktivieren. Nun sollte spätestens nach dem nächsten Speichervorgang in der View “Problems” eine Reihe weiterer Zeilen auftauchen, die in der Spalte “Type” als “PyLint Problem” gekennzeichnet sind (siehe Screenshot am Ende dieses Artikels).

Die entsprechende Codezeile, aus der eine Meldung resultiert, erreicht man übrigens (wie im Problems-View üblich) durch einen simplen Doppelklick.

PyLint-Fehlermeldungen (statische Codeanalyse)

PyLint-Fehlermeldungen

 

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

neun − 4 =