Woran erkenne ich Spaghetti-Code?

[gomberl]

schliesse mich sowohl RenéG als auch pfalzmarc vollstaendig an

natuerlich haben sich die anforderungen geaendert aber strukturierte programmierung mach noch immer sinn

ich nutze nur single in - single out funktionen und methoden

was ich uebertrieben halte sind struktogramme
zumindest tiefgreifende
das blaeht sich extrem auf und macht keinen sinn

die einzige ausnahme zu diesem themengebiet sind fuer mich exceptions

@volkard: was meinst du mit:

alle variablen zu funktionbeginn deklarieren wollten und noch mehr so sachen, die aus heutiger sich unfug sind

??

regards

gomberl

[volkard]

Original erstellt von pfalzmarc:
**Und soviel schlechter lesbar ist das hier nun auch nicht (wenn auch in diesem Fall ziemlich überflüssig):

double* find(double* array,size_t size,double toFind)
{
 double *rc=0;
 for(size_t i=0;i<size&&rc==0;++i)
  if(array[i]==toFind)rc=&array[i];
 return rc;
}

**

naja. erstens schlechter zu lesen.
und zweitens langsamer.

[volkard]

Original erstellt von gomberl:
@volkard: was meinst du mit:
@volkard: was meinst du mit:
alle variablen zu funktionbeginn deklarieren wollten und noch mehr so sachen, die aus heutiger sich unfug sind

variablen macht man inzwischen so lokal wie möglich. in härtefällen, wo ne variable nur über drei zeilen gebarucht wird, kann man sogar nen block erzeugen, der nur den sinn hat, die variable lokaler zu machen.
wobei das aber ein trick für dir schlimmen funktonen ist, deren größe fast scho an eine bildschirmseite herankommt.

[kartoffelsack]

ich returne auch an verschiedenen Stellen in ner Funktion, versuche kleine Funktionen zu schreiben (die mir aber manchmal außer kontrolle laufen und 20 Zeilen sind) und benutze trotzdem das Wort Spagetti-Code

Für mich ist Spagetti-Code nicht das rumgespringe sondern das nicht-rumgespringe. Also Code 2x schreiben anstatt in in ne Funktion zu packen und die aufzurufen etc ...

[gomberl]

@volkard: jetzt verstehe ich was du meinst

von 3 zeiligen bloecken hab ich noch nie was gehoert
ich muss sagen das funktionen bei mir kaum variablen haben die nicht entweder im ganzen block immer wieder gebraucht werden oder sowieso nur in einer schleife oder nem if gueltig sind

und ich habe nix gegen ne funktion die ne seite lang ist - solange sie nicht laenger wird
obwohl ich gestehen muss
in meinem letzten projekt habe ich ne 2 1/2 seiten methode
aber die macht so banale dinge wie bits verschieben das ich nicht richtig wusste was wuerdig waere in ne funktion zu kommen

[volkard]

irgendwie verändert c++ den stil.
-immer sofort raus, sobald eine funtion ihren wert berechnet hat oder ihren seiteneffekt erfüllt. einfach gleich raus. falls was aufzuräumen wäre, machen das die *sofort zuschlagenden* destruktoren.
-die sind auch daran schuld, daß man nen block um ein mal schneöö reingehacktes

ofstream out("log.txt",ios::app);
for(int i=0;i<10;++i)
  out<<a[i]<<' '<<;
out<<endl;

macht. damit die datei auch so früh wie möglich zu geht.
-tiefe vermeiden und ablauf sequenzieller machen. statt

for(..)
 if(a)
  if(b)
   bla;

lieber

for(..)
{
 if(!a) continue
 if(!b) continue
 bla;
}

entsprechendes bei vorbedingungen von funktionen. wenn die bedingung nicht zutrifft, sofort returnen (oder gar throwen).
keiner hat was gegen ne rein sequenzielle funktion, die 2 bildschirmseiten voll macht.
-<algorithm> und so benutzen, das macht die eigenen funktionen sequenzieller.
-auf inlining bzw kline call-kosten vertrauen und wirklich kleine funktionen basteln. also ein for+ein if oder ein if+ein for oder viele gleicharteige ifs hintereinander oder so und zum schluß haben alle funktionen entweder nicht mehr als 6 zeilen oder sind trivial (oder hauen sich mit Win-Api etc rum).
<edit>
-für unsere hacker: ?: vermeiden
</edit>

es ist c++, was sich mit einigen sätzen der strukturierten programmierung nicht verträgt. andere oo-sprachen brauchen eher sowas. wenn destruktoren nicht sofort zuschlagen, wie in c++ oder perl, dann beginnt sofort, die single-return-point-leuchte zu glimmen. und das wichtigste an der strukturierten programmierung war es doch, ins bewußtsein zu rufen und beständig zu furdern, lesbaren einfachen code zu bauen. in diesem sinne ist sie weiter notwendig und vorrangiges ziel. nur ein paar alte dogmen sind halt kaputtgegangen in c++.

[ Dieser Beitrag wurde am 09.05.2003 um 19:24 Uhr von volkard editiert. ]

[toosten]

Original erstellt von volkard:
**
kleine funktionen verlangen andere regeln, als die großen ungetüme von damals. falls du nochg große funktionen baust, dann sollste auch "strukturiert" programmieren. die anderen mit ihren kleinen funktionen machens schlicht möglichst lesbar.
**

ich habe einen Kollegen der braucht für eine Funktion oft mehr als eine A4 Seite in kleiner Schrift
seine Beste war 4 A4-Seiten lang ...

Mein Chef -> Nimm Dir ein Beispiel an X der schreibt guten und verstänlichen Code

[Helium]

Vielleicht kommst Du bei Deiner WM-Uhr mit solchen Mini-Funktionen aus. Wenn es aber an größere Projekte geht, wirst Du bald an eine Bildschirmseite herankommen.

Ich behaupte jetzt einfach mal Volkrad hat schon an größeren Projketen teilgenommen.

[pfalzmarc]

Flame
Das elektronische Gegenstück zum bitterbösen Leserbrief, nur viel direkter und heftiger. Werden von Leuten geschrieben, die einen Verstoß gegen das Netiquette (siehe dort) entdeckt zu haben glauben und können sehr persönlich sein.

[japro]

Original erstellt von gomberl:
**von 3 zeiligen bloecken hab ich noch nie was gehoert
**

naja typisches beispiel (denke ich):

{
int chg = a;
a = b;
b = chg;
}

ok normalierweise hat man ne swap funktion aber wenn man es in den code hineinschreiben würde würd ich es jedenfalls so machen...

[gomberl]

das ist ja mein problem

bevor ich nen block mache - schreibe ich es lieber als ne methode
und inline das ganze - hat denselben effekt ist aber lesbarer, leichter zu pflegen und macht das ganze auch noch wesentlich modularisierter