Control Flow

Wie wäre es mit UML?

Ich meinte eher ein Programm, das die Cases fuer mich aus der Funktion 
heraus erzeugt.

Armin Sch. schrieb:
> Ich meinte eher ein Programm, das die Cases fuer mich aus der Funktion
> heraus erzeugt.

> Weil man sich hierbei sehr schnell vertut was die Aststruktur angeht - vorallem, 
wenn man eine dicke State-Machine hat, die recht viel abarbeitet.

So wie ich das sehe, ist der normale Weg, dass man zuvor seine 
Statemachine entwirft und dokumentiert und erst dann implementiert.
Dafür gibt es auch Werkzeuge.

Alles was in letzter Konsequenz mit 'reverse engeneering' zu tun hat, 
ist nun mal höllisch aufwändig. Dazu kommt, dass dafür der Markt nicht 
wirklcih gross genug ist, dass ich da eine Flut an Tools erwarten würde.

Armin Sch. schrieb:
> case gruen:                    /* 1.2 */
>         if ((haustier.katze.status == TOT) &&\    /* +1.2.1 */
>         (oma.zuhause == TRUE))
>         {
>           oma.gemuet = TRAURIG;

Du wirfst Zuweisungen und Vergleiche in Deinem "Quelltext" mächtig 
durcheinander. Das kann sehr fehlerträchtig werden!

Route 66 schrieb:
> Armin Sch. schrieb:
>> case gruen:                    /* 1.2 */
>>         if ((haustier.katze.status == TOT) &&\    /* +1.2.1 */
>>         (oma.zuhause == TRUE))
>>         {
>>           oma.gemuet = TRAURIG;
>
> Du wirfst Zuweisungen und Vergleiche in Deinem "Quelltext" mächtig
> durcheinander. Das kann sehr fehlerträchtig werden!


als allgemeinen Tipp hierfür (MISRA fordert das denke ich auch - und du 
bist ja im ASIL Bereich) kann ich dir empfehlen, das einfach so zu 
schreiben:

1

  if ((TOT == haustier.katze.status)

Wenn du die Konstanten links hältst, bekommst du sofort einen Fehler im 
Fall einer ungewollten Zuweisung.

Prog Rammer schrieb:

> Wenn du die Konstanten links hältst, bekommst du sofort einen Fehler im
> Fall einer ungewollten Zuweisung.

Ich denke ganz ehrlich, dass es hier einfach besser ist, sich eine 
gewisse Sorgfalt anzugewöhnen. Denn das funktioniert dann auch beim 
Vergleich 2-er Variablen und nicht nur bei Konstanten. Die Schreibweise

1

   if( 5 == i )

ist mehr als ungewohnt. So funktioniert menschliches Denken im 
Normalfall nicht. Wir sagen nun mal nicht "Wenn es wahr ist, dass 5 
gleich der Anzahl der Milchtüten im Kühlschrank ist", sondern "Wenn die 
Anzahl der Milchtüten im Kühlschrank gleich 5 ist".
Ich gestehe zwar zu, dass da natürlich auch viel Gewohnheit dabei ist, 
aber im Regelfall ist man gut beraten nicht zu sehr zu künsteln und die 
gewohnten Denkmuster beizubehalten und die Dinge so zu formulieren, dass 
man nicht um die Ecke denken muss. Da kommt erfahrungsgemäss viel 
schneller Palawatsch raus, als wie wenn man am Anfang ganz einfach 
sorgfältig ist. Und mit ein bischen Übung ist ein Zuweisungs / 
Vergleichsfehler in C etwas, das nur gaaanz gaaaanz selten passiert. Und 
wenn, dann merkt man den sehr schnell.

Sehe ich, um ehrlich zu sein, auch so.
Aber andererseits hab ich's mir wegen MISRA (was wie gesagt auch hier 
relevant sein sollte) angewöhnen müssen und wenn man mal eine (gar nicht 
so lange) Weile seine Statements so formuliert, fällts gar nicht mehr 
auf.

Armin Sch. schrieb:

> Jetzt meine Frage: Kennt jemand zufaellig ein Programm die
> visualisierung (jeglicher Art) der Baumstruktur aller moeglichen
> Ablauefe einer Funktion realisiert?

SourceInsight kann das zu einem gewissen Level -- ich habe selber aber 
noch nicht viel damit gearbeitet. Sonst gibt es Tools wie "Understand" 
von SciTools, oder "Structure 101" vom PRQA. Aber allen ko$tenpflichtig.

Nicht direkt zum Visualisieren, aber zum (automatischen) Testen von 
Software: VectorCast.

Karl Heinz schrieb:
>Die Schreibweise
>

1

>    if( 5 == i )

2

>

> ist mehr als ungewohnt.

Gewohnheit ist Gewohnheitssache.  Und so unüblich ist die Schreibweise 
auch nicht.

Ich hab mir diese Schreibweise inzwischen angewöhnt, und damit ist sie 
denn  nicht mehr ungewohnt :-)