Servus Leute...
ist zwar Off Topic.
Aber gehts euch auch manchmal so...ihr Progt und Progt...kopiert euch
ein paar Codeschnippsel von alten Projekten zusammen...wie dtostr etc.
Und stellt dann fest es geht nicht.
Nach ner weile wo ihr schon an allem Zweifelt...Gegooglet habt wie
blöde...und drauf und dran seit hier hilfe zu suchen.
Dann den Fehler findet...weil ich beispielsweise im
Copy-Pastemodus...auf Hirnausmodus geschalten habt...und vergessen habt
die Richtigen Variablen jetzt zu setzten.
Mir gings grad wieder so...manchmal frag ich mich echt.
MfG
und frohes Schaffen...
Matthias
Matthias wrote:
> Dann den Fehler findet...weil ich beispielsweise im> Copy-Pastemodus...auf Hirnausmodus geschalten habt...und vergessen habt> die Richtigen Variablen jetzt zu setzten.
Irgendwann kommt man dann zur Erkenntnis, dass globale Variablen
mit eine Wurzel allen Übels sind. Variablen in die Funktionen
reinziehen, dort wo sie gebraucht werden. Argumente tatsächlich
über eine Argumentliste übergeben und nicht auf globale Variablen
zum Datenaustausch setzen und schon tritt dieses oder ein
ähnliches Problem nicht mehr auf.
Funktionen nach Funktionalität in *.c Files verpacken, dazu ein
Header File und man kann sich zumindest für diese Funktionaliät
von copy&paste verabschieden. *.c, *.h in das Projekt mitaufnehmen,
Funktionen aufrufen, läuft.
Defensiv programmieren. Beim Programmieren sich schon fragen
was da alles passieren kann. Nach Möglichkeiten suchen, wie einem
der Compiler beim Fehlerfinden helfen kann.
> Argumente tatsächlich über eine Argumentliste übergeben und nicht auf> globale Variablen...
Ob nun die 'Hirn-AUS-Funktion' bei den Variablen oder den
Argumentenlisten einsetzt, ist doch 'gehoppelt wie gedeckelt'.
Meine Erfahrung ist, wenn 'Hirn-AUS', dann ist die
Summe aller Errors = const.
Aber grundsätzlich kenne ich den Zustand 'Hirn-AUS' ;-))
Wenns mir dann mal auffällt, dann ruf' ich ganz laut: "Ich bin sooo
hooohhl"
Beim Programmieren vertraue ich stark auf mich selbst. Fremde Programme
von irgendwo aus dem Internet nehme ich gerne als Anregung und / oder
Vorlage. Aber ungeprüft geht sowas nicht in mein Projekt rein. Zumindest
wird es intensiv angeschaut und an die eigenen Bedürfnisse angepasst.
Merke: Der Debugger ist Dein Freund.
Ich will damit nicht sagen, dass der entsprechende Kollege sein Programm
nicht gut getestet hat, aber das ein oder andere undokumentierte Feature
kann stören. Er hat sicher nicht meinen Anwendungsfall getestet, und udn
und.
Zu Karl-Heinz-Buchegger:
Aktuell haben wir bei uns ein Programm ausgegraben, bei dem weite
Codeteile in Headern stehen - GRUSEL!
Willi Wacker wrote:
> Aktuell haben wir bei uns ein Programm ausgegraben, bei dem weite> Codeteile in Headern stehen - GRUSEL!
Ja das kenn ich auch.
Aber haben wir nicht alle unsere Leichen im Keller?
Übrigens, gerade wenn man "progt" und "progt" und weiter"progt", dann
sollte man irgendwann auch einfach mal aufhören. Ich merks nach einiger
Zeit, dass ich dann häufig Fehler mache, die ich auch direkt hätte sehen
können und einfach nur blöd sind. Und die mich zudem auch noch ne Stunde
Fehlersuche gekostet haben.
Und gerade wenns mal spät wird (so um die 1-5 Uhr nachts) sollte man
auch mal über einen Schlaf nachdenken. Beim schlafen (und aufm Klo)
kommen einem eigentlich die besten Ideen/Problemlösungen ;)
Debugger und Controller...naja. Ich nehm immer die pratiksche Lösung.
Prpggen reinstecken und testen. Hauts is gut ansonsten...etwas suche.
Ich meinte mit Copy Paste...hab aus meinem Projekt z.b. den
Funktionsaufruf für die doubletostring funktion kopiert. Blos ich hirni
hab vergessen die Variable welche in den string soll zu ändern.
[c]
dtostrf(Erg,8,0,string);
dtostrf(Wert,8,8,string);
[\c]
ersteres Kopiert und vergessen nach zweitens zu ändern. Und ich denk mir
schon entweder bin ich blöde oder der Atmel.
Derweilen ists so wies so oft ist...der der davor sitzt baut mist.
Ist mir jetzt schon etliche male passiert...aber langsam wirds..diesmal
hab ich den Fehler nach 10 minuten gefunden...letzte mal hats 2 Stunden
gedauert.
Was auch oft mein Problem ist...ich hab ne verquere Logik.
Da hat damals schon der Prof im C-Programmieren und sein Tutor passen
müssen.
Auf 100 Zeilen Quellcode.
Dafür hab ich dabei Windows zerschossen...weil irgendwo ein Überlauf im
Array drin war...*autsch*
An der FH ging sowas nicht dank Dr.Watson Antivir.
Hab mir mittlerweilen auch mehr Kommentar als zu wenig angewöhnt auch
wenn ichs bei kurzen TestHacks dabei meistens vernachlässige.
Aber nix ist Schlimmer als ne Zeiger auf Zeiger auf Zeiger schlacht in
C++. Ich hasse sowas. Bin froh das ich davon bisher verschon worden bin.
Da ärgere ich mich lieber über Bugs in C#.
@Willi: Ich verfahre ähnlich...oft sind da manchmal noch ganz schöne
Bugs drin.
> kopiert euch ein paar Codeschnippsel von alten Projekten zusammen
Niemals, nie, nicht Code "kopieren"!
Copy&Paste ist mitunter einer der Hauptverursacher von Softwarefehlern.
Ganz schlimm wird es, wenn man innerhalb eines Programms Source-Code
kopiert und im kopierten Teil dann kleine Änderungen zum Original
einbaut. Eine solche Vorgehensweise ist grundlegend falsch.
Wenn Source-Code aus anderen Projekten übernommen wird, gehört der Code
in eine Bibliothek, mit präziser Schnittstellen-Definition, dazu gehören
dann selbstverständlich auch Unit-Tests dazu.
Wann immer ein Unit-Test zu schreiben schwierig oder unmöglich ist, ist
das ein extrem deutlicher Hinweis dafür, dass an der Struktur des
(Bibliothek-)Codes etwas grundsätzlich nicht stimmt.
Noch ein Tip:
> Ist mir jetzt schon etliche male passiert...aber langsam wirds..> diesmal hab ich den Fehler nach 10 minuten gefunden...letzte mal> hats 2 Stunden gedauert.
Überdenke Deine arbeitsweise.
Wenn Du den gleichen Fehler mehrfach machst, musst die Ursache des
Fehlers beheben. Es bringt Dir nichts, wenn Du das Beheben des immer
wieder gleichen Fehlers routinierst.
Du musst die Quelle ausschalten, nicht die Symptome!
Tja, da scheiden sich die Geister. Pointer sind mitunter eigentlich das
Beste was mir an Programmierkonzept bisher untergekommen ist. Auch wenn
das Designen von Pointerstrukturen relativ aufwendig ist, bzw. man mit
einer bestimmten Denkweise daran gehen sollte ;)
C# hingen ist wirklich das grottigste, was ich bisher an "neumodischer"
Programmiersprache erlebt habe (Jaja, die ganzen alten Sachen kenne ich
natürlich nicht)
Matthias wrote:
> Ich meinte mit Copy Paste...hab aus meinem Projekt z.b. den> Funktionsaufruf für die doubletostring funktion kopiert. Blos ich hirni> hab vergessen die Variable welche in den string soll zu ändern.
Das ist wohl jedem schon passiert.
In meiner C-Zeit hab ich mit 3D Grafik angefangen.
Man glaubt gar nicht, wie oft es einem passiert, dass
man eine Berechnung für die X-Dimension aufschreibt, für die
Y-Dimension einfach kopiert, ist ja eh dasselbe, und vergisst
das x gegen ein y auszutauschen :-)
>> Hab mir mittlerweilen auch mehr Kommentar als zu wenig angewöhnt auch> wenn ichs bei kurzen TestHacks dabei meistens vernachlässige.
Bei solchen Flüchtigkeistfehler helfen Kommentare auch nicht
wirklich. Ich bin seit Jahren auf Blockkommentare aumgestiegen.
Jede einzelne Anweisung zu kommentieren bringt nicht viel (IMHO).
Was mir aber was bringt ist, vor einem Codeblock zu erläutern
was hier abgeht (und warum).
Das geht soweit, dass ich tatsächlich oft die Blockkommentare
vor dem Code schreibe und erst dann den Code einfüge.
> Aber nix ist Schlimmer als ne Zeiger auf Zeiger auf Zeiger schlacht in> C++.
Dann machst du irgendwas falsch. In C++ braucht man Zeiger sehr
viel seltener als in C. Und Zeiger auf Zeiger auf Zeiger schon
gar nicht. Sowas ist dann zumindest ein Hinweis darauf, dass
ein paar Zwischenklassen angebracht wären bzw. Funktionalität
nicht dort in der Klassenhierarchie sitzt wo sie hingehört.
Jo ich sag blos Vorlesungen. War irgendwie immer Platz 1 auf der Liste
des Profs.
Eine Martix von Zeichern, die jeweils auf eine Matrix zeigt, welche
wiederrum von einem Zeiger "gezeigt" wird...fällt das wort net ein.
Und mit den Komentaren mach ichs ähnlich. Teilweise is der Kommentar
länger als der Code :-)
Früher hiess es immer... Copy, Paste no Time to waste...
Also die besten Mittel gegen solche Deppenfehler (nicht bös gemeint -
passiert allen) sind erfahrungsgemäß:
- Pause machen (Klo, Essen, um den Block laufen, Simpsons gucken, UT
zocken, schlafen ...)
- Einem Kollegen am Code erklären was der Rechner wieder für einen Mist
fabriziert. Meist schickt man den Kollegen nach der dritten Zeile wieder
weg oder er zeigt beim Reinkommen schon drauf.
- den betroffenen Abschnitt neu schreiben:
1. Code blockweise gut kommentieren
2. Code löschen (oder zumindest anders aus dem Blickfeld verbannen)
3. Kommentare zusammenhängend lesen und so lange nachbessern bis sie
Sinn ergeben und das beschriebene Problem auch wirklich zu lösen
scheinen.
4. Code neu schreiben, nicht in den alten Code sehen, nichts
kopieren
5. Dem neu entstandenen Problem auf den Grund gehen...
- Variablennamen verlängern und dann den Code nochmal durchlesen
- Alle X, Y und Z spaltenweise durchzählen und damit zyklische
Ersetzungen überprüfen - da ist immer eines falsch! (ja, meine 3D-Ära
hält sich hartnäckig)
- Bessere IDE zulegen. Seit ich mit Eclipse arbeite zeigen viele
Projekte schon beim Laden ihr grauenhaftes Gesicht - und nicht erst beim
Sezieren.
Je länger man an einem Fehler sitzt, desto kürzer sitzt man beim
nächsten Mal dran.
Ich verbringe immer noch regelmäßig Stunden bis Tage an einzelnen
Leerzeichen, Semikolons, etc. - Wartung von Altcode ist echt eine
Strafe!
Einer der miesesten Fehler, der mir untergekommen ist: Ein Kollege hat
mich wegen einem scheinbar willkürlichen Parser-Fehler (PHP) gerufen,
der in einer leeren Zeile aufgetreten ist (er saß bereits den halben Tag
an dem Problem). Als ich ihm nach 5 Minuten rumklickern mal gebeten habe
die Datei im Hex-Editor zu öffnen hat er das 0xFF in der Mitte gesehen
:)
In diesem Sinne
Kai Giebeler wrote:
> Ich verbringe immer noch regelmäßig Stunden bis Tage an einzelnen> Leerzeichen, Semikolons, etc. - Wartung von Altcode ist echt eine> Strafe!
Habt ihr auch die Erfahrung gemacht:
Der Code der am miesesten formatiert und am unleserlichsten
ist, ist der Code mit den meisten Fehlern. Gefolgt von blödsinnigen
Fehlern, weil sich der Programmierer selbst ausgetrickst hat
und im Dickicht der globalen Flags nicht mehr durchblickt.
Leider hab ich auch die Erfahrung gemacht, dass ein derart
mieser Code sehr oft aus universitärem Umfeld (und da leider
oft aus der Unix-Ecke) kommt. Bei so manchem Code aus einer
Diplomarbeit hab ich mich schon gefragt, ob der Blindenhund
des betreuenden Assistenten nicht ebenfalls blind ist.
Hallo,
eigendlich ist es schon fast normal, dass die Programmierarbeiten von
Studenten nicht so toll aussehen. Das liegt wohl oft daran, dass viele
gar nicht daran gedacht haben einmal programmieren zu müssen und dann
waren sie eben froh wenigstens etwas zusammengestümpert zu haben.
Ähnlich fehlerträchtig sieht der Code auch aus, wenn er von den "Freaks"
stammt, die schnell mal was ausprobieren wollen, also möglichst ohne
Vorkenntnisse und ohne großes Interesse für Details einfach unüberlegt
loslegen. Es geht dann oft darum auch dazu zu gehören und was "tolles"
gemacht zu haben, wo nach sie bewundert werden.
Die wirklichen Profis, die alles planen und durchdenken, sind eher
selten und fallen deshalb nicht auf, weil alles glatt läuft.
>Ja das kenn ich auch.>Aber haben wir nicht alle unsere Leichen im Keller?
Solange man aus seinen Fehlern lernt, kann man auch damit leben. Es ist
dann ja nicht allzu lange.
Hackt mal net so auf den Studenten rum.
Woher sollten die auch Programmieren lernen. Die Profs hab ich die
Erfahrung gemacht können meist nur ihren Standardstiefel. Wenns mal
weiterliegende Sachen gibt siehsts oft düster aus.
Die andere Sache ist auch, das viele..naja sagma mal so nicht zum
Programmieren gemacht sind. Zu meiner Zeit war Programmieren das Hass
Fach Nummer 1. Und ist noch net mal so lange her.
Da wars aber auch wurscht obs C oder C# oder sonsta was war. Viele
blicken einfach nicht so durch. Sie hatten ihren Text und verstanden nur
Bahnhof.
Wie setzt man sowas jetzt um???
Fragezeichenkreisen
Dann wurd sich vom Progger Guru aus der Gruppe der Quellcode kopiert,
die Hilfe und dann rumgestöpselt.
Die andere Sache ist, Richtig Programmieren lernt man meist erst
wirklich in der Firma und über Jahre. Dort ist meist ein Standard
festgelegt, wie etwas zu Proggen ist damits auch später wer lesen kann.
Sowas fehlt einfach im Studium.
Eine andere Seite ist, dort proggt man sein kleines Programm, vll mit
100-500 Zeilen Code um vll PI auf 1000 Stellen auszugeben.
In einem großen Programm ist man dann schnell verloren.
Oberbeschiss ist wenn wären der Entwicklung eines Programms erst A
gewünscht ist, aber dann Kunde auf B will und kurz vor Abgabe noch auf
C...da geht mir immer die Hutschnur hoch.
Im letzten Betrieb ging mir dann die Hutschnur hoch und hab der Dame
verklickert, dass die 2 Dialoge mit jeweils 2 Buttons und ein paar Grids
(natürlich noch einige Tabellen in die Datenbank die dann noch durch
andere Dialoge gefüllt etc. werden müssen)für einen Programmierer an die
2-3 Wochen rangehn...ohne Pause und Schlaf...
@Kai:
Nicht in den Code sehen. Wennst ne ordentliche IDE hast, kannst ja schon
nach den ersten Buchstaben ne Funktion etc. auswählen. Aber bei C auf
MC`s hab ich noch keine solche IDE gesehen. Und viele Befehle sind
einfach noch net in Fleisch und Blut übergegangen.
Bor Matthias, dein Text ist aber sehr holprig ;)
Und entgegen deiner Meinung würde ich behaupten, dass sauberer Code
nicht unbedingt durch's Arbeiten kommt. Aber durch Erfahrung und lange
Zeit würde ich sagen, tut man es schon.
