RTFM! oder warum dir keiner helfen will...
-
Hi.
Wenn du dir einen Gefallen tun willst, dann lies diesen Thread bitte vollstaendig, denn dann kannst du uns helfen, dir zu helfen. Danke.Du wurdest auf diesen Thread verwiesen, weil du es jemandem schwer machst, dir zu helfen.
Eigentlich ist doch alles in Ordnung, denn du willst Hilfe und wir wollen dir helfen.
Aber! Wenn alles in Ordnung waere, dann wuerdest du diesen Thread garnicht lesen.
Zumindest liest du diesen Thread gerade, denn wuerdest du ihn ignorieren, waere fuer dich schon alle Hoffnung verloren.Grundsaetzlich solltest du verstehen, dass wir dir freiwillig helfen und uns nichts dazu verpflichtet, auch nur ein Wort mit dir zu wechseln. Also sei dankbar, dass wir dir aus Hilfsbereitschaft, Langeweile oder welchem Grund auch immer helfen wollen.
Du solltest bereit sein, uns ein Stueck entgegenzukommen. Dazu gehoert, dass du zwar Hilfe bei deinen Hausaufgaben bekommst, sie aber dennoch selbst machen musst. Unter "Hausaufgaben" verstehen wir auch, dass du dein Buch/Tutorial/Kurs aufmerksam verfolgst und keine voreiligen Experimente unternimmst.
Wenn du selber Code schreibst, musst du ihn auch verstehen. Code ist kein Haufen von wahllos zusammengeschmissenen Buchstaben und Zeichen, Code ist Logik pur. Du musst genau wissen, warum du wo und welches Zeichen setzt.
Wenn du Code postest, dann bitte nur ein kleines darstellendes Programm, welches man sofort und ohne Umwege kompilieren kann. An dieser kleinen Demo soll dein Problem klar dargestellt sein. Die Demo darf keinen Code enthalten, der nicht am Problem beteiligt ist (abgesehen von allem, was zu einem kompilierbaren Programm gehoert).
Gib immer mit an:
- wie dein Wissensstand aussieht (welche Teile der Sprache kannst du und welche nicht, was verstehst du und was nicht)
- was du ueberhaupt erreichen willst
- was du schon versucht hast, um das Problem zu beheben...
- ...und was davon wie ausgegangen ist
- welche anderen Quellen du nach hilfreichen Informationen abgesucht hast...
- ...was du gefunden hast und...
- ...warum du das gefunden hast, was du gefunden hast ("ich finde nichts bei google" ist daemlich)Ich habe dir bei Weitem nicht alles genannt, was du fuer uns tun kannst.
Wenn dir wirklich etwas an deiner Hilfe gelegen ist, lies bitte hier weiter:
http://www.tty1.net/smart-questions_de.htmlNach diesem Post findest du noch weitere Posts von anderen Helfenden, die einiges genauer darstellen oder ergaenzen. Es waere nett von dir, diese auch zu lesen.
im Namen aller Helfenden danke ich dir fuer deine Zeit
[ bearbeitet von c.rackwitz am 06.02.2006 20:53: Satz umformuliert nach Optimizers Vorschlag ]
[bearbeitet von SeppJ, Link aktualisiert]
-
- Probleme genau schildern. Ein einfaches "tut nicht" ist _keine_ genaue Beschreibung.
- Bei evtl. Compilerfehlern bitte diese auch angeben.
- [cpp]-Tags verwenden.
- Wenn man einen Tipp/Anregung/Lösungsansatz bekommen hat, länger als nur ein paar Minuten drüber nachdenken und das Thema nochmal im Tutorial/Buch nachschlagen.
- _Nie_ pampig werden!
-
c.rackwitz schrieb:
Irgendjemand hat dich auf diesen Thread verwiesen, weil du es diesem Jemand schwer machst, dir zu helfen.
Klingt komisch, ich würde vorschlagen
keiner schrieb:
Du wurdest auf diesen Thread verwiesen, weil du es jemandem schwer machst, dir zu helfen.
-
vor 15 jahren oder so wollte ein freund von mir mal das programmieren lernen. und weil er es sich einfach machen wolle hat er sich ein basic mit ca 500 befehlen gekauft (amos für den amiga, falls es jemand wissen will). da muß es doch, so dachte er wohl, für jedes problem ein befehl geben, der das problem löst. anschließend saß er verzweifelt vor dem 500-seiten-handbuch und verstand nur bahnhof.
und die moral von der geschicht': von nix kommt auch nix! grundsätzlich kann jeder programmieren lernen. sobald es aber nach dem ersten "hallo welt"-programm massenweise komplett unverständliche fehlermeldungen vom c++-compiler hagelt, trennt sich die spreu vom weizen. um sich da durchzubeißen muß man es schon wirklich wollen. und es muß einem das programmieren an sich spaß machen. sonst gibt man wegen der anfänglich mickrigen ergebnisse schnell auf. mal eben den coolen ego-shooter oder das coole hacker-programm schreiben geht nicht.
-
Noch ein Tipp:
Der gepostete Code sollte exakt dem Code entsprechen, bei dem das Problem auftritt. Auf keinen Fall irgendwas abschreiben, immer Copy&Paste. Das gleiche gilt für Fehlermeldungen.
-
Aber keine _kompletten_ Listings posten, sondern nur das Codestück in dem der Fehler auftritt. Oder noch besser, den Code auf ein minimales getestetes Beispiel reduzieren in dem das Fehlverhalten auftritt. IMHO gibt es nichts nervigeres wenn ein Poster den Code vom kompletten Programm hinklatscht und sagt "funktioniert nicht".
mfg
-
Gastt schrieb:
Aber keine _kompletten_ Listings posten, sondern nur das Codestück in dem der Fehler auftritt.
im prinzip richtig, aber der fehler liegt ja oft nicht in der zeile in der der
compiler meckert und dann postet ein anfänger schon mal leicht zuwenig.
am besten wäre es den kompletten code woanders hochzuladen und dann hier nen link posten.
ey genau, man könnte doch einen "No Paste" service anbieten
-
icepacker schrieb:
am besten wäre es den kompletten code woanders hochzuladen und dann hier nen link posten.
falscher ansatz. wenn du sowas akzeptierst, bekommst du nur noch ein paket mit ungeordneten dateien und den vermerk "geht nicht, mach dass es geht".
ein fragender hat sich gefaelligst gedanken zu machen. dazu gehoert nun mal, den fehler erfolgreich einzugrenzen ("da muesste es sein" ist falsch) und uns nicht mit belanglosem code zu belaestigen. wer diese simplen reduktionsschritte nicht bereit ist zu machen, soll sich von mir aus gleich wieder vom acker machen. immerhin muss das jemand beherrschen, der selbststaendig seinen code debuggen will.
die angebotene hilfe soll schliesslich nicht nur auf das problem an sich abzielen, sondern auch einen mehrwert haben. damit meine ich etwas im sinne von "gib ihm einen fisch und er hat ein mittagessen; zeig ihm wie man fischt und er hat nahrung fuer alle zeit".
wichtige anlaufpunkte fuer selbsthilfe (man page portale, msdn, irgendeine c referenz, bestimmte dokumentationen, debugger, profiler,...) sollten genannt werden. das ist zwar sowieso oft der fall, aber ich sags lieber ausdruecklich.
"das musst du so machen" ist falsch. besser sind erklaerungen, und wenn man nur nen link auf eine seite aus "c von a bis z" auf pronix verlinkt (man muss ja nicht alles mehrmals sagen).
-
an dieser stelle ist es evtl. angebracht auch http://tggc.tg.funpic.de/index.php?cat=8&page=5
zu nennen da er damit (leider) zum grossen teil recht hat, auch wenn er es krasser ausgedrueckt hat als es hier der fall ist.
-
Wie wäre es, wenn das mal in die FAQs kommt. In alle. Oder alle Unterforen. Ganz oben. f'`8k
Gruß, TGGC (\-/ has leading)
-
Möchte an dieser Stelle kundtun,
daß ich das Forum mit einem Haufen unglaublich blöder Fragen strapaziert
und vor noch viel mehr noch viel dooferen Fragen meinerseits verschont habe 
.Letzteres aber nur, indem ich mir wirklich Mühe gebe, das Problem herauszuarbeiten, also nicht nur einen Codeschnipsel- oder Brocken hinklatsche, sondern wirklich die kleinstmögliche Umgebung herzustellen versuche, in der sich der Fehler zeigt. Das gebietet die Höflichkeit.
Dabei kommt man so oft auf den "Hirnpatsch"- Effekt, daß sich in den meisten Fällen ein Posting erübrigt, was sich auch positiv auf das Ego auswirkt. Man möchte als Redner ja auch nicht wirklich erst beim Abgang von der Bühne feststellen, daß der Hosenstall offen steht und Klopapier an den Schuhen klebt
.An die Moderatoren: Eine Top 10 der Blödsinnsfehler als stehendes Thema wäre vielleicht eine Idee. Wenn der therapeuthische Effekt ausbleibt, der humoristische könnte einem so manche Minute versüßen, in denen man in Selbstzweifeln zu versinken droht: Es gibt auf der Welt Menschen, die sind noch blöder als ich, das hat schon was Tröstliches ...
-
Mittlerweile hab ich mich im Griff mit dem auf post antworten. Etwas moechte ich aber doch loswerden...
Der erste Eindruck zaehlt
keiner liest deinen code, wenn er wie hingerotzt aussieht. wenn du deinen stil noch nicht gefunden hast, oder einfach nur einen unzumutbaren hast (das entscheiden andere fuer dich), dann bemuehe doch BITTE einen code-reformatierer. einige gute IDEs und editoren helfen dir schon beim schreiben dabei. wenn deine(r) das nicht oder nicht ausreichend kann, besorg dir ein tool dafuer.
indent: http://www.linuxcommand.org/man_pages/indent1.html
dieses solltest du auf jedem unix finden. fuer windows kannst du auch einfach cygwin installieren (bei der installation "indent" mit anwaehlen).
Mach deine Hausaufgaben
ich setze voraus, dass du dein kapitel im buch fertig gelesen hast und keine features ausprobierst, die noch nicht erklaert worden sind. wir werden dir nicht sachen erklaeren, die dein buch sowieso erklaeren wird. sollte das der fall sein, lies einfach weiter und heb dir die fragen bis zum ende des buches auf.
dein programm hat also einen fehler. fein.
ist es eine fehlermeldung vom compiler oder vom system, google danach.
keine fehlermeldung? dein code hat vorhin ja noch funktioniert, also bevor du irgendwas dran geaendert hast. hoffentlich hast du nicht zu viel geaendert, denn weniger neuer code heisst weniger moegliche fehlerstellen.
du wirst in den neuen codeteilen irgendwelche (neuen) funktionen verwendet haben. google nach diesen und lies alles durch. vielleicht faellt dir was auf.
Heute mal Selbstkorrektur
inzwischen wissen wir ja, dass dein programm nicht funktionieren will. im vorherigen abschnitt hast du gelernt, immer nur ueberschaubare aenderungen vorzunehmen und sehr oft zu testen, ob dein code noch genau das tut, was du von ihm erwartest.
bei der fehlersuche kannst du nun zuversichtlich deine neueste aenderung verdaechtigen. der code macht offensichtlich etwas anderes als du erwartest. du musst nun rausfinden, warum dein geistiges bild vom code nicht mit der realitaet uebereinstimmt.
wie gleicht man seinen kopf mit der wirlichkeit ab?
printlining (geht immer)
printlining ist verwandt mit logging. du verstreust in deinem code ueberall textausgaben auf eine konsole (oder datei oder sowas). an hand dieser ausgaben verfolgst du variablen in deinem programm und auch welche teile des codes wann (in welcher reihenfolge) ausgefuehrt werden.
im einfachsten fall waere das ein
puts("test");, das du durch den code schiebst und immer wieder das programm laufen laesst. damit findest du raus, wo genau es kracht (dass also dein test-puts nicht mehr ausgefuehrt wird).etwas mehr information bekommst du, indem du mit printf allerlei variablen ausgibst. das koennen sein: schleifenzaehlvariablen, irgendwelche strings, datenstrukturen marke eigenbau (verkettete listen z.b.)...
du verfolgst nun den programmfluss, siehst alle daten und auch den programmfluss vor dir. so bald das programm von deiner vorstellung abweicht, weisst du, wo du nachhaken musst.
nachhaken heisst in dem fall weiteres printlining bis du genau sagen kannst: die stelle ist kaputt. das kann z.b. eine funktion sein, die du benutzt, oder eine schleifenbedingung oder du verwendest falsche variablen/werte/zeiger.
der debugger (komfortabler und du musst dein programm nicht mit printlines vollmuellen)
wenn du mit einer IDE programmierst, kommt die sehr oft gleich mit einem debugger mit. in dem fall lies bitte die hilfedatei (im zweifelsfall F1 druecken und nach "debugger" suchen).
ist das nicht der fall, besorg dir GDB, den wohl bekanntesten debugger fuer C. die handhabung von GDB haben andere leute schon viel besser erklaert als ich es koennte oder wollen wuerde.
lies doch bitte einfach dies:
http://sourceware.org/gdb/onlinedocs/gdb.html
die Praesentation
wenn du bei deinen noetigen vorarbeiten auf keine loesung gestossen bist, lass dir hier helfen. du willst deine hilfe schnell und kompetent, also sollten diese tipps in deinem interesse sein.
entschuldigungen und andere einleitungen sind nicht noetig (und werden von einigen sowieso ueberlesen). stell dir die ganze prozedur so vor, als wuerdest du pizza bestellen: hallo, ich haette gern, ist in 20 minuten da.
um dir zu helfen, muessen wir ueber dein problem so viel wissen wie du.
konkret heisst das:- was hast du vor (ideen und konzepte, kein code) und warum willst du das machen
- dein original code, nichts abtippen oder aus dem kopf reproduzieren. (in [cpp] tags kleiden und auf den eindruck achten)
- genug code, um das programm kompilieren zu koennen ("das sollte so kompilieren")
- gerade so viel code, damit das problem noch besteht (alles raus, was nicht zum problem beitraegt)
- was sollte der praesentierte code eigentlich machen
- was macht er stattdessen (fehlermeldungen usw hier)
- all deine eigenbemuehungen, das problem zu loesen (was kam beim googlen raus, was kam beim debugging raus,...)
du musst dir von uns nicht alles gefallen lassen, aber wenn jemand einsilbig oder mit ner URL antwortet, sei verstaendnisvoll und versuche aus den antworten so viel zu machen wie du kannst. den link einfach mal lesen (und auch weiterklicken), eventuell mal nach der einen silbe googeln, boardsuche bemuehen, in deinem buch nachschlagen,...
-
c.rackwitz schrieb:
wenn deine(r) das nicht oder nicht ausreichend kann, besorg dir ein tool dafuer.
indent: http://www.linuxcommand.org/man_pages/indent1.html
dieses solltest du auf jedem unix finden. fuer windows kannst du auch einfach cygwin installieren (bei der installation "indent" mit anwaehlen).
Für Windows gibt es auch noch die unxutils, eine Sammlung von GNU tools für win32. Darin ist indent auch vertreten.
Ansonsten gibt es noch astyle, weniger mächtig, dafür vielleicht etwas einfacher.
