[ruby-de] String-Bearbeitung, gsub

Jörg W Mittag ruby-de at joergwmittag.de
Mi Aug 30 15:13:29 JST 2017


Hallo,

> "ab/cd".gsub( /\/(.)/,  "\\1".upcase)        # => "Abcd"
> # auf das wesentliche komprimiert
> Warum wird das .upcase nicht ausgeführt?,

Wie *genau* hast du festgestellt, dass `upcase` nicht ausgeführt
wird? Ich habe es mit verschiedenen Mitteln getestet: ich habe
einen Debugger verwendet, um das Skript Schritt für Schritt
auszuführen, und konnte daher beobachten, dass die Ausführung in
der Tat in die `upcase`-Methode hinein springt, und diese
vollständig und ohne Fehler ausgeführt wird. Ich habe einen
Profiler verwendet, und habe verifiziert, dass `upcase` in der
Tat im Profil auftaucht, sprich, dass die `upcase`-Methode auch
tatsächlich ausgeführt wurde. Ich habe die `TracePoint`-API
verwendet, um sämtliche Methoden-Aufrufe nachzuverfolgen, und
konnte daher verifizieren, dass `upcase` definitiv aufgerufen
wird. Ich habe `String#upcase` re-definiert, so dass es auf die
Konsole schreibt, wenn es aufgerufen wird, und wieder konnte ich
so verifizieren, dass die Methode definitiv vollständig und ohne
Fehler oder Ausnahme bis zum Ende ausgeführt wird.

Um es kurz zu machen: egal, was ich auch anstelle, es gelingt mir
*nicht*, dein Problem nachzuvollziehen. In *jedem* Test, den ich
mache, *wird* `upcase` ausgeführt.

Daher meine Frage: könntest du bitte den Testfall, mit dem du
festgestellt hast, dass `upcase` nicht ausgeführt wird, zur
Verfügung stellen, damit ich das Problem nachstellen kann? Wenn
das Problem nicht nachstellbar ist, dann ist es sehr schwer, es
zu diagnostizieren, und unmöglich festzustellen, wenn es behoben
ist.

Natürlich enthält der String keinerlei Kleinbuchstaben sondern
lediglich einen Backslash und eine Ziffer, so dass `upcase`
ohnehin nichts tun wird, aber das Problem ist ja momentan erstmal,
dass – wie du sagst – `upcase` von vorne herein überhaupt gar
nicht ausgeführt wird.

> wie tut man das (gehts auch ohne Block)?

Das kommt darauf an, was „das“ ist.

Das ist leider zu wenig und zu unpräzise Information, um dir
helfen zu können. Was *genau* ist das Problem? Wird eine Ausnahme
aufgeworfen? Wenn ja, welche? In welcher Zeile? Wie sieht der
Aufrufstapel aus? Was ist die Nachricht? Gibt es eine
Fehlermeldung? Wenn ja, welche? Wie lautet sie genau? Stimmt das
tatsächliche Ergebnis nicht mit dem erwarteten Ergebnis überein?
Wenn ja, was ist das erwartete Ergebnis (und warum), was ist das
tatsächliche Ergebnis und wie genau unterscheiden sie sich (und
warum und in welcher Form ist dieser Unterschied relevant)? Stimmt
das beobachtete Verhalten nicht mit dem erwarteten Verhalten
überein? Wenn ja, was ist das erwartete Verhalten (und warum), was
ist das beobachtete Verhalten und wie genau unterscheiden sie sich
(und warum und in welcher Form ist dieser Unterschied relevant)?

Es ist auch unklar, was du mit „das“ meinst. Was genau ist das
„das“, welches du erreichen möchtest? Kannst du eine *präzise*
Spezifikation liefern, was genau du erreichen möchtest, inklusive
aller Regeln, Ausnahmen, Grenzfälle und Spezialfälle? Kannst du
Beispiele für Eingaben und die erwünschten Ausgaben / Ergebnisse
geben, die sowohl das normale Verhalten als auch die Ausnahmen,
Grenzfälle und Spezialfälle demonstrieren?

Was ist der größere Kontext dieses Quelltextes? Was soll er als
Teil eines größeren Systemes bezwecken?

Das Problem ist, dass dein „Problem“ kein Problem ist. Es ist ein
hingeworfenes Schnipsel Quelltext ohne Erklärung, was der Sinn und
Zweck dieses Schnipsels ist, wovon es ein Teil ist, was es tut,
was es tun *soll*.

Übrigens, mir ist aufgefallen, dass deine Fragen unglaublich
schwer zu beantworten sind. Das hat jedoch nichts damit zu tun,
dass die Fragen selbst so hart wären, ganz im Gegenteil: die
überwiegende Mehrzahl ist absolut trivial und lässt sich durch
kurzes Überfliegen der Dokumentation, Lesen der Fehlermeldung,
oder eine kurze Google-Suche innerhalb von Sekunden lösen. Das
Problem ist, dass die Fragen dermaßen unklar gestellt sind, dass
es typischerweise ein mehrtägiges hin und her an Gegenfragen und
(oftmals ebenso unklaren) Ergänzungen erfordert, um überhaupt den
Hauch einer Chance zu haben, zu verstehen, *was* die Frage ist.

Darum hier ein paar Tipps zum Stellen besserer Fragen:

* Aussagekräfige Betreffzeile: die Betreffzeile sollte kurz und
    knapp das Thema der Frage beschreiben. Die Betreffzeile ist
    das erste (und typischerweise auch das einzige), das ein
    potenzieller Helfer zu Gesicht bekommt, um zu entscheiden, ob
    ihn das Thema interessiert und ob er die nötige Expertise hat.
    Ein guter Trick zum Schreiben einer guten Betreffzeile ist,
    die Betreffzeile als *letztes* zu schreiben, nachdem du deine
    Frage vollständig ausformuliert hast.

    Deine Betreffzeilen sind fast ausschließlich unglaublich
    generisch und sagen absolut nichts über den Inhalt aus.
    Oftmals sind sie zudem auch noch irreführend und haben –
    nachdem man denn irgendwann mal die Frage verstanden hat –
    nur am Rande (wenn überhaupt) mit der Frage zu tun. In diesem
    Falle lautet die Betreffzeile zum Beispiel „String-
    Bearbeitung, gsub“, die Frage beschäftigt sich dann aber mit
    `upcase`.

    Stelle dir vor, ein vollkommen Fremder hält dich auf der
    Straße an und sagt nichts weiter als „String-Bearbeitung,
    gsub“. Und mit dieser Ansprache möchte er dich dazu bewegen,
    deine Arbeit ruhen zu lassen und *kostenlos* deine Freizeit
    (oder deine Arbeitszeit(!!!)) exklusiv für ihn zu opfern, um
    eine Arbeit zu machen, die eigentlich *seine* Aufgabe wäre.
    Würde dich diese Ansprache überzeugen? Enthält sie genug
    Informationen, um zu entscheiden, ob es sich lohnt, deine Zeit
    kostenlos zur Verfügung zu stellen? Zeugt diese Ansprache
    davon, dass der unbekannte Fremde selber hinreichend an der
    Lösung des Problems interessiert ist, dass er bereit ist,
    signifikante Zeit und Ressourcen zu opfern, um mit dir an der
    Lösung des Problems zusammen zu arbeiten?

* Eine klar, präzise, unmissverständlich und nachvollziehbar
    formulierte Problemstellung, mit eindeutigen und objektiven
    Kriterien für eine Lösung des Problems. Wir wissen absolut
    nichts über dein Problem, dein System, deinen Quelltext, deine
    Architektur, deinen Entwurf, kurz den gesamten Kontext. All
    das muss aus der Problembeschreibung hervorgehen! Und zwar in
    einer Art und Weise, dass es unmissverständlich klar ist.

    Das ist nicht nur wichtig, weil ohne alle diese Informationen
    und den Kontext eine Beantwortung der Frage schlicht nicht
    möglich ist. Es ist auch und vor allem deswegen wichtig, weil
    Computer unglaublich dumm sind. Viel, viel, viel dümmer als
    Menschen! Sie verstehen keinen Kontext, sie haben keine
    Kreativität, sie können keine Nachfragen stellen. Wenn du
    nicht in der Lage bist, dich klar, präzise und nachvollziehbar
    in einer Art und Weise auszudrücken, dass Menschen dich
    unmissverständlich verstehen, dann ist es erst recht 100%
    absolut undenkbar, dass ein Computer dich verstehen wird,
    sprich dass du jemals in der Lage sein wirst, ein Programm zu
    schreiben.

    Wichtig ist auch, dass es objektive und klare Kriterien gibt,
    an denen die Leute, die hart kostenlos für dich an deinen
    Problemen arbeiten, erkennen können, ob sie Fortschritte
    machen, wie weit sie noch von einer Lösung entfernt sind, wann
    sie damit aufhören können, und ob sie dein Problem korrekt
    gelöst haben. Deine Problembeschreibung sollte alle nötigen
    Informationen enthalten, die nötig sind, um zu sagen: „Ja,
    das ist exakt, was er möchte, das Problem ist gelöst.“

* Achte darauf, dass deine Frage auch tatsächlich eine Frage ist.
    Deine Fragen sind oftmals gar keine Fragen sondern einfach nur
    eine Beschreibung dessen, was passiert. (Oder noch schlimmer:
    einfach nur ein Quelltext-Schnipsel ohne irgendwelche
    Informationen.) Aber, was hast du erwartet? Was meinst du,
    das statt dessen hätte passieren sollen? Und warum? Worin
    unterscheidet sich das, was du beobachtest von dem was du
    erwartest? Gab es eine Fehlermeldung? Wie lautet sie? Wurde
    eine Ausnahme aufgeworfen? Welche? Wie lautet die Nachricht?

* Wichtig ist auch, darzulegen, welche Anstrengungen du bisher
    unternommen hast, das Problem zu lösen, wie und warum diese
    nicht funktioniert haben, und warum du keinerlei andere
    Lösungswege mehr siehst. Nicht nur zeigt das einem
    potenziellen Antworter, dass du nicht darauf aus bist, einfach
    nur aus Faulheit kostenlos jemand anderen deine Arbeit machen
    zu lassen, sondern tatsächlich selber mindestens so hart an
    der Lösung arbeitest wie wir. Noch viel wichtiger ist, dass
    wir nicht sinnlos unsere Zeit damit verschwenden, Lösungswege
    zu verfolgen, welche du bereits ausführlich und gründlich
    untersucht und für unwirksam befunden hast.

    In diesem Falle habe ich zum Beispiel fast eine Stunde damit
    verbracht, zu versuchen, dein Problem nachzustellen, und es
    ist mir nicht gelungen. Egal, was ich auch versuche, `upcase`
    wird *immer* ausgeführt. Jetzt habe ich eine ganze Stunde
    meiner Arbeitszeit auf dein Problem verwendet und bin noch
    keinen Schritt weiter zur Lösung des Problems, ja, es ist mir
    noch nicht einmal gelungen, das Problem zu reproduzieren! Das
    ist nicht nur für mich ärgerlich und unbefriedigend sondern
    auch für dich, denn schließlich ist dein Problem weiterhin
    ungelöst. Ich hätte mir diese Stunde sparen können, wenn du
    z.B. dazu geschrieben hättest: „Ich habe versucht, das Problem
    mittels eines Debuggers, eines Profilers, der `TracePoint`-API
    und Re-Definierung der Methode zu reproduzieren, aber es ist
    mir nicht gelungen. Es tritt nur unter folgenden Umständen
    auf: …“

Hier sind ein paar Verweise auf Artikel, die gute Hinweise geben,
wie man gute Fragen formuliert:

How do I ask a good question?
https://stackoverflow.com/help/how-to-ask

Writing the perfect question
https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/

How To Ask Questions The Smart Way
http://catb.org/~esr/faqs/smart-questions.html

How to create a Minimal, Complete, and Verifiable example
https://stackoverflow.com/help/mcve

The SSCCE – Short, Self Contained, Correct (Compilable), Example
http://sscce.org/

How to debug small programs
https://ericlippert.com/2014/03/05/how-to-debug-small-programs/

Beste Grüße,
    Jörg.


Mehr Informationen über die Mailingliste ruby-de