mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik uCs sauber programmieren in C


Autor: C-Master (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

bis jetzt hab ich sehr einfach Software einfach so vor mich hin 
programmiert (ohne vorher gross zu überlegen oder pläne zu zeichnen). 
Aber wie geht man vor wenn die Software etwas komplizierter wird? Gibt 
ja schnell sehr viele Fehlerquellen.

Habt ihr ein paar Tipps?

Gibt es irgendwelche Grundlegende sachen dir man beachten sollte? Viel 
if else benutzen oder wenig. Viel ineinander verschachteln oder 
möglichst wenig. Viele verschachtelungen sollte man maximal benützen?

Wann benutzt man State Machines?

Wie dokumentiert ihr Software? Immer, garnie oder im nachhinein? 
Zeichnet ihr Struktorgramme oder einfach Kommentare?

Wann verwendet man C++ bei uCs?

Und zum Schluss, habt ihr noch eine Buchempfehlung für C speziell für 
uCs?


Danke und schönen Abend

C-Master

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die wichtigsten Dinge:

- Main Loop immer schön klein halten
Hier so wenig Funktionalität wie möglich unterbringen und diese hinter 
klingenden Funktionsaufrufen verbergen.

- Selbsterklärende Namen für Variablen und Funktionen wählen, ganz egal 
wie lang diese werden.

- So wenig globale Variablen wie möglich, dies sollte die absolute 
Ausnahme sein!

- Selbsterklärenden Code schreiben
Viele hier versuchen immer noch das kleinste Quäntchen an Performance 
herauszukitzeln. Dies geht oft zu Lasten der Lesbarkeit, Wartbarkeit und 
Portierbarkeit und ist (fast) nie nötig.

- Zustandsautomaten sind ein sehr gutes Stichwort
Diese Dinger sind ein Garant für guten Code, weil man von Anfang an 
gezwungen wird alles nach Lehrbuch zu machen.
Hier erstellt man zuerst das Konzept, und dann erst den Code. Das 
Konzept ist gleichzeitig die beste Doku.
Bei der Implementierung gibt es keine Fehler, da das vorher erstellte 
Zustandsdiagramm eindeutig ist. War das Konzept richtig, dann 
funktioniert das Programm auch.
Grundsätzlich sollte man sich bei jeder Aufgabe fragen, ob diese sich 
sinnvoll mit einem Automaten lösen lässt.

Autor: Uboot- Stocki (uboot-stocki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas wrote:
> - So wenig globale Variablen wie möglich, dies sollte die absolute
> Ausnahme sein!
>
Wie macht Ihr es dann, wenn Ihr Zustände o.ä. in mehreren Funktionenen 
benötigt?

Ein Beispiel: Meine Rolladensteuerung - Ich benötige Uhrzeit, 
Schaltzeiten etc. in vielen Funktionen. Daher habe ich diese als globale 
Variablen implementiert. Die Alternative wäre, alle diese Werte als 
Variablen in Funktionsaufrufen zu übergeben. Dies würde m.E. aber zu 
großen Overhead bei Funktionsaufrufen führen ...

Was macht man hier? Ist es Zielführend alle mehrfach benötigten 
Variablen in ein globes Struct zu packen? Damit hätte man dann nur eine 
globale Variable ?

Also wie macht Ihrs ?

Gruß

Andreas

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle nötigen Zustandsvariablen in einer Struktur zusammenfassen und dann 
einen Pointer auf diese Struktur den einzelnen Funktionen übergeben 
(=Handle auf den Kontext).

Autor: Tomasio (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso eigentlich keine globalen Variablen? Gibts da einen vernünftigen 
Grund?

Autor: irgendjemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Globale Namensbereich ist begrenzt. Häufig hat man ja auch "status" 
Variablen, die dann mehrfach vorkommen, dann gibt es Kollisionen, also 
einfach in ne struct und die struct nach dem Modul benennen.

Auch sehr hilfreich, die sache mit dem Kontextpointer, dann kann man den 
selben Code auch mehrfach benutzen (z.B. Filteranwndungen, ...).

Meines Erachtens geht Leistung nicht gegen Lesbarkeit. Ich habe erst 
letzten Monat ein in C geschriebenes Modul (sehr gut lesbar, 100% 
portierbar), in ASM umgesetzt und nur etwa 40% eingespart. Das meisste 
natürlich beim Push/Pop (Interrupts).

Interrupts sind eh ein gutes Stichwort: ich habe gute Erfahrung gemacht, 
dieses moeglichst klein zu halten, also wenig Funktionalität dort 
reinzubringen. Wenn man dann noch ausschließlich Inline Funktionen dort 
verwendet, kommen auch brauchbar schnelle und kleine Binärdaten aus dem 
Compiler raus.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso eigentlich keine globalen Variablen? Gibts da einen vernünftigen
> Grund?

Der Hauptgrund ist der, dass bei globalen Variablen schwer
nachvollziehbar ist, woher sie ihre Inhalte stammen. Um das
herauszufinden, muss man den Quellcode des gesamten Programms nach
Funktionen durchscannen, die die eine bestimmte Variable beschreiben,
anschließend nachschauen, welche anderen Funktionen diese Funktionen
aufrufen usw. Problematisch wird es vor allem dann, wenn globale
Variablen an sehr vielen Stellen im Programm beschrieben werden.

Bei lokalen Variablen muss hingegen nur eine Funktion durchgelesen
werden. Selbst wenn Werte als Argumente an eine Funktion übergeben
werden, ist die Suche nach ihrem Ursprung immer noch mit begrenztem
Aufwand möglich.

Es ist aber überhaupt kein Problem, Uboot-Stockis Uhrzeitvariable
global zu machen, wenn aus Namensgebung und Dokumentation klar wird,
dass sie nur an einer Stelle, nämlich vielleicht in einem zyklisch
aufgerufenen Interrupthandler beschrieben wird. Würde man diese als
Argument über mehrere Aufrufebenen durchreichen, würde die Lesbarkeit
sogar schlechter, weil dabei nicht sofort klar wird, dass es sich bei
den Argumenten in Wirklichkeit immer um Kopien der gleichen Variable
handelt.

Es ist ebenfalls überhaupt kein Problem, eine Satz Parameter global zu
machen, wenn klar ist, dass diese einmal beim Programmstart
initialisiert (bspw. aus einem EEPROM gelesen) werden, und danach kaum
noch verändert werden. Idealerweise packt man all diese Variablen in
eine Struktur, um damit auszudrücken, dass ihre Inhalte alle aus der
gleichen Quelle stammen.

Bei der Übergabe von Werten zwischen Interrupthandlern und anderen
Programmteilen führt sowieso kein sinnvoller Weg an globalen Variablen
vorbei. Aber auch hier kann man die Lesbarkeit verbessern, wenn man
jeweils alle globalen Variablen eines Interrupthandlers zu einer
Struktur (bspw. timer_irqvars, uart_irqvars usw.) zusammenfasst.

Globale Variablen sind also nicht böse, genauso wenig wie Gotos. Man
muss sie nur mit Bedacht einsetzen.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:

> Globale Variablen sind also nicht böse, genauso wenig wie Gotos. Man
> muss sie nur mit Bedacht einsetzen.

Hi yalu,
bei dem meisten was du von dir lässt nicke ich oft und gerne, wie auch 
hier bei den globalen Variablen, aber bei gotos muss ich dir 
widersprechen.
Gotos führen zu Sphagetti Code und es gibt immer eine Möglichkeit diese 
zu vermeiden.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich ähnlich, gotos habe ich in den letzten 15 Jahren Programmierung 
nicht mehr gebraucht. Ich glaub auch nicht, dass mein Programmcode 
dadurch vorteilhafter geworden wäre.

Bin aber auch ein Gegner vom blinden Befolgen irgendwelcher Regeln. Wenn 
jemand den sinnvollen Einsatz von Gotos findet, darf er die gerne 
einsetzen.

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Verteufelung von goto in C ist wahrscheinlich so alt wie die 
Sprachdefintion. Sicher, man kann gotos immer irgendwie vermeiden und es 
gibt einige übergreifende oder in-house Richtlinien, die die Verwendung 
von goto auch verbieten. Aber vor allem in Funktionen mit vielen 
Verschachtelungen, bei denen z.B. sehr viele mögliche Fehlerzustände 
abgefragt werden, vermeiden machmal "mit Bedacht" eingesetzte label und 
ein paar gotos ausufernde und unübersichtliche if-else Konstrukte und 
manchmal auch die meiner Meinung nach viel fehleranfälligeren innerhalb 
einer Funktion verstreuten return fehlercodeX (mehr als ein return in 
einer Funktion wird in zumindest in zwei mir bekannten Richtlinien 
ebenfalls untersagt). Das ist dann im Prinzip ein realtiv 
übersichtliches, im Vergleich zu C++ allerdings recht primitives, 
exception-handling.

Nur meine 0,02EUR dazu; Diskussionen zu goto in C füllen wahrscheinlich 
inzwischen zehntausende von Foren-, Mailinglist-Threads und 
Internetseiten.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
goto ist so eine Sache. Ich kannte dies anfangs garnicht, (was 
vielleicht auch gut so war), aber mittlerweile nutze ich es ab und zu. 
Es gibt ein paar Fälle in denen es durchaus brauchbar ist:
z.B. wenn man mehrere Schleifen auf einmal verlassen möchte. OK, man 
kann es auch anderst machen indem man eine Variable setzt, die dann in 
allen Schleifen nacheinander ein break auslöst, oder gleich ein return 
um die komplette Funktion zu verlassen. Manchmal hat goto aber ein paar 
kleine Vorteile.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ging es ähnlich, ich kannte goto noch aus basic, war mir aber lange 
nicht bewusst das ich damit auch in c arbeiten kann, heute bin ich froh 
das ich es nicht von anfang an kannte. Was ich häufiger sehe ist das 
gotos meistens schlechten Code unterstützen, weil man sich vorher keine 
Gedanken gemacht hat.

Ein Beispiel was mir spontan einfällt ist das Rausspringen aus 
irgendwelchen Such-Schleifen, bei einfachen Konstruktionen tut es ein 
break, bei verschachtelten Angelegenheiten packt man das Ganze einfach 
in eine Unterfunktion. Wenn man von vornerein gotos gedanklich 
ausblendet wird der Code meistens strukturierter. Im Idealfall hat man 
also dann eine Suchfunktion die als Rückgabewert einen Pointer auf die 
Gesuchte Stelle oder NULL enthält. Oder wenn nur das Enthalten eines 
Wertes in einem Feld interessiert, ist ein if (beinhaltet(Feld, x)) {}; 
auch besser lesbar als irgendwelche Sprünge.

Das schlimmste Negativ Beispiel was ich bisher gesehen hab war ein Code 
mit etwa 800 Zeilen und alles in der main, dafür aber massig gotos...
(Funktionen aus Standardheadern mal ausgenommen.)

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

Bewertung
0 lesenswert
nicht lesenswert
Erinnert mich an den alten Spruch: “Real Programmers can write
FORTRAN programs in any language.”

Sprich: man kann alles, was es gibt, immer gehörig missbrauchen (und
C setzt dem Missbrauch wenig Schranken).  Sinnvoll benutzt, ist aber
oft nichts dagegen einzuwenden.

Gerade bei sehr kleinen Controllern können globale Variablen u. U.
zu einfacherem (und kleinerem) Code führen, und eine fehlende
Übersichtlichkeit ist dort nicht das Problem, was es bei einem
Projekt auf einem Controller mit 64 und mehr KiB an Code sein kann.
Gleichermaßen bringt ein "goto", das fünf Klammerungsebenen einspart,
ggf. mehr Übersichtlichkeit in das Projekt, als man bei strikter
Meidung dieses Worts erreichen kann.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erinnert mich an einen gewissen Finnen:
http://kerneltrap.org/node/553/2131

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was die Globalen Variablen angeht, bastel ich auch bei Kleinstprojekten 
jeden Funktionsblock (Hauptprogramm, Timer, UART, etc.) in jeweils 
eigene C Files und binde sie bei Bedarf in andere Programme wieder ein, 
damit erledigen sich die meisten globalen Variablen von selbst.

Autor: panam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für was brauchts eigentlich Pointer?? Das hab ich nie gecheckt. Man kann 
doch gleich die Variable übergeben! Bei Java wurde das doch auch 
abgeschafft.

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

Bewertung
0 lesenswert
nicht lesenswert
panam wrote:
> Für was brauchts eigentlich Pointer?? Das hab ich nie gecheckt. Man kann
> doch gleich die Variable übergeben!

Das ist dann aber eine Einbahnstrasse in C.
Der Wert geht zwar in die Funktion hinein, aber eine Veränderung
des Wertes in einer Funktion führt nicht zu einer Veränderung
der aufrufenden Variablen des Aufrufers.
Wenn du das so willst: super, genau das was du brauchst. Du kannst
   nach Herzenslust innerhalb der Funktion mit dem Argument
   fuhrwerken, ohne das du dem Aufrufer etwas zerstörst.
Wenn du aber haben willst, dass eine Änderung an einem Argument
   auch für den Aufrufer sichtbar ist, dann geht das in c nur,
   in dem der Aufrufer die Adresse übergibt (aka. einen Pointer)
   an der diese Änderung gemacht werden soll.

Die andere Spielwiese für Pointer sind: dynamische Datenstrukturen.
Also Arrays, Listen, Maps, Strings die zur Laufzeit bei Bedarf
anwachsen und kleiner werden können.

Pointer sind ganz einfach: Das sind Variablen, der Inhalt eine
Speicheradresse ist. So wie ein int eine ganze Zahl aufnimmt,
ein double eine Fliesskommazahl, so nimmt eine Pointer-Variable
eine Speicheradresse auf. Mehr steckt da nicht dahinter :-)

> Bei Java wurde das doch auch
> abgeschafft.

Auch in Java gibt es noch Pointer. Nur heissen sie dort AFAIK
Referenzen.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
panam wrote:
> Für was brauchts eigentlich Pointer?? Das hab ich nie gecheckt. Man kann
> doch gleich die Variable übergeben! Bei Java wurde das doch auch
> abgeschafft.

Jein, in Java und C++ gibts Referenzen, das ist praktisch ein stark 
vereinfachter Pointer.

Wenn man einen Pointer übergibt, bleiben Änderungen an der Variablen 
erhalten da direkt der Inhalt der Speicheradresse der Variablen geändert 
wird.
Bei Variablenübergabe wird mit einer Kopie innerhalb der Funktion 
gearbeitet und nach dem rausspringen aus dieser Funktion ist diese weg.
Ausserdem kostet das Anlegen dieser Kopie Speicher und Zeit.

EDIT: Immer wieder erstaunlich wie schnell Mr. Buchegger solche 
Erklärungen aus dem Ärmel zaubert.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das war der Original-Beitrag (nur noch mal zur Erinnerung):
------------>>
Hallo zusammen,

bis jetzt hab ich sehr einfach Software einfach so vor mich hin
programmiert (ohne vorher gross zu überlegen oder pläne zu zeichnen).
Aber wie geht man vor wenn die Software etwas komplizierter wird? Gibt
ja schnell sehr viele Fehlerquellen.

Habt ihr ein paar Tipps?

Gibt es irgendwelche Grundlegende sachen dir man beachten sollte? Viel
if else benutzen oder wenig. Viel ineinander verschachteln oder
möglichst wenig. Viele verschachtelungen sollte man maximal benützen?

Wann benutzt man State Machines?

Wie dokumentiert ihr Software? Immer, garnie oder im nachhinein?
Zeichnet ihr Struktorgramme oder einfach Kommentare?

Wann verwendet man C++ bei uCs?

Und zum Schluss, habt ihr noch eine Buchempfehlung für C speziell für
uCs?


Danke und schönen Abend

C-Master
<<------------ Ende des Beitrag

Eines sollte man beachten:
Das Programmieren ist kein Selbstzweck!
Ein Programm setzt eine definierte Aufgabe in Software um(, weil es so 
am einfachsten geht).

Das Ganze sieht dann sinngemäß folgendermaßen aus:
1. Es zeichnet sich eine Aufgabe ab, die zu lösen ist.
2. Die Aufgabe wird ausreichend durchdacht und dabei dokumentiert.
3. Der Benutzer des Ganzen versteht das Ergebnis von 2. und segnet es 
ab.
4. Die Lösung der Aufgabe wird aus Benutzersicht beschrieben und vom 
Benutzer abgesegnet.
5. Die Hardware für die Lösung wird konzipiert.
6. Das Design der Software erfolgt:
6.1 Grobdesign,
6.2 Feindesign bis herunter zum Pseudocode.
7. Die Hardware wird hergestellt.
8. Erst jetzt wird die Software programmiert, und zwar in den Pseudocode 
hinein.
9. Der Software-Produzent testet (White Box Test).
10. Der Benutzer nimmt das System ab (einschließlich Black Box Test).

Die Dauer der einzelnen Schritte kann hierbei von Minuten bis hin zu 
Jahren betragen. Das Ergebnis des Ganzen ist jedenfalls ein 
durchdachtes, sauber dokumentiertes, wartbares und (meist) 
funktionsfähiges System.
Der Anteil der eigentlichen Codierung am gesamten Zeitaufwand liegt 
erfahrungsgemäß bei weniger als 20%.

Zum Schluß noch eins: Wenn ein Programm kompliziert ist, dann stimmt 
etwas mit dem Programm nicht!

Grüße
Bernhard

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, nochmal zu ein paar Ausgangsfragen zurück:

>Wie dokumentiert ihr Software? Immer, garnie oder im nachhinein?
Eigentlich nur durch selbsterklärende Funktions/Variablennamen und an 
komplizierteren Stellen vereinzelte Kommentare im Quelltext.

>Zeichnet ihr Struktorgramme oder einfach Kommentare?
Nur wenns nach 3 Versuchen im Kopf nicht hinhaut, dann aber lieber 
Flussdiagramme, Struktogramme mag ich irgendwie nicht.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte entschuldigt, wenn ich das Topic wieder ein wenig verlasse. Habe
den folgenden Text vor etwa zwei Stunden geschriebeni, als der Inhalt
noch aktueller war, bin aber noch nicht dazu gekommen, ihn
abzuschicken:

Tim T. schrieb:
> aber bei gotos muss ich dir widersprechen.

Das sollte natürlich auch überhaupt kein Aufruf zur Verwendung von
Gotos sein, sondern eher einer gegen pauschale Verteufelungen im
Allgemeinen.

Martin Thomas schrieb:
> Aber vor allem in Funktionen mit vielen Verschachtelungen, bei denen
> z.B. sehr viele mögliche Fehlerzustände  abgefragt werden, vermeiden
> machmal "mit Bedacht" eingesetzte label und  ein paar gotos
> ausufernde und unübersichtliche if-else Konstrukte

Genau das ist der Fall, und wahrscheinlich der einzige, wo Gotos
sinnvoll sein können. Beispiel:
void function(void) {
    // Aktion 1
    if(Fehler1) goto error;

    // Aktion 2
    if(Fehler2) goto error;

    // Aktion 3
    if(Fehler3) goto error;

    // Aktion 4
    if(Fehler4) goto error;

    // Aktion 5
    if(Fehler5) goto error;

    goto end;

error:
    // Fehlerbehandlung

end:
    // abschließende Aktionen, die in jedem Fall ausgeführt werden
    // müssen
}

Hier wird sofort klar, dass nacheinander die Aktionen 1 bis 5
ausgeführt werden und im Fehlerfall in die gemeinsame
Fehlerbehhandlung verzweigt wird.

Dieselbe Funktion ohne Gotos:
void function(void) {
    int ok = 0;

    // Aktion 1
    if(!Fehler1) {
        // Aktion 2
        if(!Fehler2) {
            // Aktion 3
            if(!Fehler3) {
                // Aktion 4
                if(!Fehler4) {
                    // Aktion 5
                    if(!Fehler5) {
                        ok = 1;
                    }
                }
            }
        }
    }

    if(!ok) {
        // Fehlerbehandlung
    }

    // abschließende Aktionen, die in jedem Fall ausgeführt werden
    // müssen
}

Hier ist es nicht sofort offensichtlich, was beim Auftreten eines
Fehlers passiert. Um das zu erkennen, muss man sich mühsam die
If-Treppe am anderen Ende wieder hochhangeln (man stelle sich zudem
vor, die einzelnen Aktionen bestehen aus jeweils mehreren
Anweisungen, so dass der Code insgesamt länger wird).

Außerdem benötigt man eine izusätzliche Variable, um die
Erfolgsinformation aus der innersten If-Anweisung nach außen zu
tragen.

Ganz abgesehen davon wird der Code unnötig "breit", vor allem, wenn
man nicht nur 5 sondern vielleicht 20 Fehlerfälle zu untersuchen hat.

Ein Switch-Case in C ist auch nicht viel anderes als ein Mehrfach-
Goto, bei dem an Stelle der Labels abzuprüfende Werte stehen. Würde
man den Switch deswegen durch eine verschachtelte und mehrfach
eingerückte If-Anweisung ersetzen?

> Das ist dann im Prinzip ein realtiv übersichtliches, im Vergleich zu
> C++ allerdings recht primitives, exception-handling.

Genau richtig. Die C++-Exceptions sind für die Fehlerbehandlung wie im
obigen Beispiel gemacht. Damit kann man in C++ nicht nur Gotos,
sondern auch Longjumps auf saubere Art und Weise ersetzen.

Jetzt aber wieder zurück zur Ausgangsfrage ;-)

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry aber dafür würde ich:
uint8_t FehlerInFunktion(void){
    // Aktion 1
    if(Fehler1) return 1;

    // Aktion 2
    if(Fehler2) return 1;

    // Aktion 3
    if(Fehler3) return 1;

    // Aktion 4
    if(Fehler4) return 1;

    // Aktion 5
    if(Fehler5) return 1;

return 0;
}

void function(void){
 if (FehlerInFunktion()){
  // Fehlerbehandlung
 };
 // abschließende Aktionen, die in jedem Fall ausgeführt werden
 // müssen
}
verwenden.

Aber ich will keine Endlosdiskussion starten, jeder wie er mag... und 
nun B2T

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was aber, wenn du für die Fehlerbehandlung ganz viele Variablen aus
den Aktionen 1 bis 5 brauchst? Die darin enthaltenen Werte müsstest du
irgendwie aus FehlerInFunktion() heraus- und in function()
hineinbekommen. Vielleicht ein Fall für globale Variablen? ;-)

Man müsste jetzt ein konkretes Anwendungsbeispiel parat haben. Ich
habe jetzt gerade keins hier, da der Fall zugegebenermaßen nicht allzu
oft auftaucht.

Aber ich denke, wenn jemand tatsächlich auf so einen Fall stößt, der
ohne Gotos nur ungeschickt gelöst werden kann, wird er es nach dem
bisher Geschriebenen wahrscheinlich selbst merken. Wie gesagt, es geht
mir ja nicht darum, dass jetzt jeder seinen bereits funktionsfähigen
Code mit Gotos spickt. Von Gotos ist nach wie vor abzuraten, nur
generell vertaufeln sollte man es nicht.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich breche alle Konzepte auf saubere State-Maschines runter.

DIese sind (zuerst) unabhängig voneinander und könnn sich nur durch 
funktion(saufrufe) beeinflussen...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.