RTFM! oder warum dir keiner helfen will...
-
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.
