P
19. Dez. 2007, 12:34
Wenn ein neuer Post diese Regeln grob missachtet, wird er einiger Wahrscheinlichkeit nach ignoriert oder geschlossen.
Stelle eine präzise Frage!
Poste keinen langen Code, sondern reduziere ihn auf das wesentliche Problem!
Keine (Haus)aufgaben!
Du stellst fest, dass Du gerade dabei warst, einen solchen Post zu verfassen, und möchtest genau verstehen, wie Du ihn tauglich machst? Lies weiter.
Reduziere Codebeispiele auf das Wesentliche. Niemand wird sich 300 Zeilen Code durchlesen, wenn du dein Problem eigentlich auch an 20 Zeilen deutlich machen könntest. Und je weniger du den Leuten zumutest desto wahrscheinlicher ist es, dass sie es sich durchlesen (und evtl. eine Antwort haben). Siehe unten für eine genauere Anleitung zum Posten reduzierter Beispiele.
Frage nach dem, was du erreichen willst und nicht danach womit du es erreichen willst. Es kommt des Öfteren vor, dass Leute zielgerichtet Fragen stellen, wie sie z.B. eine bestimmte Funktion auf eine bestimmte, ungewöhnliche Art und Weise nutzen können. Im Laufe längerer Diskussionen kommt dann heraus, dass sie ein konkretes Problem lösen wollen und der Meinung sind, diese Funktion sei das richtige Werkzeug. Oft kommt dann ein Vorschlag, wie man das Problem anders (meist eleganter und nicht mit so ungewöhnlichen Mitteln) lösen kann. In so einem Fall kann einem viel schneller geholfen werden, wenn man das zu lösende Problem gleich zu Anfang mit schildert, denn die Frage "Was willst du damit eigentlich erreichen?", oft gepaart mit der Feststellung "Sieht nach Designfehler aus..." kommt bestimmt! Trotzdem den eigenen Lösungsansatz nicht vergessen, denn das zeigt dass du dich mit dem Problem beschäftigt hast und nicht auf Musterlösungen aus bist.
Wir machen keine Hausaufgaben! Verlange keine Komplettlösungen. Hier im Forum gehts um Hilfe bei spezifischen Problemen, nicht darum, irgendjemandem die Hausaufgaben zu machen, der einfach nur zu faul ist. Wer danach sucht kann bei einem kostenpflichtigen Dienstleistungsunternehmen anfragen, nicht hier. Wenn du deine Aufgaben bearbeitest und dabei auf ein für dich unlösbares Problem stößt helfen wir natürlich gerne weiter. Sei aber nicht enttäuscht wenn du nur Hinweise bekommst, wo das Problem liegen könnte. Mit einer Komplettlösung ist weder dir noch uns geholfen - daraus lernst du nur wenig und wir müssen dir bei der nächsten Gelegenheit eine ähnliche Frage noch einmal beantworten.
Das Forum ist kein Ersatz für Eigeninitiative. Bemühe Bücher, Tutorials, Dokumentationen, Referenzen und Suchmaschinen bevor du fragst. Jemand der offenbar einfach zu faul ist um kurz nach ein oder zwei Stichworten zu googlen erntet schnell den Unmut der anderen Forenuser oder wird gleich ignoriert. Zeig was du selber geleistet hast, dann wird dir auch weitergeholfen.
Sei dir sicher, dass du im richtigen Forum bist. Dieses Forum ist für Standard C++ und nur dafür gedacht. Es gibt hier andere Unterforen für C, Java, PhP usw. Auch Fragen, die sich um ein bestimmtes Framework (GUI-Fra,eworks, WinAPI usw.) drehen, haben einen angemesseneren Platz. Wenn du gleich im richtigen Forum postest, können die richtigen Leute schneller deine Frage lesen - und beantworten. Siehe auch "Wohin mit meiner Frage?"
Wähle einen aussagekräftigen Threadtitel. Threads wie "Habe da ein Problem." oder gar "BRAUCHE HILFE!!!11einseinself" werden gern mal geflissentlich ignoriert. Ein (kurzer) Auszug aus einer Fehlermeldung oder eine kurze Beschreibung dessen, was dir Probleme bereitet (z.B. "Fehlermeldung bei Rückgabewert von überladenem Operator", "Compiler bemängelt 'undefined reference' bei templates" etc.) erregt mehr Aufmerksamkeit, vor allem bei Leuten die das Problem vielleicht lösen könnten.
Stelle höfliche Fragen, keine Forderungen. Die Leute hier machen das aus Spass an der Freude, nicht weil sie ein bezahltes Dienstleistungsunternehmen sind. Wer den falschen Ton anschlägt, vergrault seine Helfer. Wenn dir jemand deine Frage nicht zufriedenstellend beantworten konnte oder die Antwort nicht dein Problem trifft, formuliere deine Frage anders (und genauer). Ungeduldig und ausfallend zu werden hilft da nicht weiter (Ist aber schon vorgekommen. Diejenigen mussten dann feststellen dass mehr über ihren Tonfall als über ihr Problem geschrieben wurde).
Stell deine Fragen präzise. Mache deutlich, was du erreichen willst, was du bereits erreicht hast und wo aktuell dein Problem liegt. Ein kurzer, aussagekräftig kommentierter Codeausschnitt besagt oft mehr als seitenweise umständliche Beschreibungen oder falsch benutzte Fachausdrücke, die zu Missverständnissen führen. Halte dich aber auch nicht zu kurz, denn ein "funktioniert nicht" wird hier meist mit Hinweisen auf die defekte Glaskugel geahndet - wir sind alle keine Wahrsager. Man bringt schliesslich sein Auto auch nicht zum Mechaniker und sagt nur "Da ist was kaputt".
Schreib lesbar. Seitenlange Monologe ohne Satzzeichen sind schwer lesbar, das wird sich also kaum einer freiwillig antun. Gleiches gilt für durchgehend schlechtes Deutsch. Lieber ein, zweimal korrekturlesen als Gefahr zu laufen dass der Text ignoriert wird. Wer sich des Deutschen nicht ausreichend mächtig fühlt kommt vielleicht mit Englisch weiter (auch wenn nicht jeder hier Englisch kann). Google translate ist im Normalfall keine gute Idee, da die Übersetzungen scheußlich sind. In dem Fall am Besten die Frage in Originalsprache mitposten, insbesondere wenn die Originalsprache Englisch ist.
Formatiere deinen Code. Du musst Code in deinem Beitrag kenntlich machen, sonst ist er für andere nur schwer lesbar. Setze in der Zeile vor und nach deinem Code jeweils drei Backticks ```, oder benutze den Formatierungsknopf </> im Editor. Du kannst Code auch inline hervorheben, indem du ihn mit einzelnen Backticks umgibst. Zu lesbarem Code gehört auch eine gute Einrückung, die meisten Codeeditoren unterstützen auch automatische Einrückung, die du benutzen solltest.
Nach der Lösung deines Problems wäre es natürlich nett gegenüber den Helfern, wenn du Bescheid sagst dass du es gelöst hast. Den Thread einfach links liegen zu lassen während andere noch fleißig ihre Lösungsvorschläge posten ist reichlich undankbar (kommt aber leider immer wieder vor). Diejenigen, die das Problem interessant fanden, freuen sich natürlich, wenn du auch noch mitteilst, wie am Ende dann die Lösung aussieht. Diejenigen die geholfen haben freuen sich außerdem über ein Dankeschön, schließlich ist das die einzige Belohnung die sie bekommen. Im Übrigen wäre es wünschenswert, wenn du deinen ersten Post editierst und den Topic mit einem
"[gelöst]" versiehst.
Für Interessierte gibt's einen weitaus umfassenderen Artikel über richtiges Verhalten in Newsgroups und Foren wie diesem: Wie man Fragen richtig stellt.
Vielleicht trägt dieser Post ein wenig zum "kultivierten Fragen" in diesem Forum bei. Verbesserungs- und Ergänzungsvorschläge nehme ich gern entgegen und arbeite sie ein
~Edit durch Arcoth: Code-Tag fix. Außerdem Korrekturen orthographischer Flüchtigkeitsfehler.~
~Edit durch Arcoth: Wichtige Bullet-points nach oben verschoben.~
~Edit durch SeppJ: Codetags für neues Forum angepasst und einen eigenen Unterpunkt dafür gegönnt
Wie man Probleme nachstellbar und nachvollziehbar macht
Oft findet man hier im Forum Fragen von Neulingen mit Problemen beim Übersetzen ihrer Programme oder zur Laufzeit. Manche liefern dazu garkeinen Code, andere nur spärliche Brocken oder aber hunderte irrelevanter Zeilen, wieder andere posten ungetesteten Pseudocode, der haufenweise Proleme hat, nur nicht das, um welches es geht. Weder mit dem einen noch mit dem anderen Extrem ist uns und euch geholfen, daher soll hier ein kleines Tutorial folgen, wie man den relevanten Code postet - und nur den.
Wenn der Code nicht kompiliert/linkt
Es muss zwischen Compilerfehlern und Linkerfehlern unterschieden werden. Erstere haben auf allen aktuellen Compilern eine Angabe der Quelldatei und der Zeile, in der der Fehler auftritt. Letztere haben das nicht immer. Unter MSVC haben Compilerfehler einen Fehlercode Cxxxx und Linkerfehler LNKxxxx, wobei xxxx eine Ziffernkombination ist.
Grundsätzlich solltest du immer die Fehlermeldung mit angeben, allerdings auch nur eine, nicht einen ganzen Haufen. Nach einem Fehler sind andere Fehlermeldungen häufig Folgefehler, auch wenn man das nicht auf den ersten Blick sieht. Versuche auf jeden Fall, die Meldung zu verstehen, um zu wissen, was zum Fehler gehört und was nicht. Ein paar Brocken Englisch sind (bei englischen Compilern) von Nutzen. Wenn du Wörter aus den Fehlermeldungen nicht verstehst, lass sie dir übersetzen oder google nach den Fachbegriffen - oder der gesamten Fehlermeldung.
Gib von vornherein an, welchen Compiler und welche IDE du benutzt (nicht verwechseln!), außerdem ist es gut zu wissen, welche Compileroptionen du gewählt hast (wenn du einfach aus der IDE heraus baust ohne was geändert zu haben sag das explizit dazu). Beachte Warnmeldungen und poste sie ggf. auch noch. Die meisten Warnungen weisen auf mögliche Fehlerquellen hin und sollten behoben werden.
Linkerfehler
Linkerfehler sind sehr häufig fehlende Funktions- oder Variablendefinitionen. Siehe dazu den FAQ-Eintrag zu undefined references.
Das Gegenteil dazu ist der Fehler "multiple definition of..." - er erscheint meist, weil eine globale Variable oder eine freie, nicht-inline Funktion in einem Header definiert wurde.
Linkerfehler beziehen sich meistens auf ein bestimmtes Symbol, d.h. einen Funktionsnamen oder Variablennamen. Jeder Code, der diesen Namen enthält, ist hierbei relevant, d.h. aufrufende Funktionen, die Funktion/Variable selbst, die zugehörige Klasse, wenn es sich um eine Methode handelt. Beim Reduzieren des Codes (s.u.) sollten unbetiligte Funktionen und Variablen komplett entfernt werden. Wenn sich die Fehlermeldung auf eine Funktion bezieht, kann ihre Funktionalität normalerweise auf wenige Zeilen reduziert werden.
Compilerfehler
Compilerfehler betreffen normalerweise nur eine Handvoll Variabeln und Funktionen. Für das Nachstellen solcher Fehler wird nur eine .cpp und die (direkt oder indirekt) eingebundenen Header benötigt, alles weitere ist überflüssig. Tritt der Fehler in einer Funktionsdefinition auf, dann ist das die einzige Definition die man braucht, alle anderen Funktionen dürfen beim Reduzieren auf Deklarationen zusammengeschrumpft werden (beteiligte Funktionstemplates ausgeschlossen).
Ein einzelner Compilerfehler kann bei Templates viele Zeilen umfassen, wenn eine fehlerhafte Benutzung eines Templates an einer Stelle erst viele Instantiierungsstufen tiefer zu einem Fehler führt. Bei Template-Fehlern (z.B: in der Standardbilbiothek) solltest du daher immer sicherstellen, dass du die wesentlichen Teile der kompletten Fehlermeldung einsetzt, nicht nur die erste Zeile. Dazu gehören vor Allem die Zeilen, die deinen eigenen Code betreffen und der eigentliche Fehler.
Laufzeitfehler
Laufzeitfehler sind am schwierigsten zu reduzieren, weil hier oft nicht klar ist, in welcher Ecke was schief läuft. Aus dem Grund ist es wichtig, den Fehler zu lokalisieren, dazu ist es unumgänglich, sich mit der Benutzung eines Debuggers vertraut zu machen.
Wenn das Debuggen nichts hilft, können wir natürlich gerne weiterhelfen. Dazu brauchen wir neben dem Code eine möglichst genaue Beschreibung des Verhaltens, das ihr erwartet und des Verhaltens, das ihr tatsächlich bekommt.
Den Code reduzieren
Wenn du hier ins Forum kommst um eine Lösung für das Problem zu finden, heißt das, dass du schon einige Zeit suchst (bei Google, in deinem Code, im Buch deiner Wahl...). Um hier zügig eine Antwort zu bekommen investierst du am besten noch ein kleines bisschen mehr Zeit in die Kürzung und Formatierung deines Codes, und das geht so:
Sichere deinen Code und lege eine Kopie davon an. (z.B. einen neuen branch in deiner Versinskontrolle) Von jetzt an arbeitest du auf der Kopie.
Lösche großzügig die Teile raus, von denen du sicher bist, dass sie zum Problem nichts beitragen. (Funktionen, Klassen, #includes, ...)
Übersetze den Code und stell sicher, dass du genau die selben Fehler hast wie vorher, nicht mehr und nicht weniger.
Ersetze komplizierte Funktionalität Schrittweise durch was einfacheres, z.B. Funktionsaufrufe durch dummy-Werte usw. Auf die Weise reduzierst du die Abhängigkeiten deines Codes von weiteren Headern usw., die du dadurch auch rauswerfen kannst.
Übersetze nach jedem Schritt und stell sicher, dass du genau die selben Fehler hast wie vorher, nicht mehr und nicht weniger.
Verkleinere deine Klassen: entferne Membervariablen und Methoden, die den Fehler nicht beeinflussen.
Übersetze...
Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.
Wenn du in einem der Schritte neue Fehler bekommst, behebe sie oder mache den Schritt rückgängig.
Wenn du in einem der Schritte deinen Fehler nicht mehr bekommst, denk drüber nach, ob dir das einen Hinweis gibt, woher der Fehler kommen könnte. Mache den Schritt rückgängig (Versionskontrolle hilft!) und fahre mit kleineren Schritten fort, den Fehler einzukreisen.
Du kommst zu einem Punkt, in dem du den Code nicht mehr weiter reduzieren kannst. Typischerweise hast du ca. 20-60 Zeilen, verteilt auf 1-5 Dateien.
Diesen Code kopierst und postest (nicht Abtippen!) du jetzt komplett zu deiner Fragestellung (und Fehlermeldung, Compiler, -optionen...):
Lasse nichts weg, damit wir den Code einfach nur zu kopieren brauchen um den Fehler nachstellen zu können.
Highlighte deinen Code in Markup, indem Du ihn mit ``` einschließt.
Rücke deinen Code ordentlich ein (hast du ja sicherlich sowieso, oder?)
Schreibe mit Kommentaren die Namen der einzelnen Sourcen und Header vor die Codeabschnitte
Trenne den Code verschiedener Dateien sichtbar voneinander - entweder durch mehrere Leerzeilen oder indem du sie jeweils in einen eigenen ``` Block setzt.
Idealerweise postest du den so reduzierten Code direkt bei http://coliru.stacked-crooked.com oder einem anderen online-compiler und lieferst zusätzlich zu dem hier geposteten Code einen Link dorthin.
Zu viel Aufwand? Du möchtest, dass sich zig Leute hier mehr als nur einen Augenblick mit deinem Problem beschäftigen. Also solltest du auch bereit sein, dafür entsprechend viel Zeit zu investieren. Je mehr Mühe du dir gibst, desto leichter machst du es anderen, dir zu helfen, und desto wahrscheinlicher ist es, dass jemand sich auch wirklich mit deinem Problem beschäftigt.
~
Edit durch Arcoth: C++-Tag korrigiert.~
Edit durch Columbo. Die Einleitung etwas prägnanter und catchier gestaltet, damit dieser Post hoffentlich mehr Leser gewinnt.
