Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Breakpoints können einfach an Bedingungen geknüpft werden.
Die Diskussionen habe ich alle schon geführt und in meinen Vorlesungen und Laboren werden die Möglichkeiten moderner Programmierumgebungen auch entsprechend genutzt
Ganz im Gegenteil. Das sollte das Erste sein, was man lernt. Hab ich auch auf die "schmerzvolle" Art lernen müssen.
edit:
Um das mal klarer auszuführen. Ich hab mir vor vielen vielen Jahren grundlegendes Programmieren selbst bei gebracht (noch so richtig mit ausgedrucktem Delphi-Handbuch^^). Dann später eine Umschulung zum FIAE mit IHK-Abschluss. Dort lernt man aber auch nur die Grundlagen und viel "Kaufmanns-Scheiß". Irgendwann bei mir auf Arbeit angefangen, wo ich der einzige Entwickler bin. Und nun, Jahre später, wenn ich meinen eigenen Code sehe, wird mir teilweise schlecht. Nun habe ich aber mit diesen ganzen Fehlern zu kämpfen.
Eine richtig große Weiterentwicklung war, mich mit Design Pattern und ähnlichem zu beschäftigen. Und ich würde mich noch nicht mal als guten Programmierer bezeichnen.
Also: Code Quality > all (ne while-Schleife bekommt eigentlich jedes Kind hin (sorry für den Seitenhieb^^))
Wobei es zB bei nlog auch das Console- und Debugger-Target gibt, die im Prinzip nichts anderes sind als printf.
Reines printf ist sicherlich nicht mehr zeitgemäß, da gebe ich dir Recht. Es klang aber so als wenn du jedwedes Debugging jenseits des Debuggers in Visual Studio verteufelst und das ist in meinen Augen falsch (wenn du es denn so gemeint hast).
KuestenNebel schrieb:
Breakpoints können einfach an Bedingungen geknüpft werden.
"Fehler" impliziert ja eine Abweichung von einem erwarteten Zustand, entsprechend kann zumindest dies formuliert wird. Wodurch die Abweichung verursacht wird steht freilich auf einem anderen Papier
Die Diskussionen habe ich alle schon geführt und in meinen Vorlesungen und Laboren werden die Möglichkeiten moderner Programmierumgebungen auch entsprechend genutzt
Warum sollte es hier meine Aufgabe sein Bedingte Breakpoints, der Call Stack, Variableninspektor, alles Standard-Tools in Entwicklungsumgebungen wie Visual Studio oder Eclipse, die jeder Programmiererin und jedem Programmierer auch bekannt sein sollten
@KuestenNebel hat schon Recht, der Debugger ist natürlich ungleich mächtiger und erlaubt eben auch Debugging von Dingen, die man beim Einfügen der Log-Messages - sei es nu mit printf, nlog oder was auch immer - gar nicht bedacht hat. Beispielsweise indem man sich Werte von Objekten und deren Unterobjekten in allen Ebenen anschauen kann, ohne für jede einzelne Klasse vollständige Log-Messages schreiben zu müssen. Ich denke jeder saß schon mal vor seinem Log und dachte sich "Mist, das habe ich vergessen zu loggen...."
Aber wie gesagt, ich sehe für beide Methoden einen Sinn und ich nutze auch beides - in jeweils anderen Situationen.
Wie dem auch sei, ich denke das führt nu ein wenig am Thema vorbei. Wahrscheinlich meinen wir alle zumindest fast das gleiche, reden nur ein wenig aneinander vorbei - Menschliche Kommunikation kann manchmal so unpräzise sein und mein interner Debugger schmeißt dabei selbst haufenweise Exceptions....
Weil Du die Behauptung in die Welt gesetzt hast. Und der der was behauptet ist nun mal in der Bringschuld die dann auch zu erläutern. Zumindest sollte das so in einer halbwegs anständigen Diskussion sein.
Sonst könnte man ja allen möglichen Kram erzählen und auf nachfrage immer darauf verweisen, das derjenige das doch selbst herausfinden soll was nun gemeint oder nicht gemeint ist.
Ich habe doch zeitgemäßere Debugging-Verfahren erwähnt. Dein anschließendes Geschreibsel über Diskussionen führt also leider zu nichts, da ich meinen Teil erfüllt habe, dennoch kann ich nachvollziehen, dass du gerne von der Sache ablenken möchtest.
Raijin schrieb:
Wahrscheinlich meinen wir alle zumindest fast das gleiche
Fast Ich werde nicht müde gegen zweifelhafte Programmierpraktiken anzukämpfen und moniere diese deshalb, wenn ich sie sehe - auch wenn das am Stolz manches Coders kratzt.
Ich bin auch der Ansicht, dass man früh auf Code-Qualität hinweisen sollte. Man verbringt die meiste Zeit damit Code zu lesen und zu verstehen. Spätestens, wenn ein Projekt mit mehreren Personen realisiert werden soll, kann es den Aufwand deutlich reduzieren und den Entwicklungsprozess beschleunigen. Das wird dann sicherlich auch in der Leistungsbewertung sichtbar.
Um das Fahrrad-Beispiel aufzugreifen. Natürlich kann man von keiner Person erwarten, dass sie am ersten Tag gerade und sauber fährt. Wenn man sie jedoch nicht darauf anspricht, weil sie sich dann angegriffen fühlen könnte, wird sie eine längere Zeit eine Gefährdung für sich und für andere Personen sein. Im Entwicklungskontext wäre das dann der Kollege, der den Entwicklungsprozess bremst.
Zur Ausgabe in der Konsole oder Log-Datei und der Nutzung des Debuggers: Ich nutze beides und versuche das Einsatzszenario abzuwägen. Wenn mich nur das Ergebnis vieler Iterationen interessiert, lasse ich es in der Konsole oder in der Log-Datei ausgeben. Wenn ich ein Problem und die Ursache analysieren muss, nutze ich meistens lieber den Debugger.
Welchen Vorteil bietet dieses Vorgehen deiner Ansicht nach gegenüber dem Variableninspektor? Auch dort kannst du jederzeit einen Blick auf alle Variablen werfen - ohne überflüssige printf-Zeilen.
Das setzt aber voraus, das ich dann einen Breakpoint gesetzt hast und das Programm dort gerade gestoppt hat.
Wenn ich das brauche, dann sind solche Debugger-Funktionalitäten ja auch ganz nützlich.
Aber nicht immer hab ich ja solche Anforderungen. Manchmal will ich ja zum Beispiel gucken, wie sich Variablen innerhalb einer Schleife entwickeln. Dann brauche ich eher eine Liste mit der dann die entsprechenden Variablenwerte bei jedem Durchlauf aufgeführt sind. Da nützt es mir nix, wenn ich irgendwo im GUI nur den aktuellen Wert angezeigt bekomme.
Oder ich hab z.B. den Anfangsverdacht das bei irgendeiner Funktion ein inkorrektes Argument übergeben wird und will halt nun bei jedem Aufruf dieser Funktion die Argument-Variablen ausgegeben haben.
Solche Sachen lassen sich halt gut "debuggen", wenn ich einfach eine Ausgabe mache. Ob nun nach stdout, stderr, in ein Fenster auch immer ist ja da auch eher nebensächlich.
Ich habe mir auch mal vor längerer Zeit ein kleines Makro zu gebastelt. Wenn ich da eben auf diese Weise die Variable xyz checken will schreib ich an der gewünschten Stelle im Quelltext einfach z.B.: (debug xyz)
Und dann krieg ich halt bei jedem Aufruf den Namen der Variable, ihren Wert, welchen Typ die Variable hat, in welcher Datei in welcher Zeile der Aufruf steht.
Und ich sehe halt nur die Variablen, die ich aufführe (die mich also interessieren) und muss nicht erst in der Variablenübersicht gucken, wo die für mich interessante Variable genau steht (was je nach Scope durchaus mal ein paar mehr sein können).
Und dabei ist es nicht mal besonders schwer diese temporären Debug-Ausgaben wieder aus dem Quelltext rauszuziehen, weil ich halt nicht stumpf nach printf suchen muss (was ja durchaus auch mal regulär vorkommen kann), sondern einfach mir alle Referenzen auf das Makro (debug) geben lasse und die dann entferne.
Mit welchem Mechanismus in Visual Studio wird mir nun diese Funktionalität erleichtert? :-)
Welchen Vorteil bietet dieses Vorgehen deiner Ansicht nach gegenüber dem Variableninspektor? Auch dort kannst du jederzeit einen Blick auf alle Variablen werfen - ohne überflüssige printf-Zeilen.
Nach reiflicher Überlegung kann ich leider keine Vorteile gegenüber den Debugging-Möglichkeiten in Visual Studio nennen. Scheinbar handelt es sich bei meinem Modus Operandi um eine Angewohnheit, die ich mir beim Arbeiten an kleineren Projekten ohne Visual Studio, sicherlich auch mit anderen Programmiersprachen und weniger mächtigen Entwicklungsumgebungen (oder Code-Editoren), im Webumfeld angeeignet habe.
Meine Arbeit findet überwiegend ohne Visual Studio statt. Dahingehend bin ich nicht qualifiziert genug, um die Vor- und Nachteile beider Methoden im professionellen Umfeld zu bewerten und zu kommentieren. Sicherlich erhöht das Weglassen von überflüssigen printf-Zeilen die Lesbarkeit des Codes. Daher bewerte ich es als positiv, die gegebenen Möglichkeiten bei der Arbeit mit Visual Studio oder einer ähnlich starken Entwicklungsumgebung voll auszuschöpfen.
Vielleicht kann man der Konsolenausgabe-Variante abgewinnen, dass diese sich leicht für unterschiedliche Programmiersprachen implementieren und mithilfe von Dependency Injection als dateibasierter Logging-Mechanismus verwenden lässt.
Update #1:
Wenn es nicht möglich ist, den Entwicklungsverlauf von Variablen in einer Schleife oder in einer rekursiven Methode zu überwachen bzw. aufzuzeichnen, dann sehe ich in der Konsolenausgabe-Variante auch den Vorteil, den @andy_m4 nennt. Dafür sind meine VS-Kenntnisse nicht gut genug.
Update #2:
Laut einem Stack Overflow-Beitrag ist es möglich, im Zusammenhang mit Unreal Engine 4, sich Variablenänderungen ausgeben zu lassen. Wäre das deine genannte Funktion @andy_m4? https://stackoverflow.com/a/31725773
Update #3:
Es ist scheinbar möglich den Entwicklungsverlauf von Variablen bspw. in einer Schleife ausgeben zu lassen, ohne die Programmausführung zu stoppen. Es kann anscheinend auch eine Bedingung angegeben werden, wann die Aktion ausgeführt wird.
Saubere Arbeit Du siehst @andy_m4 der Debugger kann das alles ... printf-Debugging ist nicht mehr als eine lieb gewonnene Angewohnheit, von der man nicht mehr wirklich wegzukommen vermag ...
Routinemäßiges Logging ist davon explizit auszunehmen, ich kreide lediglich das wahllose Ein- und Ausbauen von print-Statements zur Überwachung von Variablen an. In kleineren Projekten mag das noch in Ordnung sein, aber mit wachsendem Anspruch sollte der Umgang mit dem Debugger im Vordergrund stehen.
Was mich überrascht: Wieso hat uns noch kein Mod ins Aquarium verschoben?
Die Frage war ja, welchen Vorteil bietet mir die Visual Studio Variante?
Im Grunde ist es letztlich das selbe. Variableninhalte werden auf einer Konsole ausgegeben. Der einzige Unterschied ist: einmal notiert man das im Quelltext, einmal hinterlegt man das in der IDE.
Die erste Variante soll jetzt furchtbar schlecht sein und die zweite Variante ist der one and only way to do it.
KuestenNebel schrieb:
ich kreide lediglich das wahllose Ein- und Ausbauen von print-Statements zur Überwachung von Variablen an.
Na erstens ist das ja nicht wahllos, sondern nur wenn man es braucht.
Zweitens sind es (zummindest bei mir) keine printf-Statements.
Die fänd ich auch eher unhandlich. Und haben (wie schon angedeutet) auch den Nachteil, das man sie ggf. nicht wieder alle sauber eingesammelt kriegt.
Was Du vielleicht meinst ist, das man das wirklich mehr oder weniger wahllos einsetzt und an allen möglichen Stellen einbaut. Und dann noch womöglich je nach Bedarf ein- und auskommentiert und man dann in solchen Quelltexten wenn man dann später mal da archäologisch durchforstet, dann auf alle möglichen Fragmente trifft. :-)
Aber das war hier gar nicht gemeint.
KuestenNebel schrieb:
In kleineren Projekten mag das noch in Ordnung sein
Die Projektgröße spielt da eigentlich keine Rolle. Keine Ahnung, wie es andere machen. Aber es geht ja meist um ein ganz spezielles Problem was man sich näher angucken möchte.
KuestenNebel schrieb:
printf-Debugging ist nicht mehr als eine lieb gewonnene Angewohnheit, von der man nicht mehr wirklich wegzukommen vermag ...
Mag durchaus sein. Man kann es also durchaus so nach dem Motto sehen: "Haben wir immer schon so gemacht" :-)
Nur ich sehe das eher als eine Form der persönlichen Vorlieben. So wie ja jeder so seine Eigenheiten hat.
Ich bin da durchaus auch offen was andere Möglichkeiten betrifft. Aber dann muss man mir auch darlegen, welche Vorteile die andere Methode gegenüber meinem altbewährten Kram hat. Und bisher sehe ich da nix.
Und ich hab auch absolut nix dagegen wenn es jemand anders macht als ich. Da würde ich mir nie anmaßen darüber zu urteilen und so sagen "So macht man das aber nicht".
Nicht zuletzt muss man auch immer gucken, in welcher Situation ist man und warum geht man so und so vor. Daher klingelt immer mein Alarmglöckchen, wenn jemand versucht mit pauschalen Aussagen ("macht man nicht") um die Ecke zu kommen. Pauschale Aussagen sind sozusagen so eine Art code smell :-)
KuestenNebel schrieb:
Was mich überrascht: Wieso hat uns noch kein Mod ins Aquarium verschoben?
Obgleich ich mich als Visual Studio-Anfänger outete, der wenig mit C und C++ arbeitet, sehe ich mehrere Vorteile darin, die gegebenen Debugging-Möglichkeiten zu verwenden. Du musst für die Verwendung der Debugger-Funktionalität keinen Code schreiben oder ändern. Entsprechend muss die Anwendung (oder Teile davon) für einen Debugging-Vorgang nicht immer rekompiliert werden. Die Debugging-Bedingungen und die Ausgabe können dadurch schneller angepasst werden. Es muss kein Makro definiert werden, welches dir die gewünschte Funktionalität liefert. Andere Programmierer können mit den gegebenen Tools von Visual Studio arbeiten und brauchen das Makro nicht kennen. Beim Kompilieren muss das Makro nicht immer an der entsprechenden Stelle durch den tatsächlichen Code ersetzt werden.
Diese Punkte fallen mir spontan dazu ein. Bitte korrigiert mich, falls einige der genannten Punkte falsch sind. Ich würde diese rege Diskussion gerne dafür nutzen, um mein Wissen dahingehend zu erweitern. :-)
Ist das Thema jetzt nicht allmählich durch? Zum einen ist das mittlerweile sehr OffTopic und zum anderen wird keine Seite die andere von ihrer Meinung überzeugen können, das wurde nun schon mehr als deutlich. Also bitte back to topic oder die Diskussion in einem neuen Thread oder via PN weiterführen.
Mist, jetzt klinge ich schon wie ein Mod... Ich verbringe zu viel Zeit auf computerbase.de ....
Naja. Erleichtert ist das falsche Wort. Weil ich bin ja zufrieden mit dem wie ich das mache. Ich hab das nur angesprochen, weil jemand meinte "so mache man das nicht" und wenn jemand sowas sagt hätte ich halt auch gern eine Begründung dafür. Das ermöglicht mir ja dann auch dazu zu lernen.
Und im Grunde ist das mit dem dazu lernen durch Dich auch irgendwie passiert. :-) Ich hab ein Visual Studio Feature kennengelernt, was ich vorher nicht kannte.
Insofern finde ich da Deine Erklärung (sogar inkl. Screenshots!) sehr gut.
Sonnenkarma schrieb:
Du musst für die Verwendung der Debugger-Funktionalität keinen Code schreiben oder ändern. Entsprechend muss die Anwendung (oder Teile davon) für einen Debugging-Vorgang nicht immer rekompiliert werden.
Aber das Problem fängt ja manchmal schon an anderer Stelle an. Nicht für jede Programmiersprache hast Du halt eine IDE mit solchen Debugging-Funktionalitäten. Schon allein das verbietet halt so ein pauschales "macht man nicht mit 'printf'".
Zum anderen sind ja einige Sprachen und Umgebungen auch nicht so statisch, das sie diesen Edit-Compile-Run-Zyklus haben. Da tut es dann auch viel weniger weh wenn Du schnell mal was ändern musst/willst.
In solchen Situationen verliert dann der von Dir genannte Vorteil deutlich an Gewicht.
Oder ums mal konkreter zu sagen: Wenn Du das irgendwie in C++ machst tut das Dir viel mehr weh weshalb da solche Debugger-Möglichkeiten viel nützlicher sind, als wenn Du irgendwie was mit Smalltalk, Common Lisp oder Skriptsprachen machst. Gerade bei ersteren beiden ist es absolut üblich direkt live den Code zu ändern während er läuft. Logischerweise bietet sich das dann auch an mit "printf" schnell mal was zu debuggen.
Und das ist halt der Punkt. Es geht mir gar nicht darum irgendwas mies zu machen oder "meine" Variante als die einzig Wahre darzustellen. Es geht mir darum, das man das differenziert betrachten sollte.
Sonnenkarma schrieb:
Es muss kein Makro definiert werden, welches dir die gewünschte Funktionalität liefert. Andere Programmierer können mit den gegebenen Tools von Visual Studio arbeiten und brauchen das Makro nicht kennen.
Ich setze übrigens auf eine relativ bescheidene IDE und arbeite manchmal sogar nur im Editor.
Ich hab nix gegen IDEs. Zu meiner Java-Zeit hab ich die sogar sehr viel in Anspruch genommen. Und das war auch gut so, denn gerade bei Sprachen wie Java profitiert man sehr von den Hilfen die eine IDE bietet. Also nicht nur was den Debugger angeht, sondern auch an sonstigen Funktionalitäten.
Im Augenblick bin ich hauptsächlich in der Lisp/Scheme-Welt unterwegs und habe dabei festgestellt, das man dort viele Funktionalitäten die so typische IDEs bieten gar nicht braucht, weil man da bestimmte Dinge grundsätzlich anders macht.
Außerdem sind IDEs komplexe Programme. Allein die zu beherrschen muss man dann erst mal lernen. Und dann stellt sich auch mal die Frage: Lernst Du die IDE oder nutzt Du für die entsprechende Funktionalität Deine Programmiersprache die Du ja sowieso schon kannst.
Wie gesagt. Alles hat so sein Für und Wider und es gibt nicht den einen Weg der für alles und in jeder Situation der Richtige ist.
Ergänzung ()
Raijin schrieb:
Also bitte back to topic oder die Diskussion in einem neuen Thread
Ja. Wobei man das auch übertreiben kann. Denn der Threadersteller hat sich ja nicht noch mal gemeldet. Also denk ich mal, da ist eh alles geklärt.
Und die Diskussion hat sich ja auch einfach ergeben. Jetzt dafür extra einen neuen Thread aufmachen (was ja die Diskussion auch auseinander reißen würde), halte ich dann doch für übertrieben.
