goto SCL

Zuviel Werbung?
-> Hier kostenlos registrieren
In der Firmenvorschrift, die ich beachten muss, wird nur eine FOR-Schleife und IF-THEN erlaubt.

Halte ich für eine übliche Schwachsinnsvorschrift.
Ein Sortieralgorithmus wie Bubble- oder Quicksort beispielsweise würde dadurch entweder unübersichtlicher oder langsamer.

So eine Vorschrift macht vielleicht Sinn wenn in der Firma nur Leute arbeiten die nicht wissen wann man welche Anweisung einsetzt. Da wäre eine Mitarbeiterschulung zweckdienlicher als so eine Vorschrift.
 
nebenbei bemerkt versuche ich, Schleifen grundsätzlich zu meiden, wenn ich entsprechende Möglichkeiten hab, die Laufvariablen nur Zyklus für Zyklus weiterzählen zu können. Wenn ich das Ergebnis der Schleife nicht sofort im gleichen Zyklus brauche.

dass repeat-until unübersichtlich sein soll ist wohl genauso Ansichtssache, wie dass goto und exit als unschön betrachtet werden. Ich finde eigentlich an Repeat nichts unschönes.

Dass Schleifen ausschließlich in der FOR-Form erlaubt werden, ist, denke ich mal, dem Umstand geschuldet, dass diese Form niemals endlos laufen kann (jedenfalls nicht, solange man die Laufvariable in der Schleife nicht manipuliert, oder meckert da der Compiler?). Was aber auch bedeutet, dass man mit IF-THEN und GOTO ebenfalls keine Schleifen bauen sollte, deren Abbruchbedingung unter Umständen niemals eintritt.

Letztlich ist eigentlich jede bedingte Codeausführung im Bereich Automatisierung (da spreche ich jetzt von Einzelmaschinen, die Zykluszeiten von oftmals <10ms erfordern) problematisch, wenn man sich nicht gerade im Status befindet, sondern nur den Code vor Augen hat, bei dem unklar ist, ob er überhaupt wirksam ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Halte ich für eine übliche Schwachsinnsvorschrift.

Naja, die Firma, um die es geht, stellt u.a. Waschmaschinen her ..... also keine Gurkenbude.

Außerdem haben die einen Codescanner geschrieben - genial wie ich finde - der scannt den kompletten ST-Quellcode, also
das gesamte CoDeSys-Projekt auf Konformität mit dieser .....-vorschrift und der gibt nachher exakt aus, wo der Programmierer
etwas zu virtuos gehandelt hat. Man mag davon halten was man will, der Softwareeinheitlichkeit und -qualität ist das mit
Sicherheit dienlich.

Frank
 
Warum ist CASE OF nicht in die Firmenvorschriften ?
CASE OF ist genau so "sicher" wie IF THEN. CASE OF ist eigentlich nur eine saubere Variante von verschacktelte IF THEN.
 
Ich verwende FOR Schleifen nur dann, wenn mir die Anzahl der Schleifendurchläufe bekannt ist (z.b. ein Array von 100 Elementen durchsuchen). WHILE und REPEAT kommen wohl eher bei Sortieralgorithmen zum Tragen. Ich denke die meisten nehmen deswegen eine FOR-Schleifen weil sie noch am einfachsten zum debuggen ist (meiner Ansicht nach). EXIT habe ich auch schon oft gebrauchen können, aber wie steht es denn bei euch mit CONTINUE??? :D
Soweit ich weiß beendet diese Anweisung ja den aktuellen Schleifendurchlauf und der Index wird dann um eins weitergezählt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... sodenn man auf goto verzichten kann. Exit gehört, glaube ich, auch eher in die Kategorie deprecated, wenn ich da meinen Informatikunterricht noch richtig im Ohr behalten habe.
Das u.ä. haben die Unterrichtenden schon vor min. 25 Jahren erzählt.

Und trotzdem kann ich nicht nachvollziehen, warum ich mich freiwillig in meinen Möglichkeiten einschränken soll, wenn es die Programmierer der jeweiligen Hochsprache (immer noch?) anbieten und demzufolge nicht für überholt halten.

Auch wenn's nicht viele Situationen gibt, aber wenn es in einer am Besten passt - warum nicht?
 
Das u.ä. haben die Unterrichtenden schon vor min. 25 Jahren erzählt.
...
...aber wenn es in einer am Besten passt - warum nicht?
in meine Ohren ist dies schon vor 30 Jahren gedrungen.

das "warum nicht" wurde damals so beantwortet, dass der Leser (und auch der Urheber des Codes) davon ausgehen kann, dass die Schleife auch wirklich vollständig abläuft. Und wenn eben nicht ein vollständige Ablauf vonnöten ist, dann eben "UNTIL done", dann kann man sich auf die Suche im Code nach dem "done" machen.

Aber wie so oft: was schön ist und was weniger schön ist, liegt auch hier vermutlich rein im Auge des Betrachters.
 
Wenn schon GOTO dann das "COMPUTET GOTO" aus Fortran (ist wenn man es beherrscht universeller als jede CASE-Verzweigung bzw. SPL in Step7). Leider unterstützt SCL, ST, VB usw. diese Anweisung nicht.

Corrado
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn schon GOTO dann das "COMPUTET GOTO" aus Fortran (ist wenn man es beherrscht universeller als jede CASE-Verzweigung bzw. SPL in Step7). Leider unterstützt SCL, ST, VB usw. diese Anweisung nicht.

Corrado

.... eventuell gibt es auch in COBOL, FORTH, ADA, MODULA2, PL/M, Prolog, Lisp oder 8080 Assembler irgendwas schönes was STEP7 nicht unterstützt;)

Gruß

Johannes
 
Kein GOTO

Es ist klar, GOTO entspricht einer Sprunganweisung an ein direktes Ziel. Wer von der AWL kommt oder Assembler gemacht hat, kennt es erst einmal gar nicht anders.

Aber die Zeit ist nicht stehen geblieben, man hat höhere Sprachen entwickelt mit Kontrollanweisungen wie IF, ELSE, END_IF.

Diese wurden weiter entwickelt in Konstrukte wie FOR, WHILE, CASE ... bis hin zu foreach xxx in yyy.

Hinzu kam das Konzept der Blöcke und die seinerzeit geniale neue Forderung
"Eine Funktion hat nur EINEN Eingang und auch nur EINEN Ausgang".

All das dient einzig und allein dazu, die Programme übersichtlicher und damit sicherer zu machen. Der CPU ist es egal, wenn es richtig gemacht wird, woher der Sprung
kommt. Es basiert das "Kein GOTO" also auf Erfahrung, kommt meist aber daher wie ein pädagogisch erhobener Zeigefinger und wie immer fühlen sich die Anfänger stark
und müssen erst noch Lehrgeld zahlen, bis sie lernen "Shit happens".

Wenn es ein kleines Programmchen ist, überblickt es der Entwickler, wenn er mal so eben GOTO sagt, aber wenn später mal jemand anderes was ändert und gar nicht
bemerkt, dass irgendwo quer rausgesprungen wird, dann ist das Problem gewaltig.
 
Wenn es ein kleines Programmchen ist, überblickt es der Entwickler, wenn er mal so eben GOTO sagt, aber wenn später mal jemand anderes was ändert und gar nicht
bemerkt, dass irgendwo quer rausgesprungen wird, dann ist das Problem gewaltig.

Was meiner Meinung nach dann ganz klar ein schlecht dokumentiertes Programm darstellt, wenn man das GOTO nicht bemerkt, oder wenn das programm doch sauber kommentiert ist nimmt es der, der das programm nicht sehr ernst die absichtlich hinterlegten kommentare zu lesen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was meiner Meinung nach dann ganz klar ein schlecht dokumentiertes Programm darstellt, wenn man das GOTO nicht bemerkt, oder wenn das programm doch sauber kommentiert ist nimmt es der, der das programm nicht sehr ernst die absichtlich hinterlegten kommentare zu lesen.
wer dokumentiert denn extra ein GOTO? doch nur der, der sich dessen bewusst ist, dass es allgemein problematisch ist, ein solches zu verwenden.
 
... Aber die Zeit ist nicht stehen geblieben, ...
... und doch hat das GOTO (wie der Perfektionist sagt, schon über 30 Jahre) überlebt.
Das hat z.B. die Menüleiste im MS-Office nicht geschafft. (Und die vermisse ich immer noch - gut das es Zusatztools anderer Anbieter gibt.)

Ich wüßte jetzt aus dem Kopf zwar keine Situation, wo ich ein GOTO bevorzugen würde, aber ich find' es einfach nur bekloppt, wenn man freiwillig sagt: "GOTO darf unter keinen Umständen verwendet werden!", obwohl es zum Befehlsumfang gehört.

Da unterstütze ich dann doch eher solche Aussagen:
... In der Regel gibt es deutlich bessere (übersichtlichere) Lösungen als GOTO. ...
Denn es gibt nun mal gelegentlich auch Ausnahmen von der Regel.
 
GOTO gehört in die Zeit von Commodore Basic

... mit Commodore-Basic praktisch nicht umsetzbar...
:D Na ja, bei so einer "Programmiersprache" war das GOTO noch essentiell nötig, da gab's noch ganz andere "Sünden".

Ich hab z.B. mal meinen Informatik-Leher auf einem VC20 damit verblüfft, das geforderte Programm einer Klassenarbeit in eine einzige Zeile zu packen, indem ich IF-Konstrukte durch Multiplikationen mit -1*Bedingung ersetzt habe. Der Kommentar des Lehrers unter der Note 1 war der Brüller: "Ich hab zwar nicht verstanden warum, aber ich hab es eingegeben und es hat funktioniert."
Dies war aber auch so ziemlich das letzte Mal, dass ich Code geschrieben habe, den andere NICHT verstehen sollten.

Insofern ist GOTO (mit den genannten Ausnahmen von Errorhandling usw. ) ein absolutes NO GO.
 
Zurück
Oben