Woran erkenne ich Spaghetti-Code?



  • Original erstellt von <Nudel>:
    Moin Leutz,
    woran oder wie erkenne ich das ich Spaghetti code?

    Spaghetti-Code war ein schlagwort der dogmatischen schule des srukturierten programmierens, die *jedes* goto ablehnten, single return points forderteten, alle variablen zu funktionbeginn deklarieren wollten und noch mehr so sachen, die aus heutiger sich unfug sind.
    keiner verwendet mehr das wort, außer lehrern und anderen zurückgebliebenen, was die entwicklung des programmiergeschehens angeht.
    du erkennst, daß du spaghetti-code hast daran, daß dein lehrer/vorgesetzter deinen code nicht versteht. genau dann erwendet er das wort, so meine erfahrung.



  • du erkennst, daß du spaghetti-code hast daran, daß dein lehrer/vorgesetzter deinen code nicht versteht. genau dann erwendet er das wort, so meine erfahrung.

    wenn der lehrer nun noch in der vorzeit des programmierens lebt und meinen blitzsauberen aktuellen code nicht versteht (obwohl er semantisch sowas von eindeutig ist) dann sit das doch aber kein spaghetti coder oder?!



  • Original erstellt von Griffin:
    wenn der lehrer nun noch in der vorzeit des programmierens lebt und meinen blitzsauberen aktuellen code nicht versteht (obwohl er semantisch sowas von eindeutig ist) dann sit das doch aber kein spaghetti coder oder?!

    leider doch. denn nur die saurier verwenden das wort. also haben sie als einzig-wort-verwender doch definitionsgewalt.

    //SCHLIMMER SPAGHETTI-CODE
    //BITTE NICHT UNACHTSAM AELTEREN PROGRAMMIEREN ZEIGEN
    //WEITERLESEN AUF EIGENE GEFAHR
    /*spoiler
    *
    
    *
    
    *
    
    *
    
    *
    
    *
    
    *
    
    *
    
    *
    
    */
    double* find(double* array,size_t size,double toFind)
    {
     for(size_t i=0;i<size;++i)
      if(array[i]==toFind)
       return &array[i];
     return 0;
    }
    

    [ Dieser Beitrag wurde am 08.05.2003 um 21:31 Uhr von volkard editiert. ]



  • hmmm...ich weiß zwar nicht so recht, ob der Thread wirklich ernst gemeint ist...
    Aber unter Spaghetti-Code versteht man ein bißl was anderes. In frühen Basic-Dialekten gab es weder Sprungmarken noch Funktionen, also eigentlich gar keine Möglichkeiten zur Strukturierung. Also mußte man quasi das ganze Programm wie eine Liste schreiben, Verzweigungen konnte man nur über "goto" oder "gosub" und Zeilennummer machen, Rückgabewerte oder Parameterübergabe gab es natürlich auch nicht. Daher wurde das Hauptprogramm natürlich ellenlang. Als dann die strukturierte Programmierung entwickelt wurde, blieben viele Programmierer bei ihrem alten Stil, ohne die neuen Möglichkeiten zu nutzen. Solchen Code nannte man dann scherzhaft (oder abwertend) "Spaghetticode".



  • Original erstellt von volkard:
    [quote]
    Spaghetti-Code war ein schlagwort der dogmatischen schule des srukturierten programmierens, die *jedes* goto ablehnten, single return points forderteten, alle variablen zu funktionbeginn deklarieren wollten und noch mehr so sachen, die aus heutiger sich unfug sind.

    Mag sein, dass ich nach Deiner Definition zu den Sauriern gehöre, aber (abgesehen von den Variablendeklarationen) macht die strukturierte Programmierung auch im Zusammenspiel mit OOP durchaus Sinn.
    Single-Return-Points (in Schleifen, Funktionen und Bedingungen) machen den Quelltext übersichtlicher und damit problemloser wartbar.
    Spätestens bei der Fehleranalyse verlierst Du ohne übersichtliche Struktur kostbare Zeit.

    [ Dieser Beitrag wurde am 08.05.2003 um 22:28 Uhr von pfalzmarc editiert. ]



  • Original erstellt von pfalzmarc:
    Single-Return-Points (in Schleifen, Funktionen und Bedingungen) machen den Quelltext übersichtlicher und damit problemloser wartbar.
    Spätestens bei der Fehleranalyse verlierst Du ohne übersichtliche Struktur kostbare Zeit.

    dann mach doch mal die oben von mir angegebene funktion so, daß sie nur einen return-point hat. ond dann lach ich
    , weil sie auf alle fälle schlechter lesbar wird.
    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.

    [ Dieser Beitrag wurde am 08.05.2003 um 22:33 Uhr von volkard editiert. ]



  • 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. Größer sollte eine Funktion wirklich nicht sein - lässt sich aber der Übersicht halber nicht immer vermeiden.

    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;
    }
    


  • Und warum ist dann folgendes nach Meinung einiger unlesbar?

    double* find(double* array,size_t size,double toFind)
    {
      for( ; size; size--, array++)
        if( *array == toFind)return array;
      return NULL;
    }
    

    Vielleicht, weil es nicht viel Ähnlichkeit mehr mit einer Basic-Schleife hat?



  • pfalzmarc: Deine Version geht unnötigerweise das Datenfeld auch nach dem Finden des Elements noch weiter durch.



  • @Krösus

    Genau hinschauen 😉



  • 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



  • 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.



  • 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.



  • 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 ...



  • @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



  • 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. ]



  • 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 😉



  • 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.



  • 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.



  • 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...


Anmelden zum Antworten