StdoutRead-Beispiel @CRLF

  • Hallo,

    bin ich hier richtig? Eigentlich geht es nicht um ein Übersetzungsproblem, sondern um ein Problem in einem Beispiel-Script in der Hilfe-Datei, das schon im Englischen besteht. Dabei weiß ich nicht, ob dort ein Fehler ist, oder ich es nur falsch verstehe. Der Punkt ist, dass mich der Text dort mehr irritiert als er hilft.

    Details

    In der Hilfe für StdoutRead wird ein Beispiel gezeigt. In dem Beispiel steht ziemlich unten folgendes:

    Zitat

    ; Use StringSplit to split the output of StdoutRead to an array. All carriage returns (@CRLF) are stripped and @CRLF (line feed) is used as the delimiter.

    Local $aArray = StringSplit(StringTrimRight(StringStripCR($sOutput), StringLen(@CRLF)), @CRLF)

    Es geht um "@CRLF", was bekanntlich die Kombination darstellt aus "@CR" ( carriage return) und @LF (line feed). Beschrieben wird, dass alle CRs entfernt und LFs als Trenner benutzt werden. Jedoch ist beide Male die komplette Kombi genannt. Nachdem ich mich nun damit beschäftigt habe (bin weit weg von einem AutoIt-Profi), denke ich, es wäre vielleicht richtiger so:

    ; Use StringSplit to split the output of StdoutRead to an array. All carriage returns (@CR) are stripped and @LF (line feed) is used as the delimiter.

    Falls ich überhaupt richtig liege, ist dies, wie gesagt, kein Übersetzungsproblem, da es schon im englischen Text so steht. Aber vielleicht kann man es dennoch verbessern. ;)

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • @LF wird nicht als Delimeter benutzt, weil ja @CRLF an StringSplit übergeben wurde. ~> Siehe Post #5

    Generell scheint mir der Funktionsaufruf nicht viel Sinn zu machen.

    Das macht sich auch im ArrayDisplay bemerkbar, denn vom letzten Dateinamen werden Teile abgeschnitten.

    Local $aArray = StringSplit(StringTrimRight(StringStripCR($sOutput), StringLen(@LF)), @LF) wäre die korrekte Variante.

    Local $aArray = StringSplit($sOutput, @CRLF) die wesentlich bessere. (Wir gehen von Windows aus, dort gibts standardmäßig nur @CRLF).

    Im Bugtracker gibts übrigens auch kein Ticket dafür, ich würde dir anraten das dort zu erwähnen, oder wenn du nicht weißt wie man das macht kann ich das auch gerne übernehmen.

  • Hallo alpines, danke für die schnelle Antwort!

    @LF wird nicht als Delimeter benutzt, weil ja @CRLF an StringSplit übergeben wurde.

    Kann es nicht sein, dass die Übergabe von @CRLF an StringSplit richtig ist? Dann wäre es doch logisch, dass am Ende etwas abgeschnitten wird, wenn du als Längenangabe nur @LF nimmst, oder?

    Bin gereade dabei, mir den Code genauer anzusehen und es sieht so aus, als hättest du Recht! Ich werde es mir mal zu Ende ansehen und berichte dann. :)

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (26. Juni 2019 um 17:46)

  • Du hattest Recht, nicht nur der Kommentar in der Hilfe ist falsch, sondern auch die Anweisung. Kein Wunder, dass mich das Ganze mehr verwirrt als mir geholfen hat. :)

    Ich habe ein kleines Test-Projekt erstellt. Zur besseren Übersicht habe ich die Anweisung in eine eigene Funktion ausgelagert ("SplitIntoArray"), das Ganze auseinander gezogen und mit Debug-Infos versehen. Dadurch kann man im Outputfenster deutlich sehen, dass bei der letzten Datei ein Zeichen fehlt. (In diesem Beispiel steht dann "...au" statt "...au3".)

    Es hat sich gezeigt, was du schon vermutet hast, es wird der falsche Trenner übergeben. Allerdings zeigt sich im Test-Projekt schön, dass der Fehler bei "StringTrimRight" passiert.


    Test-Projekt Test - StdoutRead.zip

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Allerdings zeigt sich im Test-Projekt schön, dass der Fehler bei "StringTrimRight" passiert.

    Übrigens hätte das mit $STR_ENTIRESPLIT nicht funktioniert. Da aber der dritte Parameter standardmäßig $STR_CHRSPLIT ist, gibt das Hinweis darüber wie der Fehler durchrutschen konnte.

    Meine ursprüngliche Aussage, dass @LF nicht als Delimeter genutzt wird ist aber falsch, denn es liegt $STR_CHRSPLIT an, d.h. es wird nach jedem einzelnen Zeichen innerhalb des Delimeters gesplittet ~> @CR @LF

    Bitte melde das doch im Bugtracker damit das Hilfebeispiel gefixt werden kann oder sag bescheid wenn du es nicht machen möchtest, damit ich das Ticket erstellen kann.

    Sowas sollte nicht untergehen.

    Und jetzt zu deinem Beispiel, da sind einige Fälle die mich nachdenklich machen, vielleicht kannst du sie ja beantworten:

    Code
    Local $aArray
    SplitIntoArray($sOutput, $aArray)

    Erklär mir doch mal bitte den Gedanken dahinter.

    Wieso übergibst du ein leeres Array als Referenz damit es in der Funktion gefüllt werden kann? Du hättest in der Funktion einfach das Ergebnis vom StringSplit direkt returnen können und hättest diese Rückgabe dann in $aArray direkt speichern können, statt es in zwei Zeilen aufzuteilen.

    Das Array als Referenz zu übergeben macht in diesem Fall absolut keinen Sinn, weil du keine Performanceverbesserung davon hast, ist macht den Code nur unlesbarer.

    Die Funktionen in der Array.au3 z.B. erwarten (fast immer) ein volles Array, bzw. ein Array mit Daten, diese übergibt man per Referenz und nicht als Kopie, damit AutoIt intern das Array nicht duplizieren muss.

    Code
    Local $sStripedCR
    Local $sTrimedOutput
    
    ...
    
    $sStripedCR = ...
    $sTrimedOutput = ...

    Gut, da hätte ich persönlich nichts gegen einzuwenden, allerdings ist deine Funktion ziemlich klein und du benötigst explizit keine Deklaration da du nicht verzweigte Codepfade langläufst wo du in Deklarationsfehler reinstolpern könntest.

    Wenn du die Variablen am Anfang einer Funktion explizit deklarieren möchtest um zu zeigen welche Variablen in der Funktion verwedendet werden würde ich dir aber vielleicht anraten sie in eine Zeile zu packen, etwa wie Local $sStrippedCR, $sTrimmedOutput.

    Aber vielleicht bin ich auch einfach zu penibel und nimm es zu ernst, es soll ja nur ein Beispiel zum illustrieren sein :rolleyes_:

  • Was und wo ist Bugtracker? Und vermutlich wird dort englisch erwartet, was recht anstrengend ist für mich. (Oh, kein rot-werd-Smilie. Bitte einfach vorstellen, hier wäre eins.) Mein Englisch ist zum ;(

    Deine Antworten zum Code beantworte ich nachher, muss gleich mal weg.


    Edit: "nervig-bescheuertes" Smilie entfernt.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (26. Juni 2019 um 22:38)

  • Was und wo ist Bugtracker? Und vermutlich wird dort englisch erwartet, was recht anstrengend ist für mich.

    https://www.autoitscript.com/trac/autoit - Das gute Teil hier.

    Dort kann man Tickets erstellen die öffentlich eingesehen werden können und diese werden dann auch von den Entwicklern bearbeitet.

    Ich erstell das Ticket mal und wir sehen was dabei rumkommt. ~~> https://www.autoitscript.com/trac/autoit/ticket/3722

    (Oh, kein rot-werd-Smilie. Bitte einfach vorstellen, es wäre eins.)

    Das rolleyes-Smiley sieht seit WBB4 echt bescheuert "genervt" aus obwohl man es eigentlich nicht so meint. Das war der gute alte aus WBB3:

    Deshalb schreibe ich seitdem auch :rolleyes_: Die Mühe ständig das originale von irgendwoher zu verlinken will ich mir nicht machen.

  • Ich erstell das Ticket mal und wir sehen was dabei rumkommt. ~~> https://www.autoitscript.com/trac/autoit/ticket/3722

    Hallo alpines, dickes Lob und danke schön dafür! Nicht nur, dass ich das nicht so geschmeidig hingekriegt hätte, wie du, sondern das hast du so gut geschrieben, da hätte meins wie von einem Viertklässler ausgesehen. ;)

    Über den Drogen-Kommentar habe ich mich ausgeschüttet vor Lachen! :rofl:


    Deine Fragen zu meinem Demo wollte ich zwar auch noch beantworten, habe aber aufgeben müssen, da mein Kopf heute nicht mehr will. (Kommt nur noch Usinn bei raus, weil zu müde.) :sleeping: Morgen versuche ich es. Falls mein Kopf noch soweit funktioniert, einen Teil hast du im Bugtracker schon selbst beantwortet.

    Zitat

    If you break up the commands line by line it looks like this:

    Local $sStrippedCR = StringStripCR($sOutput)

    Local $sTrimmed = StringTrimRight($sStrippedCR, StringLen(@CRLF))

    Local $aArray = StringSplit($sTrimmed, @CRLF)

    Sieht doch aus wie in meinem Demo, wenn man ConsoleWrite und Kommentare weg lässt:

    Zitat

    $sStripedCR = StringStripCR($sOutput)

    $sTrimedOutput = StringTrimRight($sStripedCR, StringLen(@CRLF))


    $aArray = StringSplit($sTrimedOutput, @CRLF)

    Gute Nacht!

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Gut dass du den Bugtracker geschrieben hast. Mein Englisch hält sich in Grenzen und meiner Meinung nach entbehrt Englisch eine durchgehenden Logik. Ich war schon stolz, von StringStripCR auf striped zu schließen. Und das war schon richtig gut, denn anfangs habe ich überlegt es einfach $sTmp1 usw. zu nennen, :P Aber das führt zu weit.

    (Nun gut, einen noch: Kann es sein, dass du englisch "denkst"? Du hast von "Fällen" gesprochen, was eine ungewöhnliche Formulierung darstellt. Hattest du da vielleicht "Issues" im Sinn? )


    Kommen wir nun zu deinen Fragen. Das ist gar nicht leicht zu beantworten. Nun habe ich sie mehrmals durchgelesen, und bin mir nicht sicher, ob ich es verstehe. Aber ich versuchs mal. :)

    Wieso übergibst du ein leeres Array als Referenz damit es in der Funktion gefüllt werden kann? Du hättest in der Funktion einfach das Ergebnis vom StringSplit direkt returnen können und hättest diese Rückgabe dann in $aArray direkt speichern können, statt es in zwei Zeilen aufzuteilen.

    Das Array als Referenz zu übergeben macht in diesem Fall absolut keinen Sinn, weil du keine Performanceverbesserung davon hast, ist macht den Code nur unlesbarer.

    Bitte sei nachsichtig mit mir, ich habe seit Jahren nicht mehr programmiert. ;) Ehrlich gesagt war ich erstaunt und mächtig stolz, dass ich das überhaupt so gut hingekriegt habe! Zudem war ich aufgeregt darüber, ob mein vermeintlicher Fehlerfund in der Hilfe überhaupt einer ist. Als du dann ins Details gegangen bist, hat mich das motiviert, mich eingehender damit zu befassen. Das Demo habe ich quick-and-dirty erstellt, es sollte nur das Wesentliche veranschaulichen, weshalb ich den Code in eine Funktion verfrachtet habe. Notwendig, oder gar Performance-steigernd sollte das nicht sein. Nur deutlich.

    Dss Arrays habe ich als Referenz an die Funktion übergeben, weil es in dem Moment schnuppe war, effektiven Code zu schreiben. Da ich aus der Übung war, sah ich mir die Hilfe zu "Func" an. Hilfeseite sehr groß, ich in Eile, nur gelesen "Arrays als ByRef übergeben ..." und voila: Schnell zusammengeklöppelt. Hat also keinen tieferen Sinn. (Hinzu kam, dass ich auf die Schnelle nicht wusste, ob man ein Array einfach so retunen kann.)

    ... allerdings ist deine Funktion ziemlich klein und du benötigst explizit keine Deklaration da du nicht verzweigte Codepfade langläufst wo du in Deklarationsfehler reinstolpern könntest.

    Wenn du die Variablen am Anfang einer Funktion explizit deklarieren möchtest um zu zeigen welche Variablen in der Funktion verwedendet werden würde ich dir aber vielleicht anraten sie in eine Zeile zu packen, etwa wie Local $sStrippedCR, $sTrimmedOutput.

    Deklarationen an den Anfang zu setzen war zu meiner Zeit guter Programmierstil. Ist das heute nicht mehr so? Ich persönlich deklariere tatsächlich am liebsten untereinander, statt nebeneinander. Und möglichst "sprechende Namen", statt §sString1, $sString2, ... Ist wohl Geschmackssache. Letztens hatten wir das Thema User-Shortcuts. Die könnte man auch alle in eine Reihe schreiben, aber ich bevorzuge die aufgeteile Schreibweise:

    Was anderes: Ich habe glaube ich einen weiteren "Fehler" gefunden, diesmal in der deutschen Übersetzung. Sieh's dir mal an, sag ob's richtig ist und ob es in einen extra Thread soll.

    Beim Durchlesen der Hilfe zu "Func" ist mir folgendes aufgefallen:

    Nach dem Wort "Remarks" der dritte Abschnitt.

    EN: Declaring parameters as both ByRef and Const is useful when the large original variable must remain unchanged as AutoIt will return an error if the function attempts to alter it inadvertantly.

    DE: Das Deklarieren von Parametern als ByRef und Const ist nützlich, wenn die große ursprüngliche Variable unverändert bleiben muss, da AutoIt einen Fehler zurückgibt, wenn die Funktion versucht, sie versehentlich zu ändern.

    Die einfache Formulierung "ByRef und Const" ist nicht stark genug, um zu zeigen, dass damit eine Kombination gemeint ist. Der englische Begriff "both" ist darin nicht berücksichtigt. Meine Vorschläge wäre:

    Das Deklarieren von Parametern mit der Kombination von ByRef und Const ist nützlich,

    Das Deklarieren von Parametern mit beiden Schlüsselwörtern ByRef und Const zusammen ist nützlich,

    Beim Deklarieren von Parametern ist die Kombination von ByRef und Const nützlich,

    Das Deklarieren eines Parameters mit beidem (Const ByRef) ist nützlich,


    Desweiteren fände ich eine Umstellung der Wörter im Schlussbereich verständlicher. Mein Vorschlag:

    wenn die Funktion versehentlich versucht, sie zu ändern.

    Oder "versehentlich" ganz weg lassen.

    wenn die Funktion versucht, sie zu ändern.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    7 Mal editiert, zuletzt von Professor Bernd (27. Juni 2019 um 12:18)

  • Gut dass du den Bugtracker geschrieben hast.

    Es wurde übrigens auch schon darauf geantwortet und das Beispiel wird für die kommenden Versionen angepasst werden.

    (Nun gut, einen noch: Kann es sein, dass du englisch "denkst"? Du hast von "Fällen" gesprochen, was eine ungewöhnliche Formulierung darstellt. Hattest du da vielleicht "Issues" im Sinn? )

    Frag nicht, ich weiß selbst kaum was in meinen Gedanken abgeht.

    Ehrlich gesagt war ich erstaunt und mächtig stolz, dass ich das überhaupt so gut hingekriegt habe! Zudem war ich aufgeregt darüber, ob mein vermeintlicher Fehlerfund in der Hilfe überhaupt einer ist. Als du dann ins Details gegangen bist, hat mich das motiviert, mich eingehender damit zu befassen. Das Demo habe ich quick-and-dirty erstellt, es sollte nur das Wesentliche veranschaulichen, weshalb ich den Code in eine Funktion verfrachtet habe. Notwendig, oder gar Performance-steigernd sollte das nicht sein. Nur deutlich.

    Das ist auch toll, dass du direkt ein Beispiel erstellt hast um das ganze zu verdeutlichen. Sowas brauchen wir in der AutoIt Community - Hut ab.

    Es ist vermutlich auch Haarspalterei von mir zu sagen, du hättest lieber den Wert returnen sollen als ByRef aber es sah für mich etwas komisch aus, und deshalb dachte ich "fragste doch nochmal nach".

    Deutlicher wäre es für die meisten wohl gewesen wenn es returnt wäre aber das sei mal jedem selbst überlassen welche Variante er bevorzugt.

    Dss Arrays habe ich als Referenz an die Funktion übergeben, weil es in dem Moment schnuppe war, effektiven Code zu schreiben. Da ich aus der Übung war, sah ich mir die Hilfe zu "Func" an. Hilfeseite sehr groß, ich in Eile, nur gelesen "Arrays als ByRef übergeben ..." und voila: Schnell zusammengeklöppelt. Hat also keinen tieferen Sinn. (Hinzu kam, dass ich auf die Schnelle nicht wusste, ob man ein Array einfach so retunen kann.)

    Lustigerweise wäre deine Variante theoretisch "performanter" aber der Unterschied ist so vernachlässigbar gering, dass es schon absurd ist - zumindest in diesem Beispiel.

    Deklarationen an den Anfang zu setzen war zu meiner Zeit guter Programmierstil. Ist das heute nicht mehr so? Ich persönlich deklariere tatsächlich am liebsten untereinander, statt nebeneinander. Und möglichst "sprechende Namen", statt §sString1, $sString2, ... Ist wohl Geschmackssache.

    Jedem das Seine - es soll jeder machen wie er es für gut hält. Es gibt gewisse Konventionen die sich über die Jahre etabliert haben damit man fremden Code einfacher lesen kann aber das sind nur Konventionen, keine unbrechbare Regeln.

    Ich deklariere auch Variablen untereinander, aber nur wenn die Zeile sonst zu lang wird. Zusammenhängene packe ich gerne hintereinander.

    Du kannst bei größeren Skripten Probleme bekommen wenn du am Anfang der Funktion bereits alle Variablen deklarierst wenn du globale Variablen mit dem selben Namen hast.

    Schau dir mal das Beispiel an:

    Es mag vielleicht etwas konstruiert aussehen aber wenn man globale Variablen ansprechen möchte, in Fällen wo einige Parameter nicht gegeben sind, wird stattdessen die lokale genommen.

    Statt dem Output Ich esse gerne "Erdbeere". steht dort nun Ich esse gerne "".

    Was anderes: Ich habe glaube ich einen weiteren "Fehler" gefunden, diesmal in der deutschen Übersetzung. Sieh's dir mal an, sag ob's richtig ist und ob es in einen extra Thread soll.

    Den Vorschlag postest du bitte hier: Fehler in der deutschen Hilfe bitte hier melden (Hilfedatei 3.3.14.5 2019.03.24)

    An sich ist das ein vernünftiger Einwand.

  • Den Vorschlag postest du bitte hier: Fehler in der deutschen Hilfe bitte hier melden (Hilfedatei 3.3.14.5 2019.03.24)

    Ist schon geschehen. :) Vielen Dank fürs Drüberschauen und weiteres Lob von dir!

    Bugtracker: Habe ich gesehen. Freut mich!

    Du findest im Editor den "</>"-Button für Code, wähle als Sprache AutoIt aus und paste ihn dann rein.

    Das ist aus einem anderen Thread, aber vielleicht kannst du mir kurz helfen. "AutoIt" finde ich in den Codes nicht, was nimmt man denn da am besten?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Das ist auch toll, dass du direkt ein Beispiel erstellt hast um das ganze zu verdeutlichen. Sowas brauchen wir in der AutoIt Community - Hut ab.

    Danke für das Lob! Ein Beispiel sagt mehr als 1.000 Worte!

    Es ist vermutlich auch Haarspalterei von mir zu sagen, du hättest lieber den Wert returnen sollen als ByRef

    Hier war das zwar nicht relevant, aber bei Anfragen zur Programmiertechniken oder sonstigem Code bin ich für solche Tipps grundsätzlich dankbar! Das liegt auch an der Natur von Tipps: Man kann sie verwenden, muss aber nicht. :thumbup:Tipps sind oft derart, dass man da kaum von selbst drauf gekommen wäre. Manche Dinge sind auch "verdreht": Kennt man sie -> man braucht sie nicht, und kein Problem. Kennt man sie nicht -> man würde sie brauchen, aber wie soll man dann danach fragen, wenn man nichs davon weiß!? ... Rede lang, Sinn kurz: Für Tipps bin ich immer zu haben! :)

    Deklarationen

    Erst mal ein Lob für schnelle Zusammenklöppeln deines Beispiels!

    Du kannst bei größeren Skripten Probleme bekommen wenn du am Anfang der Funktion bereits alle Variablen deklarierst wenn du globale Variablen mit dem selben Namen hast.

    Natürlich kann jeder seine Ansicht haben. Nach meiner Ansicht hilft gerade das zentrale Deklarieren beim Vermeiden solcher Überschneidungen. Mit zentral meine ich: Beim Script ganz am Anfang nach den Includes, und bei Routinen ganz am Anfang der jeweiligen.

    Es mag vielleicht etwas konstruiert aussehen aber wenn man globale Variablen ansprechen möchte, in Fällen wo einige Parameter nicht gegeben sind, wird stattdessen die lokale genommen.

    Da bin ich der Meinung, dass lokale Variablen die globalen immer überschreiben. Zur Verdeutlichung habe ich dein Beispiel ein wenig ergänzt. Da die Forensoftware kein AutoIt-Highlighting bietet und meine Formatierung zerfledert hat, habe ich es schnell hochgeladen. ;)

    Test lokale Variable vs globale.zip

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Da bin ich der Meinung, dass lokale Variablen die globalen immer überschreiben.

    Das ist auch richtig so, naja - vielleicht ist es ein wenig unglücklich formuliert.

    Existiert eine Variable im globalen Scope ist diese innerhalb einer Funktion solange verfügbar, bis eine Variable mit dem selben Namen innerhalb des Funktionsscopes deklariert wurde.

    Danach kannst du meines Wissens nach die globale Variable - nach der Deklaration in der Funktion - nicht mehr referenzieren.

    Das Beispiel sollte ja darauf abzielen, dass man innerhalb der Funktion eine globale Variable mit dem selben Namen anspricht aber dies nicht mehr geht, weil eine lokale deklariert worden ist und deswegen derleere String ausgegeben wird obwohl "Erdbeere" hätte ausgeben werden müssen.

    So einen Fehler zu finden ist schwierig, da es kein syntaktischer sondern semantischer Fehler ist, das kann dir kein Compiler der Welt sagen.

    Ganz düster siehts aus wenn du die Deklaration mal oben in der Funktion hast, und in anderen Funktionen mittendrin, da du dann komplett durcheinander kommst und nicht mehr weißt ob du grad eine lokale oder globale Variable ansprichst.

    Deshalb gibt es den Programmiergrundsatz nur Elemente so lange am Leben zu halten, wie sie benötigt werden, damit Überschneidungen vermieden werden können.

    OT:

    Übrigens kannst du au3-Dateien direkt anhängen ohne sie vorher zippen zu müssen.

    Außerdem musst du nicht unbedingt "in den Text einfügen" (oder wie das heißt) anklicken. Fügst du den Download nicht ein, hast du unter dem Beitrag ein Anhangsbereich wo man sogar Downloadzahlen sehen kann.

    Interessant wenn du Skripte veröffentlichen möchtest und sehen willst wie viele es schon heruntergeladen haben.

  • Damit globale Variablen innerhalb einer Funktion nicht ausgehebelt werden, was der Fall wäre, wenn eine lokale Variable mit gleichem Namen deklariert wird, beginnen bei mir alle globale Variablen mit $g_, denn dann passiert sowas nicht. Zudem habe ich mir von BugFix folgende Form abgekupfert, um Parameter optisch leichter von globalen/lokalen Variablen unterscheiden zu können: $_sParam1

  • Hallo Bitnugger.

    Genial! :thumbup:Manchmal kommt man selbst nicht auf die einfachsten Sachen. :Face:Und unglaublich, nun kann ich erneut schreiben: Vielen Dank für diesen Tipp! Das war schon der zweite der besonders wertvollen Art, nach dem man nicht fragen kann. (Wie das gemeint ist, steht irgendwo weiter oben.)

    Die globalen Variablen mit "$g_" zu kennzeichnen findet meine volle Zustimmung/Begeisterung! Das ist simple und effektiv. Funktionsparameter mit "$_" zu kennzeichnen ist ähnlich effektiv, nur irgendwas war da noch. :/ Mich beschäftigt, dass ich mir bei C++ ebenfalls eine effektive Namensgebung erdacht hatte. Leider ist das fast 10 Jahre her und fällt mir nicht mehr ein.

    Auf jeden Fall danke für die Tipps!

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Und zu Zeile 13 sagst du nichts? 8o

    Die hatte ich noch nicht bemerkt. ... Ist bestimmt eine Fangfrage. (Ich hasse reguläre Ausdrücke.) 8o

    Ok, ich sehe es mir an. Ob ich da durchblicke? Ich melde mich dann.

    Edit: Komme mir gerade vor wie in der Schule: "So, Hefte weg, wir schreiben einen Überraschungstest!"

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.