statische Code Analyse für Python

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
karomi
User
Beiträge: 18
Registriert: Mittwoch 12. Juli 2006, 12:42

Hallo Allerseits,
ich such eine OPensource Projekt oder Programm dass meine Python Source Code statisch analysiert. Gibt es sowas überhaupt?
Wenn ja welche?
Für Jave gibt es kommerzielle und Opensource Programme wie JUnit und findbug.
Ich freue mich auf eure Posts.
Vielen Dank
Haider aus Berlin
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Es gibt das ältere PyChecker und das umfassendere PyLint, welches dir deinen Quellcode analysiert und dann am Schluss eine Bewertung abgibt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Hi Sorry wenn ich mich hier einklinke aber was genau ist damit gemeint? Was genau kann ich mir unter einer statischen Analyse des Python codes vorstellen und was unter eine Bewertung des codes? :?:

lg
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Hoi,

ein Beispiel sagt mehr als tausend Worte. Hier also ein (mieser) PyLint output:

Es gibt eine qualitative Analyse Deines Codes (Warnungen, Fehlerquellen, etc.) inkl.Zeilennummer, so daß Du solche "Fehler" leichter finden kannst (sehr nützlich) - nur Auszüge:

Code: Alles auswählen

W:1081:SAXSdata.fit_gaussian.__peval: Missing docstring
C:1081:SAXSdata.fit_gaussian.__peval: Too short name "x"
E:182:SAXSdata.__init__: Access to undefined member 'minimum'
W: 36: Unused import allclose
Und abschließend eine statistische Analyse:

Code: Alles auswählen

Report
======
564 statements analysed.

Duplication
-----------

+-------------------------+------+---------+-----------+
|                         |now   |previous |difference |
+=========================+======+=========+===========+
|nb duplicated lines      |0     |0        |=          |
+-------------------------+------+---------+-----------+
|percent duplicated lines |0.000 |0.000    |=          |
+-------------------------+------+---------+-----------+



Raw metrics
-----------

+----------+-------+------+---------+-----------+
|type      |number |%     |previous |difference |
+==========+=======+======+=========+===========+
|code      |614    |58.20 |612      |+2.00      |
+----------+-------+------+---------+-----------+
|docstring |327    |31.00 |327      |=          |
+----------+-------+------+---------+-----------+
|comment   |47     |4.45  |47       |=          |
+----------+-------+------+---------+-----------+
|empty     |67     |6.35  |67       |=          |
+----------+-------+------+---------+-----------+



External dependencies
---------------------
::

    __future__ (Data)
    os (Data)
    numpy (Data)
    glob (Data)
    re (Data)
    scipy (Data)
      \-optimize (Data)
    pickle (Data)
    types (Data)



Statistics by type
------------------

+---------+-------+-----------+-----------+------------+---------+
|type     |number |old number |difference |%documented |%badname |
+=========+=======+===========+===========+============+=========+
|module   |1      |1          |=          |100.00      |0.00     |
+---------+-------+-----------+-----------+------------+---------+
|class    |9      |9          |=          |100.00      |0.00     |
+---------+-------+-----------+-----------+------------+---------+
|method   |50     |50         |=          |100.00      |22.00    |
+---------+-------+-----------+-----------+------------+---------+
|function |4      |4          |=          |50.00       |50.00    |
+---------+-------+-----------+-----------+------------+---------+



Total errors / warnings
-----------------------

+-----------+-------+---------+-----------+
|type       |number |previous |difference |
+===========+=======+=========+===========+
|convention |171    |172      |-1.00      |
+-----------+-------+---------+-----------+
|refactor   |12     |12       |=          |
+-----------+-------+---------+-----------+
|warning    |33     |33       |=          |
+-----------+-------+---------+-----------+
|error      |10     |10       |=          |
+-----------+-------+---------+-----------+



Messages
--------

+-----------+-----------+
|message id |occurences |
+===========+===========+
|C0324      |45         |
+-----------+-----------+
|C0301      |44         |
+-----------+-----------+
|C0101      |35         |
+-----------+-----------+
|C0103      |33         |
+-----------+-----------+
|W0201      |12         |
+-----------+-----------+
|W0611      |8          |
+-----------+-----------+
|C0322      |8          |
+-----------+-----------+
|W0702      |6          |
+-----------+-----------+
|E0201      |6          |
+-----------+-----------+
|C0321      |6          |
+-----------+-----------+
|R0915      |5          |
+-----------+-----------+
|E0602      |4          |
+-----------+-----------+
|R0912      |3          |
+-----------+-----------+
|W0131      |2          |
+-----------+-----------+
|W0704      |1          |
+-----------+-----------+
|W0311      |1          |
+-----------+-----------+
|W0302      |1          |
+-----------+-----------+
|W0231      |1          |
+-----------+-----------+
|W0103      |1          |
+-----------+-----------+
|R0914      |1          |
+-----------+-----------+
|R0913      |1          |
+-----------+-----------+
|R0904      |1          |
+-----------+-----------+
|R0902      |1          |
+-----------+-----------+



Global evaluation
-----------------
Your code has been rated at 5.28/10 (previous run: 5.26/10)
Es besteht aber immer die Gefahr, daß man sich zu sklavisch an solchen Metriken orientiert! Zahlen sind gut und schön, aber nicht das alleinige Maß für die Qualität von Code.

Gruß,
Christian
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Danke dir für das Beispiel. Hmm, mal sehen vielleicht installiere ich das mal.

lg

edit: Welches ist den besser? PyChecker oder PyLint?
BlackJack

Als ich die beiden verglichen hatte, fand ich PyLint besser. Es hat mehr Probleme gefunden und testet auch auf PEP 008 (Styleguide) "Fehler".
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:edit: Welches ist den besser? PyChecker oder PyLint?
Ich bevorzuge PyLint, obwohl ich zugeben muss, dass ich es kaum einsetze. Liegt wohl daran, dass ich mich an die meisten Sachen automatisch halte (z.B. PEP8, größtenteils) und es mir zu viel Arbeit ist. Wie CM sagte, man sollte sich eben nicht zu sklavisch daran halten, ab und zu es ausführen ist aber nicht schlecht um herauszufinden, ob man nicht irgendetwas übersehen hat.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

PEP8? Sagt mir nichts :/ Naja ich installiere das mal dan weiß ich wie sauber mein code ist...Ich denke für Anfänger wie mich dürfte das am anfang recht ok sein...

lg
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:PEP8? Sagt mir nichts :/
PEP 8.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Danke für den link, ich kann leider kein Englisch… (bzw. sehr schlecht, also eigentlich gar nicht). Aber das was ich grob verstanden habe geht es da um gewisse Konventionen für sauberen Code schreiben oder so…

lg
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:Aber das was ich grob verstanden habe geht es da um gewisse Konventionen für sauberen Code schreiben oder so…
Ja, da steht wie man Python-Code schreiben sollte, damit andere den auch verstehen und daran wietermachen können ohne einen neuen Stil einzuführen. Das tolle ist, die meisten Leute halten sich an diesen Styleguide :)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Huch, da habe ich ja was losgetreten ...

Also, wenn ich mir noch ein Kommentar erlauben darf: So sehr ich mich auch bemühe sauberen Code zu schreiben, so sehr weiche ich auch davon ab, wenn es mir opportun erscheint (es wird einfach unübersichtlich, wenn man überall Zeilenumbrüch einbaut, um unter 80 Zeichen zu bleiben - Fehlermeldungen z. B. sind naturgemäß manchmal länger und sie umzubrechen stört meinen Lesefluß). Dann ist mir egal was irgendeine Metrik sagt. Mir fallen noch mehr Beispiele ein (z. B. beschwert sich PyLint, daß es in manchen meiner Klassen zu viele öffentliche Methoden gibt - Blödsinn, wenn man für jeden Parameter, und sei er in einem dict, eine get-Methode definiert), aber ich will das mal nicht aufzählen ...

Fazit: Solch eine Code-Metrik kann nützlich sein, kann aber auch irreführend sein - besonders einen pot. Chef.

Gruß,
Christian
BlackJack

Klar sind das nur Richtlinien, dessen sollte man sich immer bewusst sein.

Man kann auch fast alle Zahlen und Regeln für Namensgebungen in einer Konfigurationsdatei vorgeben, einzelne Prüfregeln abschalten usw.

Ausserdem ist es möglich im Quelltext per Kommentar lokal oder modulweit einzelne Tests auszuschalten.

Dein Beispiel mit den zu vielen öffentlichen Methoden habe ich nicht ganz verstanden!? Eine Klasse mit 20 getter-Methoden hat IMHO zuviele davon, nämlich genau 20 Stück. ;-)
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

CM hat geschrieben:Fazit: Solch eine Code-Metrik kann nützlich sein, kann aber auch irreführend sein
PEP 8 hat geschrieben:A Foolish Consistency is the Hobgoblin of Little Minds
Edit (Leonidas): Restliche Diskussion in den Thread Pythons OOP erklärt abgetrennt.
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Ok, ok. Das mit den get_*-Methoden war ein schlechtes Beispiel. (Deswegen muß man doch nicht noch einen Thread drausmachen ?!?) Wie auch immer: Auch bei großen GUI-Anwendungen lagert man Methoden aus. Dennoch habe ich leicht mehr als 20 öffentliche Methoden im Mainframe (bei wxPython). Und nein, ich halte das nicht für schlechten Code - er ist auch noch ziemlich übersichtlich *stolzsei*.

Also: Schlechtes Beispiel meinerseits - aber Schlußfolgerung bzgl. Metriken unangetastet.

Christian
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

CM hat geschrieben:Deswegen muß man doch nicht noch einen Thread drausmachen ?!?
Doch, ich fand die Idee gut einen Thread rauszusplitten, da ich den anderen Thread mit samt BlackJacks Erklärung von Pythons-OO-Konzepten durchaus interessant fand und er wohl auch ohne den Code-Analyse-Thread lesenswert ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Nein, entschuldige Leonidas, ich meinte lediglich, daß es mich verwunderte, daß es die Diskussion wert ist - den neuen Thread finde ich es schon wert und auch interessant. Da ist mir wohl eine Redewendung untergekommen, wie ich sie in diesem Forum von Norddeutschen bis Schweizern und Österreichern nicht hätter verwenden dürfen.
Christian
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

@Leonidas: Jupp ich finde die Erklärungen auch sehr interessant :) Vor allem in wie fern sich Python in dem bereich von C++ unterscheidet und welche vorteile es gegenüber C++ hat. Das sind ja vollkommen unterschiedliche Philosophien die beide Sprachen verträten. Finde es daher insofern interessant für C++ Umsteiger die nicht den Fehler machen sollen in Python ihre Klassen nach den C++ Dogmata zu entwerfen. Hätte ich von BlackJack das nicht erfahren würde ich jetzt zu 100% meine Klassen nach dem gleichen Prinzip wie in C++ entwerfen…

lg
BlackJack

CM hat geschrieben:Wie auch immer: Auch bei großen GUI-Anwendungen lagert man Methoden aus. Dennoch habe ich leicht mehr als 20 öffentliche Methoden im Mainframe (bei wxPython). Und nein, ich halte das nicht für schlechten Code - er ist auch noch ziemlich übersichtlich *stolzsei*.

Also: Schlechtes Beispiel meinerseits - aber Schlußfolgerung bzgl. Metriken unangetastet.
Das sehe ich ja auch so. Gerade GUIs sind da eine Ausnahme. Jedes GUI Toolkit fällt bei pylint durch "zu viele" Methoden auf, auch ohne das man eigene Methoden hinzufügt. Das kann man also durchaus als normal ansehen.
Antworten