Sehen, wo mein Programm gerade läuft?

2 Antworten

Du kannst einen Debugger verwenden - zB in VisualStudio Code.

Damit kannst du dein Programm Schritt für Schritt ablaufen lassen und die Werte der Variablen, etc. überwachen. So findet man Fehler sehr komfortabel!

Sicher, einfach hier und da ein Print-Statement einfügen.

import numpy

print("Starting the script!")
print("Creating random numbers ... ")
random_array = numpy.random.normal(loc=0, scale=1, size=1000)
print("... Done! Reshaping ... ")
random_array = random_array.reshape((200, 5))
print("Iterating over each cell: ")
for row in range(random_array.shape[0]):
    for column in range(random_array.shape[1]):
        # ... do something
        cell_nr = random_array.shape[1] * row + column
        print("Done with cell_nr{:d} of {:d}".format(cell_nr, 1000)

Warum einfach wenn es Kompliziert auch geht? Für sowas gibt es Debugger!

Oder soll man permanent dutzende print-Anweisungen einfügen und dann wieder rauslöschen? Abgesehen davon wenn man größere Datenmengen verarbeitet können da hunderte oder tausende Zeilen in wenigen Sekunden ausgegeben werden. Komfortabel und übersichtlich und praktisch geht anders!

0
@markb1980

öhm , also da wiedersprichst du eigentlich jedem system was es so gibt. klar macht man logdateien , bei jedem piffigen system macht man als erstes ein log level , das ist praktisch nichts anders , ich gebe zu das es nicht das gleiche ist . aber ja zu 99% ist es eine gute idee mit exceptions zu arbeiten . klar nimmt man ein debugger , aber auch klar ist das man eine logdatei führt z.b. für probleme :) deswegen ist es gar nicht so unüblich .
normalerweise gibt es dann auch den debug=false , debug=true oder halt log level . damit muss man gar nicht etwas löschen , sondern eine simple funktion die aufgerufen wird mit dem debug text ggf noch variablen inhalt .

0
@RakonDark

Als Entwickler sage ich dir, die Logdateien sind nicht die Lösung sondern maximal eine Notlösung weil du den Enduser ja nicht durch den Debugger schicken willst/kannst... Daher ist Logging maximal eine Krücke für Fehler die bei der Entwicklung nicht aufgefallen sind und eine Hilfe um brauchbare Fehlerberichte zu bekommen denn mit dem üblichen "Programm funktioniert nicht" was viele User für eine Fehlermeldung halten kann kein Entwickler was anfangen geschweige denn, dass User oftmals selber den Fehler nicht reproduzieren können.

Allein schon darum weil ich dank Breakpoints mir bestimmte Code-Zeilen ansehen kann ohne mich durch den ganzen Code zu klicken. Bei Logdaten muss ich zumeist viel herumsuchen.

Und wenn du schon ein Logging einbauen willst dann doch eher mit dem logging-Module anstatt mit print()!

0
@markb1980

kommt auf das level an in dem man sich befindet. für mich ist print sowas wie console , durchaus normal für den anfänger sich erstmal alles auf die console zu packen . ob ich da erstmal lerne ein log modul zu nehmen ist dann die zweite sache . klar ist ein debugger um einiges leichter , wenn man denn lernt das zu nutzen . aber generell muss man keine print anweisungen löschen , da muss ich dir wiedersprechen . alles andere an argumenten ist ok , aber das mit dem löschen , fail . das ist einfach ein argument das etwas aroganz beinhaltet . niemand ist verpflichtet eine IDE zu nutzen und einige nutzen sie auch nicht und dann ist halt print eine gute idee . richtig gemacht braucht man nichts löschen und brauch keine ide . wie soll ich auch eine IDE auf meinen SSH Server Core packen . Oder muss ich erstmal die ganze umgebung bei mir lokal nachstellen . Also mir fallen genauso wie dir unendlich viele möglichkeiten ein wo ich gar keine debug ide nutzen kann und mir nur ein print bleibt.

0
@RakonDark
wie soll ich auch eine IDE auf meinen SSH Server Core packen

Emacs, Vim, ... + gdb mehr sag ich da nicht.

Wobei ich nicht verstehe warum man am Server überhaupt was coden sollte. Da mach logging schon Sinn aber nicht in der Entwicklung.

Mir fallen dutzende Anwendungsfälle ein in denen man die Print-Ausgaben nicht haben will - aber egal man kann die ja in if-Abfragen packen und dann die CLI-Argumente parsen um zu sehen ob Logging gewünscht ist oder nicht.

Es ist aber egal - du hast deine Meinung und ich meine. In der Entwicklungs-Phase macht m.M.n. der Debugger mehr Sinn. Warum man nicht mit einer IDE arbeiten will verstehe ich auch nicht ganz - VS Code ist weder ein Ressourcenfresser noch Groß und Überladen außerdem noch kostenlos und sehr hilfreich beim schreiben von Code.

Klar, man muss sich nicht von Intellisense die Argumente für diverse Funktionen anzeigen lassen oder Funktions-, Klassen- und Variablennamen vorschlagen lassen. Man kann auch die Doku immer nebenbei offen haben und sich da permanent durchsuchen und Tippfehler von Hand ausbessern. Der Sinn einer IDE ist es Code schneller, effektiver und komfortabler zu schreiben und zu debuggen also warum sollte man sich das Leben schwer machen? Aber egal - mach es so wie du willst.

0
@markb1980

Hi Markb, ich habe schon öfter beobachtet, dass Profi-Entwickler und Experten im Programmieren sehr festgefahrene Ansichten haben, was "guten Stil" angeht. Das ist in deinem Metier ganz sicher super wichtig, damit man sowas wie einen universellen Kodex erzeugt. Wenn du das Skript eines Kollegen oder Kunden bekommst, musst du damit arbeiten können. Mit meinem Kauderwelsch könntest du das garantiert nicht. Aber deshalb bin ICH ja kein Software-Entwickler, sondern nutze Programmierung für MICH und für MEINE Erleichterung im Job.

Wenn du Tipps gibst, dann müssen sie auch irgendwie der Zielgruppe angepasst sein. Macht der Fragesteller auf dich den Eindruck, dass er mit dem Debugger einer IDE umgehen kann?

Der Weg des kürzesten Widerstands ist: print-debugging und fertig. Da mag es dir die Haare aufstellen, aber schneller gehts erst mal nicht. Richtig natürlich, dass du darauf hinweist, denn wenn er/sie besser werden will, sollte er auch ein paar Punkte beachten.

Insofern sehe ich unsere Antworten nicht als Widerspruch, sondern als Ergänzung.

0
@offeltoffel
Mit meinem Kauderwelsch könntest du das garantiert nicht.

... du solltest mal so manchen Exploitcode sehen - da wird schnell was "hingerotzt" ohne Kommentare oder Anmerkungen und gut ist - meist nichtmal aussagekräftige Variablennamen. Schlimmer geht's immer ;-)

Wenn du Tipps gibst, dann müssen sie auch irgendwie der Zielgruppe angepasst sein. Macht der Fragesteller auf dich den Eindruck, dass er mit dem Debugger einer IDE umgehen kann

... Also das finde ich jetzt lächerlich - eine IDE ist kein Buch mit sieben Siegeln - im Grunde ist das nichts mehr als ein besserer Editor der dich mit intelligenten Funktionen unterstützt - Beispiel wenn du os. eintippst werden dir einfach alle möglichen Funktionen vom os-Modul vorgeschlagen oder wenn du Variablennamen schreibst werden dir nach 2, 3 oder 4 Buchstaben die möglichen Kandidaten angezeigt oder wenn du nach dem Funktionsnamen die ( tippst werden dir die möglichen Parameter und die richtige Reihenfolge angezeigt. Genau das spart Zeit denn dadurch musst du nicht immer in der Doku nachsehen!

Ein Debugger ist genau so simpel - Setz vorab einen Haltepunkt, starte das Script und lass es dann Zeile für Zeile laufen - wenn einer schon programmiert sollte das klicken auf den Play-Button und dann ein paar mal auf den "Schritt vorwärts" - Button auch keine Herausvorderung darstellen.

Der Weg des kürzesten Widerstands ist: print-debugging und fertig. Da mag es dir die Haare aufstellen

Genau das sehen viele so und scheitern dann kläglich weil sich nicht alles mit print prüfen lässt sondern nur das was man selbst ausgibt - somit sind viele komplexere Probleme damit garnicht lösbar wenn man nicht schon ansatzweise weiß wo das Problem liegt.

In einer Schleife wirst du unter Umständen von Informationen erschlagen und siehst den Fehler vor lauter Zeilen nicht.

Das Problem der Print-Methode ist einfach, dass das ganze 100x klappen wird und beim 101. mal wirst dich felsenfest darauf verlassen und nicht zum Ziel kommen und verzweifeln. Ich sitz auch immer wieder mal vor Logs die mich irrsinnig viel Zeit kosten und trotzdem nicht ein Stück weiterbringen. Klar meistens passt es aber nicht immer.

Daher lege ich bei meinen Kursen großen Wert darauf, dass die Teilnehmer richtig debuggen Lernen denn ein Großteil der Zeit ist ein Entwickler entweder am Nachlesen wie etwas geht oder am Fehlersuchen warum etwas nicht klappt.

Riskier doch mal die 200MB Festplattenplatz und schau dir VisualStudio Code an und dann sag nochmal, dass es nicht hilfreich ist beim schreiben von Code. Viele Tippfehler werden dir hier zB schon vor dem Ausführen angezeigt und Kleinigkeiten in der Doku nachzulesen wie nochmal eine Option hieß oder wie nochmal der Name der Funktion war oder in welcher Reihenfolge die Parameter stehen kannst du damit getrost vergessen. Sowas ist genau so hilfreich bei kleinen Helfern die nur 20-30 Zeilen haben wie auch für große Projekte mit hunderttausenden Zeilen Code!

0

Was möchtest Du wissen?