mikrocontroller.net

Forum: Offtopic OT: Gehts euch auch manchmal so?


Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Topentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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"

Autor: Willi Wacker (williwacker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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 ;)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir hatten mal in den coding guidelines den Spruch drin:

“copy, paste & die”

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Bernd T. (bastelmensch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf jeden Fall ist eine gute Doku Gold wert. Zugegebenerweise habe ich 
zwar reichlich Silber in der Schatule aber kaum Gold. ;-)

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
for ($i = 0; $i < 10; $i + 1);
{
    echo $i;
}

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Schelm (derschelm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.