Richtig debuggen?

Zitat von OhnePlan

schaue ich mir den Abschnitt nun an:

Local $__PIC_INFO = GUICtrlCreateIcon($_dll,$__icoNumber, 80, 5, 80, 80)

Die Variable ist doch in Verwendung?

Nein, ist sie nicht.

Mit Local $__PIC_INFO wird die Variable deklariert (und hier auch gleich ein Wert zugewiesen).

Im Verlauf der Funktion wird diese Variable aber offenbar nicht verwendet (Deklaration und Wertzuweisung stellen in diesem Fall keine Verwendung dar). Für die Warnung verantwortlich ist der Parameter -w 5 .

Beispiel :

#AutoIt3Wrapper_AU3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7

Example()

Func Example()
	Local $sString1 = "Dies ist der erste String"
	Local $sString2 = "Dies ist der zweite String"

	; 1. hier wird nur der erste String verwendet :
	MsgBox(BitOR(4096, 64), "Anzeige 1 : ", $sString1)

	; 2. hier werden beide Strings verwendet :
	;MsgBox(BitOR(4096, 64), "Anzeige 2 : ", $sString1 & @CRLF & $sString2)
EndFunc   ;==>Example

Wenn Du bei der MessageBox in 2. mal die Kommentierung ; entfernst, dann wird $sString2 auch verwendet und die Warnung erscheint nicht.

Nachtrag :

1. zu #AutoIt3Wrapper_AU3Check_Stop_OnWarning=y

Au3Check läuft vorher durch und stoppt bei Warnungen, der Compiler macht das nicht.

2. zu den Parametern von #AutoIt3Wrapper_AU3Check_Parameters siehe : https://www.autoitscript.com/autoit3/scite/…3/au3check.html

Deutsch :

-q : Still, nur Fehler/Warnungen ausgeben
-d : Wie Opt("MustDeclareVars", 1)
-w 1: Bereits eingebundene Datei {ein)
-w 2: Fehlendes #comments-end bzw. #ce {ein)
-w 3: Bereits deklarierte Variable {aus}
-w 4: Lokale Variablen werden in einem globalen Bereich verwende (aus)
-w 5: Lokale Variablen sind deklariert, werden aber nicht verwendet (aus)
-w 6: Warnung falls Dim verwendet wird (aus)
-w 7: Warnung falls Const oder Ausdrücke an ByRef Parameter übergeben werden (ein)

Naja.....Brille nicht aufgehabt?!

Zitat von OhnePlan

warning: $PIC_INFO: declared, but not used in func.

Zitat von OhnePlan

Local $__PIC_INFO =

Finde den Fehler im linken Bild.....Wenn man schon Variablennamen von einem "Debuggingtool" angezeigt bekommt, dann sollte man auch nach deren genauen (!) Schreibweise suchen!

Weiterhin ist übrigens die Stelle im Script auf die dieser Hinweis zeigt, genauestens beschrieben!

Zitat von OhnePlan

"P:\AutoIT\LIB\Copyright.au3"(73,73)

In der Klammer steht die Zeilennummer und die Spalte. Ein Doppelklick auf die in der Konsole angegebene(n) Fehlerzeile(n) führt dazu, dass in Scite an die betreffende Stelle im Script gesprunge wird.

Debuggen ist in AutoIt/Scite gegenüber selbst einfachen anderen Sprachen generell mühsam. Scite ist ein Editor und keine IDE!

Mit den vorhandenen Debuggingtools im "Extras"-Menü kommt man aber schon ziemlich weit.

Ich persönlich bin kein Freund von solchen Zeilen: #AutoIt3Wrapper_AU3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7

Die angezeigten "Fehler" sind zu 99% keine und während der Entwicklung von Programmen behindern sie mich und stören meinen "Flow" und die Kreativität. Imho sind diese Zeilen dazu geeignet, nach (!) der Erstellung eines lauffähigen Script dieses "schön" zu machen. Was mich als Privatanwender (auch wenn ich Scripte sehr oft im beruflichen Leben verwende) einen Scheiss interessiert! Form follows function....

Für diese Gimmicks habe ich definitiv keine Zeit.....

Wer jemals auf Programmierwettbewerben war oder online mal zugeschaut hat, der versteht was ich meine. KEINER dieser Jungs und Mädels hat jemals, egal in welcher Programmiersprache gehackt wurde, diese "Tools" im Einsatz. Wenn du 5 Minuten Zeit hast einen Algorithmus zu verzapfen, dann braucht niemand 20 Zeilen "Hinweise" zu programmtechnisch völlig irrelevanten "Vorgaben".

Was nicht bedeutet, dass ich nicht ein absoluter Freund von "schönem" Code bin! Ich bewundere und respektiere Leute, die sich neben der Funktion eines Programms auch noch um dessen "äußere Form" kümmern! Wobei ich ziemlich sicher bin, dass das "aufhübschen" länger braucht als die eigentliche Programm/Funktionserstellung.....

Hi Andy 👋 ,

ich kann deine Ausführungen und Argumentationen nachvollziehen, verstehen und sogar für mich, der stark auf Form, Lesbarkeit und Integrierbarkeit in ein Team achtet, akzeptieren 🤝 .

Aus meiner Sicht ändern sich die Dinge sobald nicht nur einer, sondern 3, 4, n Entwickler an einem Projekt arbeiten sofort. Denn in diesem Bereich tragen Coding Guidelines, Conventions und Co. tatsächlich zum Erfolg der Anwendung (bzw. heutzutage sind es ja oftmals Services und keine Einmal-Verkaufssoftware), stark bei.

Das von dir beschriebene, mit den Programmierwettbewerben usw. stimmt auch komplett. Daher ist nicht jeder super "Programmierer" auch gleich ein guter "Software Entwickler". Ich denke da kann man recht gut die Abgrenzung ziehen/verstehen.

Persönlich versuche ich, keinen Unterschied (oder ihn zumindest klein zu halten) zwischen privaten Projekten und der Software Entwicklung und Testing im berufsalltag zu machen. Somit versuche ich immer die gleichen Standards zu haben und muss auch wenig Angst haben, hier oder da stark nachlässig zu sein oder zu werden.

Ich bin nicht der Beste Programmierer, bei weitem nicht, jedoch bezeichne ich mich als guten Software Entwickler und Tester 😊 .

Ich freue mich sehr das du das Thema so gut, facettenreich und "recht neutral" aufgegriffen hast. Finde sowas immer total spannend - Danke Andy 👍 .

Viele Grüße

Sven

Zitat von Andy

Ich persönlich bin kein Freund von solchen Zeilen: #AutoIt3Wrapper_AU3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7

Die angezeigten "Fehler" sind zu 99% keine und während der Entwicklung von Programmen behindern sie mich und stören meinen "Flow" und die Kreativität. Imho sind diese Zeilen dazu geeignet, nach (!) der Erstellung eines lauffähigen Script dieses "schön" zu machen. Was mich als Privatanwender (auch wenn ich Scripte sehr oft im beruflichen Leben verwende) einen Scheiss interessiert! Form follows function....

Dem kann ich nicht zustimmen. Ich hatte bisher keine Fehler die nicht auch welche waren (und ja, das man eine Variable definiert aber faktisch danach nicht nutzt, ist meiner Ansicht ein Fehler, denn unnötiger Code). Und Kreativität gehört für mich nicht in den Code, sondern das Programm selber.

Wenn Beipiele wie oben (der Variablenname ist unterschiedlich, von dir selber aufgezeigt) auftreten, kann das durchaus ein Tippfehler sein wo diese Fehlermeldung drauf zeigt (solche Zeilen gehören dann auskommentiert oder korrigiert). Auch das man strickt drauf achtet, das Variablen deklariert werden und das auch im richtigen Kontext (kein Local im Global scope z.B.)gehört für mich nicht zum"schön machen", sondern zum kleinen 1*1, da sonst Variablen im Global auftauchen können, die da gar nicht hin gehören (in anderen Sprachen sogar ein MUSS), usw..

Code "schön" machen ist für mich eher, sich an Einrückungen zu halten, keiner mag oneliner hinzubratzen etc. wobei ich auch da eher auf "Lesbarkeit" als "Schönheit" verweisen würde.

Ja, es ist Ansichtssache und soll kein "blame" sein aber gewisse Grundregeln gehören für mich dazu, auch wenn man alleine am Code arbeitet.

Und so hat eben jeder seine eigene Art bestmöglich an die Software Qualität heranzukommen, die er/sie entsprechend für richtig und gut bewertet/empfindet.
Ich bin bei allem was du sagst bei dir Moombas , wirklich, doch weiße ich darauf hin - und dies musste ich für mich erstmal lernen/verstehen - das es einen großen Unterschied macht ob man beruflich an Software arbeitet oder privat. Zudem ob man kleine oder große Projekte umsetzt im privaten oder beruflichen Kontext etc.

In einem Software-Entwicklungsteam mit bspw. Product Owner und Stakeholdern, ist man i.d.R. auch gezwungen Coding Guidelines, Code Conventions etc. einzuführen, damit man den Anforderungen die von außen kommen (nicht von einem selbst) gerecht werden kann.

Aber: Vielen Dank für deinen Beitrag und die Hinweise zum Thema 🤝 => spricht mir aus der Seele.

Viele Grüße
Sven

Zitat von Moombas

Ja, es ist Ansichtssache und soll kein "blame" sein aber gewisse Grundregeln gehören für mich dazu, auch wenn man alleine am Code arbeitet.

Naja, ich denke wir sind da sehr nahe beieinander^^

Wenn zu diesem Threadthema von jemandem der einen Namen wie der TE trägt ein "Fehler" wie oben gezeigt vorkommt, dann hat das sehe wenig mit deinen Ausführungen zu tun!

Das Problem ist die strikte und generelle Unfähigkeit, Fehler (in welcher Form auch immer) zu finden und abzustellen! Woher diese Unfähigkeit kommt und wie dabei die (von dir nachvollziehbar beschriebenen) "Hilfen" einer Programmiersprache jemanden weiterbringen, sei dahingestellt....

Jedenfalls sind 90% (eher mehr) Anfragen in den einschlägigen Programmier-Foren darin begründet, dass sich der Fragesteller mit dem Thema nicht oder nur oberflächlich befassen will, es wird stattdessen jemand gesucht, der einem "den Arm aus der Sonne legt", aka, die hingerotzten 5-10 Zeilen lauffähig macht!

Aber irgendwie glaube ich, dass diejenigen unter uns, die in der Lage sind sich in anderer Leute Code hineinzuversetzen und in kürzester Zeit die "Fehler" zu finden, einen wieauchimmer "Knacks in der Birne" haben.

Ich habe 13 Jahre mit einem Mitarbeiter zusammengearbeitet und immer mal wieder dessen Code debuggen müssen. Dabei saß ich immer neben ihm und habe genauestens erklärt was ich da mache und warum. 13 Jahre lang.....Mittlerweile ist es schon "viel" besser geworden, aber die Hilferufe kommen immer noch.....nicht mehr so oft, aber sie kommen?! Warum? Ich schreibe "Easy-Code", versuche nur die einfachsten Konstrukte zu benutzen, so dass jeder Dorfdepp in meinem Code lesen kann wie in einem Buch. Dafür musste ich mich vom Geschäftsführer einer (von uns verwendeten) führenden ERP-Branchensoftware als "Oldschool-Dinosaurier" bezeichnen lassen müssen. Die Retourekutsche drücke ich ihm jeden Monat wenn seine Jungs und Mädels als "Vollprofis" wieder mal programmiertechnischen Sondermüll abliefern. Wenn professionelle Datenbankspezialisten Funktionen abliefern die 1000x länger brauchen wie die eines "Freizeit-Oldschool-Dinosaurier"-Programmierers, dann sind wohl Nachfragen erlaubt. Genau wie danach, wieso gefixte Bugs nach diversen Updates "plötzlich" wieder auftauchen.....

Das Thema ist lang....aber

Zitat von SOLVE-SMART

In einem Software-Entwicklungsteam mit bspw. Product Owner und Stakeholdern, ist man i.d.R. auch gezwungen Coding Guidelines, Code Conventions etc. einzuführen

löst imho das eigentliche Problem nicht. Der nach den tollen Code Conventions (ich sag mal "schöne") Code soll in erster Linie fehlerfrei laufen! Was nützt mir ein fehlerbehafteter Code, der nach allen Regeln der Kunst "schick" gemacht ist, aber nicht oder nicht richtig funktioniert. Gerade dieser Code sollte doch am Besten zu debuggen sein, oder etwa nicht?! Dann sollten gerade bei solchem Code die Fixes doch im Handumdrehen gemacht werden können?!

Zitat von Andy

löst imho das eigentliche Problem nicht.

Ich gebe dir Recht Andy , dass es das Problem nicht ganz löst. Es verschlimmert es jedoch aber auch nicht und vermindert zumindest die unterschiedlichen Stile und deren Auswirkungen. Ich bin mir sicher du hast in deinen Leben schon sehr viel Code gesehen und an Code mitgewirkt, doch vielleicht hast du auch eine Stichprobe von Leuten gehabt, die nicht gerade leidenschaftlich entwickeln und ggf. auch wenig Ambitionen beim Testing haben 🤔 . Ich weiß es nicht.

Für mich kann ich sagen, dass ich in den vergangenen 10+ Jahren in verschiedenen Teams, in verschiedenen Unternehmen gut mit Coding Styleguide etc. gefahren bin. Muss ja nicht das Allheilmittel sein, auf keinen Fall. Doch die breite Masse der Unternehmen nutzen solche Coding Conventions. Daher denke ich, wird es schon seinen Grund haben.

An sich verstehe ich deine Argumentation jedoch voll und muss LEIDER beipflichten.

Viele Grüße
Sven

Zitat von Andy

Ich habe 13 Jahre mit einem Mitarbeiter zusammengearbeitet und immer mal wieder dessen Code debuggen müssen. Dabei saß ich immer neben ihm und habe genauestens erklärt was ich da mache und warum. 13 Jahre lang.....Mittlerweile ist es schon "viel" besser geworden, aber die Hilferufe kommen immer noch.....nicht mehr so oft, aber sie kommen?! Warum? Ich schreibe "Easy-Code", versuche nur die einfachsten Konstrukte zu benutzen, so dass jeder Dorfdepp in meinem Code lesen kann wie in einem Buch. Dafür musste ich mich vom Geschäftsführer einer (von uns verwendeten) führenden ERP-Branchensoftware als "Oldschool-Dinosaurier" bezeichnen lassen müssen. Die Retourekutsche drücke ich ihm jeden Monat wenn seine Jungs und Mädels als "Vollprofis" wieder mal programmiertechnischen Sondermüll abliefern. Wenn professionelle Datenbankspezialisten Funktionen abliefern die 1000x länger brauchen wie die eines "Freizeit-Oldschool-Dinosaurier"-Programmierers, dann sind wohl Nachfragen erlaubt. Genau wie danach, wieso gefixte Bugs nach diversen Updates "plötzlich" wieder auftauchen.....

Das erninnert mich an meine Azubi Zeit (Komm.Elektroniker), wo wir auch welche hatten, bei denen mann alles vorgeben mussten und kaum eine Schaltung ohne Fehler hin gebratzt haben und dann nicht mal in der Lage waren ihren Fehler selber zu finden (für mich war das wiederum eine gute Übung :P). Ich wunder mich bis heute wie die die Prüfung geschafft haben XD.

____

Btt: Warum ich das geschrieben habe: Wenn du Code nicht lesen kannst (weil schlecht angeordnet, oneliner etc.) wirst du ggf. Probleme haben ihn zu debuggen. Aber ich gebe dir Recht, die Basis von allem ist, den Code zu verstehen, nicht wie er "aufgeschrieben oder eingeordent" wurde.

Ich bin da voll bei Andy. In meinem Firmenumfeld genieße ich den Vorteil, dass ich als einziger im EDV-Bereich agiere und auch Programme für die Firma schreibe. Da ich mit allen Arbeitsgängen vertraut bin, kann ich aus der Sicht des Anwenders programmieren.
Bsp.
Unsere Fa. ist recht klein und sämtliche Buchhaltung geht über ein Steuerbüro. Wir erstellen nur Ausgangsrechnungen und registrieren Zahlungseingänge. Über viele Jahre wurden immer zusätzliche Kopien der Rechnungen ausgedruckt und am Monatsende zum Steuerbüro gebracht. Die durften den Kram (ca. 300-500 Rechnungen pro Monat) dann händisch erfassen.
Ich hab dann mal angefragt, ob deren DATEV-Programm auch den Import von Daten ermöglicht und in welcher Form das sein müsste.
Nach den Anforderungen habe ich dann ein SQL-Query erstellt, zum Export der Monats-RE in eine dbf-Datei. Diese habe ich dann (natürlich mit AutoIt ) in die DATEV-importierbare Form gegossen.
Um hier Fehler auszuschließen, habe ich auch gleich im Vorfeld nach möglichen variablen Größen gefragt und diese dann über eine INI festgelegt.
Das sind z.B. bei vereinzelten Kunden abweichende Werte: KDNr=Buchungskonto;Steuersatz
Das läuft jetzt schon ca. 10 Jahre und hat bestimmt einigen Bäumen das Leben gerettet.