Nachrichtengenerierung in Mathematica

Ich möchte immer globale Variablen mit dem Präfix $ und Funktionen ohne das Präfix behalten, also würde ich schreiben:

Dann kannst du debugPrint genau so verwenden, wie du jetzt Print benutzen würdest. Wenn Sie die Debugging-Nachrichten loswerden möchten, heben Sie einfach die Variable auf:

Es gibt einige Vorteile, dies auf diese Weise zu tun. Eine Möglichkeit ist, dass Sie Block verwenden können, um das Debugging lokal und lokal zu aktivieren . em>:

Sie können $debugPrintFunction sogar lokal anders machen, zB Sow -Werte für ein Reap , oder die Debugging-Meldungen woanders anweisen, wie

Mit Bedacht verwendet das dynamische Scoping von Block die Verwendung globaler Variablen relativ sicher und kontrolliert Weg.

Mein älterer Code verwendet eine Methode wie Pillsy beschreibt.

Vor kurzem habe ich einen Kopf, der normalerweise keine Regeln hat, wie:

und dann eine zweite Funktion:

Wenn ich dann die Debugging-Ausgabe sehen möchte, kann ich PrintDebug um die Eingabe wickeln:

oder häufiger als

da ich finde, dass das Postfixformular einfacher hinzuzufügen / zu entfernen ist und den Fokus besser auf der Hauptfunktion belassen.

Normalerweise installiere ich eine verbosing-Option in meine Funktionen, die bei Bedarf zum Debuggen ein- und ausgeschaltet werden kann. Beachten Sie, dass Sie bei der Angabe des Standards für Verbose innerhalb der Funktion steuern können, ob die Information gedruckt wird oder nicht.

Natürlich kann man dieses Beispiel so ausarbeiten, dass es den Programmierstandards von Mathematica entspricht (z. B. den Header Options[func1, Verbose -> ...] hinzufügen und dann auf die Optionen innerhalb der Funktion zugreifen, aber das ist nicht der Punkt hier.

Noch eine andere Möglichkeit:

Verwenden Sie die Funktion wie folgt:

Schalte Nachrichten wie folgt ein oder aus:

Da M keinen integrierten Debugger hat, um zu sprechen, verschwende ich 50% meiner Zeit nur mit dem Debuggen, das gespeichert werden könnte, wenn es einen Debugger gäbe. 50% meines Entwicklungscodes sind Print-Anweisungen, denn ohne diese würde ich nicht herausfinden, woher ein Fehler kommt. (Das ist auch schlecht, da zu viele Drucknachrichten im Code es manchmal schwierig machen, den Algorithmus zu sehen, er kommt in die Quere, kann ihn aber nicht entfernen, da ich ihn später vielleicht brauche).

Ich finde es erstaunlich, dass ein solch leistungsfähiges und flexibles Rechenwerkzeug wie M immer noch eine relativ weniger fortgeschrittene Entwicklungsumgebung hat. Wenn ich Matlab benutze, brauche ich einige Sekunden, um herauszufinden, wo sich ein Fehler befindet, indem ich den Debugger benutze.

Jemand könnte sagen, dass Sie Workbench zum Debuggen verwenden. Ich habe versucht, eine Manipulate Demo zu debuggen, und ich kann es nicht herausfinden. Zu kompliziert zu verwenden. M benötigt einen einfach zu verwendenden Debugger-Build-In (im Notebook selbst, kein separates Programm) und mit Zeilennummern!

Ok, angesichts der obigen Einführung :), das ist, was ich selbst als Antwort auf Ihre Frage mache:

1. haben unterschiedliche Debug-Nachrichten. grobe Ebene und detaillierte Ebene. Coarse level druckt nur eine Nachricht, wenn eine Funktion aufgerufen wird und wenn die Funktion vorhanden ist.

2. Ich habe eine Schaltfläche auf der Benutzeroberfläche, mit der Debugging ein- und ausgeschaltet werden kann (wenn Sie ein auf der Benutzeroberfläche basierendes Programm verwenden, sonst wird es im Code enthalten sein).

3. Verwenden Sie eine separate Debug-Funktion, bei der die Debugging-Meldung durchlaufen wird, bevor sie gedruckt wird. Dort können Sie jeder Nachricht vor dem Drucken einen Zeitstempel hinzufügen (kann auch steuern, ob Nachrichten von einem Ort in eine Textdatei gelangen sollen). Rest Ihres Codes, ruft diese Debug-Funktion nur mit der zu druckenden Nachricht auf. Ich drucke alles jetzt zur Konsole, nicht zum aktuellen Notebook.

4. Jede Debug-Nachricht hat den Funktionsnamen, der sie am Anfang aufgerufen hat.

5. Wenn Sie das Debugging auf der Modulebene steuern wollen, was ich mache, machen Sie einfach ein lokales Debugflag innerhalb des Moduls und schalten es jedes Mal an / aus, wenn ich dieses ein bestimmtes Modul debuggen möchte. Dieses lokale Debug-Flag übernimmt die Einstellung des globalen Debug-Flags. Auf diese Weise kann ich nur ein Modul debuggen, wenn ich möchte, und nicht den Rest des Codes.

Es gibt viele andere Möglichkeiten, all dies anzupassen. Aber ich habe festgestellt, dass, wenn ich mehr Zeit für ein gutes Debugging-Meldesystem verwende, es hilft, Bugs zu finden, wenn sie benötigt werden.

Hier sind einige nützliche Links

Ссылка

workbench debugger (wenn Sie herausfinden können, wie man Manipulate und Dynamics debuggt, lassen Sie es mich wissen)

Ссылка