Goto Punkteabzug?

Bashar

volkard schrieb:

Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:[...]
Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".

Das ist ja nichtmal "unschön", sondern ganz klar der Fehler des Lehrers, der nicht weiß, dass man Allaussagen im Allgemeinen durch Gegenbeispiele widerlegt. (Im Übrigen hätte man jetzt bei x^3=-x3 auch noch ein Gegenbeispiel angeben müssen, also ist die ganze Rechnerei für die Katz.)

Aber wie wärs, wenn wir beim Thema blieben?

illuminator

Sowas ist immer ein Problem der Auifgabenstellung. Wenn eine Lösung laut Aufgabenstellung korrekt ist gibt es volle Punkte, fertig.
Ich hab mich als Schüler über wenig Sachen mehr aufgeregt als über unklare und missverständliche Aufgabenstellungen.

Ist dann immer wie ein Überraschungsei was man für eine Note bekommt.
Wenn man dann als Lehrer willkürlich von seinen Schülern verlangt sich zu denken was der Lehrer sich denkt, was er gemeint aber nicht geschrieben hat, hört es auf.

Und so Aktionen können echt die Motivation vieler Schüler _sehr_ negativ beinflussen. Hab ich mehrfach miterlebt.

Mit meinem Informatiklehrer in der 11 bis 13 hatte ich deswegen mehrmals Probleme.

Als Lehrer sollte man solche Gelegenheiten Nutzen aus den Fehlern zu lernen und das nächste Mal klarere Aufgabenstellungen zu verfassen.

volkard

Michael E. schrieb:

Samyboy schrieb:

Nunja mein Lehrer hat das getan

Ich nehme an, dass du noch in der Schule bist. In der Schule haben unschöne Lösungen in Mathe meist die Eigenschaft, dass sie unsauber sind, d. h. nicht alle Fälle zufriedenstellend abdecken. Dann kann man durchaus was abziehen.

Dann nehme ich das auch als Anker. Wenn die Lösung nicht alle gefragten Fälle abdeckt, gibts Abzug. Allerdings muß man dazu den Code auch durchlesen und durchdenken, was mehr Arbeit ist, als auf Stil zu achten.

asc

illuminator schrieb:

Ich hab mich als Schüler über wenig Sachen mehr aufgeregt als über unklare und missverständliche Aufgabenstellungen.

Wobei mit Sicherheit im Unterricht ein ähnlicher Lösungsweg gezeigt wurde. Ich gebe dir aber Recht, das viele Aufgabenstellungen zu Wünschen übrig lassen. In einigen Fällen war bei uns der Lehrer dann aber auch so konsequent das er jede Lösung, die zum vorher gelehrten passt, akzeptiert hat [Und um auf das Beispiel einzugehen hat bei uns hat der Dozent auch erwähnt was er von goto hält, und das kenne ich auch so aus einem Schulunterricht - Und dann muss er es imho nicht mehr in eine Aufgabenstellung schreiben].

illuminator schrieb:

Und so Aktionen können echt die Motivation vieler Schüler _sehr_ negativ beinflussen. Hab ich mehrfach miterlebt.

Ich habe aber auch miterlebt wie Viele, in wirklich klar geschriebenen Sätzen, einiges hinein interpretieren, das definitiv dort nicht stand.

illuminator schrieb:

Als Lehrer sollte man solche Gelegenheiten Nutzen aus den Fehlern zu lernen und das nächste Mal klarere Aufgabenstellungen zu verfassen.

Wobei klar verständlich nicht unbedingt eindeutig ist*. Wenn man z.B. als Student darauf beharrt das eine verkettete Liste (die in der Aufgabenstellung gefordert war) in dem Aufgabenumfeld ja auch durch ein normales Array ersetzt werden kann, habe ich auch kein Verständnis damit. Und jeder Text lässt sich uminterpretieren, wenn man es nur stark genug versucht.

* das gilt aber auch im wahren Leben, und es ist auch leicht dort Probleme zu bekommen. Und am schönsten ist es wenn man eine komplexe Aufgabe bekommt (Auf deren Umsetzung andere Unternehmen etliche Mannjahre investiert haben), diese mit genau einem Satz umrissen ist "Schreibe eine Projektverwaltung im Stil von MS Projekt", und als Zeithorizont dir 2-3 Wochen gegeben werden.

Bashar schrieb:

Das folgende goto finden schließlich alle Leute gut:

Das ist ja auch keins.

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

asc schrieb:

Ich persönlich kenne kaum eine Sprache wo ein goto wirklich sinnvoll ist

Gotos lassen sich immer vermeiden, aber manchmal sind sie die einfachste und naheliegendste Lösung. Demnach sind gotos nicht grundsätzlich sinnlos oder "böse", wenn man sie mit Bedacht einsetzt.

Doch nun zum Thema: Ich würde einen Punkt abziehen, wenn jemand gotos verwendet, wo gewöhnliche Kontrollstrukturen ausreichend sind. Keinen Punkt abziehen würde ich, wenn jemand goto verwendet, um aus einer tiefen Verschachtelung rauszuspringen oder nach einem Fehler zum Cleanup/Exit-Code verzweigt (Ein Beispiel hat DEvent schon gegeben).

SeppJ

Vorausgesetzt dass es sich um die böse Art von goto handelt UND es keine karriereentscheidende Prüfung ist (was in der Schule wohl der Fall ist): Ich würde Punkte für schlechten Stil abziehen. Auf die Weise lernt der Schüler sehr effektiv, mit gutem Stil zu programmieren. Und ist sicherlich sehr viel besser für ihn, als in irgendeiner unbedeutenden Klausur ein paar Punkte mehr zu bekommen.

Und auch in einer wichtigen Prüfung hätte ich keine Skrupel, Punkte für schlampige Erfüllung der Aufgabe abzuziehen. Wenn der Prüfer die Lösung nicht mehr nachvollziehen kann, ist die Aufgabe falsch gelöst. Ein einzelnes goto reicht dafür noch nicht aus, aber ein richtiger Spagetthicode schon.

Marc++us

Naja, das Spiel kann man ja weitertreiben.

Nehmen wir an, jemand programmiert das, aber macht die Fehlerbehandlung dadurch, daß er überall mit einem Flag weitergeht um aus Schleifenverschachtelung rauszukommen.

Und einer anderer springt mit goto raus auf eine Fehlermarke.

Was ist jetzt schlechter Stil?

Marc++us schrieb:

Naja, das Spiel kann man ja weitertreiben.
Nehmen wir an, jemand programmiert das, aber macht die Fehlerbehandlung dadurch, daß er überall mit einem Flag weitergeht um aus Schleifenverschachtelung rauszukommen.
Und einer anderer springt mit goto raus auf eine Fehlermarke.
Was ist jetzt schlechter Stil?

Für mich programmiert der mit dem Flag in schlechtem Stil. Umständlicher Code, nur um ein goto zu vermeiden, ist schlechter Stil.

Bashar

Z schrieb:

Bashar schrieb:

Das folgende goto finden schließlich alle Leute gut:

Das ist ja auch keins.

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

Was heißt hier "sogar"? Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch. goto-Labels können so gut wie beliebig platziert werden. Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

rüdiger

DEvent schrieb:

void main() {
 ....

Für das void main würde ich aber Punkte abziehen.

Bashar schrieb:

Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch.

Es ist kein "goto zu fester Sprungmarke" sondern ein "goto zu mehreren Sprungmarken", ein 1-zu-n goto. Ich würde es nicht als sehr eingeschränkt bezeichnen.

Bashar schrieb:

goto-Labels können so gut wie beliebig platziert werden.

Nein. Du kannst nicht aus Funktionen hinausspringen.

Bashar schrieb:

Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

Aber switch/case entspricht in BASIC dem "ON x GOTO ...". Genauso wie break ein goto ohne explizite Sprungmarke ist. Es gibt schon einige versteckte gotos, wir nennen sie nur anders und deshalb finden wir nicht, dass sie böse sind.

Nexus

Z schrieb:

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

So kann man aber nicht argumentieren. Dann müsste man alle Schleifen und Funktionsaufrufe ebenfalls als goto zählen. Den Unterschied zwischen goto und verstecktem Sprung musst du schon sehen.

asc

Z schrieb:

Bashar schrieb:

Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch.

Es ist kein "goto zu fester Sprungmarke" sondern ein "goto zu mehreren Sprungmarken", ein 1-zu-n goto. Ich würde es nicht als sehr eingeschränkt bezeichnen.

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

volkard

Würde das behoben sein, wenn man sich darauf beschränken würde, mit goto nur abwärts zu springen und nie in blöcke reinzuspringen?

Shade Of Mine

asc schrieb:

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

bei einem goto weiss ich immer genau wo es hin springt (ich sehe das label ja direkt am bildschirm) aber wo eine exception gefangen wird, das weiss ich nicht, das kann ich garnicht wissen. ich muss annehmen dass sie korrekt gefangen wird.

dass goto schlecht ist, stammt aus einer anderen zeit. es gibt ja immer mehr goto-ersatz. zB ein break das 2 schleifen breakt und nicht nur eine, exceptions und natürlich returns (früher hatte man ja single entry/single exit). also wo ist das problem wenn man goto verwendet?

das problem ist dann nicht goto sondern spaghetti code...

Nexus schrieb:

Z schrieb:

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

So kann man aber nicht argumentieren. Dann müsste man alle Schleifen und Funktionsaufrufe ebenfalls als goto zählen. Den Unterschied zwischen goto und verstecktem Sprung musst du schon sehen.

Ja, das stimmt. Funktionsaufrufe sind gotos mit automatischem Rücksprung, Schleifen sind wiederholte gotos mit Abbruchbedingung. Insgesamt sind sie alle mit zusätzlicher Funktionalität versehene gotos, damit wir das echte goto nicht benutzen müssen.

asc schrieb:

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

Das Verhalten eines gotos ist auch eindeutig, es heisst "Springe von hier bis dort", nicht in die andere Richtung, denn dazu bräuchte man ein weiteres goto.

Shade Of Mine schrieb:

das problem ist dann nicht goto sondern spaghetti code...

Vollkommen korrekt. Und Spaghetticode bekommt man auch ohne goto hin.

Bashar

Z schrieb:

Bashar schrieb:

Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch.

Es ist kein "goto zu fester Sprungmarke" sondern ein "goto zu mehreren Sprungmarken", ein 1-zu-n goto. Ich würde es nicht als sehr eingeschränkt bezeichnen.

Manche gotos können zu try..catch gemacht werden um umgekehrt, aber es gibt für beide Situationen, wo das nicht geht. Klarer Fall von "nicht dasselbe".

Nein. Du kannst nicht aus Funktionen hinausspringen.

Deshalb schrieb ich "so gut wie".

Bashar schrieb:

Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

Aber switch/case entspricht in BASIC dem "ON x GOTO ...".

Nein, mit switch kannst du nur in case-Labels, die im switch-Statement stehen, springen, mit ON x GOTO kannst du beliebige Marken oder Zeilen anspringen.

Genauso wie break ein goto ohne explizite Sprungmarke ist. Es gibt schon einige versteckte gotos, wir nennen sie nur anders und deshalb finden wir nicht, dass sie böse sind.

Wieso müssen wir andauernd diese Diskussion wiederholen? Beim letzten Mal war das mit fricky, und mir fällt grad auf, dass du registriert bist seit er weg ist. Aber der kennt kein try..catch, also verkneife ich mir mal irgendwelche voreiligen Schlüsse.

Das Problem an goto ist, dass man damit vorwärts und rückwärts an der durch die Blockstruktur gegebenen Programmstruktur vorbeispringen kann. Das gilt für keines deiner sogenannten versteckten gotos, und das ist auch der Grund, warum diese nicht als "böse" gelten: break, continue und return haben fest vorgegebene Sprungziele, die sich durch die Blockstruktur ergeben (lexikalisch). switch springt nur ein enthaltenes case- oder default-Label an. Schleifen sind in sich schon Blockstrukturen. Exceptions springen innerhalb einer dynamisch vorgegebenen Blockstruktur nach außen.

volkard

Samyboy schrieb:

PS: Hab diesen Thread extra ins falsche Forum getan, weshalb kann man in "Rund um die Programmierung" keine Umfragen erstellen?

Paßt hier besser. Andere Sprachen haben ganz andere Verhältnisse zu goto.

Bashar schrieb:

Bashar schrieb:

Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

Aber switch/case entspricht in BASIC dem "ON x GOTO ...".

Nein, mit switch kannst du nur in case-Labels, die im switch-Statement stehen, springen, mit ON x GOTO kannst du beliebige Marken oder Zeilen anspringen.

Natürlich ist es nicht exakt dasselbe, BASIC und C++ sind verschiedene Sprachen, aber ich denke die Ähnlichkeit beider Konstrukte wirst Du auch sehen.

Bashar schrieb:

Wieso müssen wir andauernd diese Diskussion wiederholen? Beim letzten Mal war das mit fricky, und mir fällt grad auf, dass du registriert bist seit er weg ist. Aber der kennt kein try..catch, also verkneife ich mir mal irgendwelche voreiligen Schlüsse.

Ja, ich kann mir vorstellen, dass solche Diskussionen hier öfter laufen. Und nein, ich war vorher noch nie hier registriert.

Bashar schrieb:

Das Problem an goto ist, dass man damit vorwärts und rückwärts an der durch die Blockstruktur gegebenen Programmstruktur vorbeispringen kann.

Deswegen, das sagte ich schon, sollte man gotos mit Bedacht einsetzen. Übrigens kannst Du auch keine Variableninitialisierungen überspringen, ohne dass der Compiler sich beschwert