Goto Punkteabzug?
-
Wenn vorher gesagt wurde, dass man es vermeiden sollte, dann würde ich nur Punkte abziehen, wenn mich jemand veräppeln will. Man kann ja die abstrusesten Gebilde bauen, die im Endeffekt das richtige Ergebnis liefern.
-
Samyboy schrieb:
Du bist ein Lehrer und korrigierst gerade eine Klausur, die deine Klasse geschrieben hat. Du hast zwar angedeutet, dass Gotos böse sind, jedoch hast du deiner Klasse nie explizit gesagt, dass Du bei einer Prüfung dafür Punkte abziehen würdest.
Was hängt denn von der Klausur ab? Prüfungen gibts in der Schule erst am Ende, da wäre ich vorab sehr explizit, aber die paar Tests in der Mitte sind ja in erster Linie für Feedback gedacht, also tut es dort keinem weh, wenn man einen Punkt abzieht.
Nun stösst Du auf ein Programm, dass das böse Goto verwendet, jedoch funktioniert dieses einwandfrei.
Nun stößt du auf ...
* unverständliche Bezeichner
* falsche/fehlende Einrückung
* massenweise globale Variablen
* oder massenweise public-Daten
* Type-Switches statt Polymorphie
* wilde Rumcasterei
* Ausnutzen von compilerspezifischen Eigenheiten
* ...
Schlechter Stil gibt Abzug. Ich geb doch nicht volle Punktzahl für ein schlechtes Programm? Dass es funktioniert, ist sehr gut, aber ein Programm muss auch wartbar sein.BTW wenn das goto sinnvoll und berechtigt ist, würde ich nichts abziehen, aber ich geh mal davon aus, dass hier eine Situation gemeint ist, in der das nicht der Fall ist. Von Automatismen halte ich nichts, ich bin ja kein Roboter.
-
In welcher Sprache den? In C brauchst du
goto
s. Wenn man nicht sehr kompliziertegoto
s im Code hat, anstelle vonbreak
odercontinue
goto
s verwendet oder anstelle von unter-Funktionen, dann würde ich keine Punkte abziehen.Bei z.B. so was:
void main() { if (something) { goto a; } else { goto b; } a: subroutine a goto ende; b: subroutine b goto ende; ende: }
Würde ich Punkte abziehen. Aber nicht bei:
void main() { int error = 0; a = malloc(); if (!routine_a(a)) { error = error_1; goto ende; } if (!routine_b(a)) { error = error_2; goto ende; } ende: free(a); return error; }
-
Bashar schrieb:
Schlechter Stil gibt Abzug. Ich geb doch nicht volle Punktzahl für ein schlechtes Programm?
Gibst Du auch in Mathe für eine unschöne aber korrekte Rechnung keine Punkte?
-
volkard schrieb:
Bashar schrieb:
Schlechter Stil gibt Abzug. Ich geb doch nicht volle Punktzahl für ein schlechtes Programm?
Gibst DU auch in Mathe für eine unschöne aber korrekte Rechnung keine Punkte?
Nunja mein Lehrer hat das getan
-
volkard schrieb:
Gibst Du auch in Mathe für eine unschöne aber korrekte Rechnung keine Punkte?
Ich finde das nicht vergleichbar.
-
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.
-
Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:
(f(x)=x³-2*x²)Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(1)=-1
f(-1)=-3
f(1)!=f(-1)
Da die Bedingung f(x)=f(-x) für x=1 nicht erfüllt ist, kann sie auch nicht für alle x erfüllt sein. Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".Was er haben will, und mit vollen Punkten versieht, ist folgendes:
Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(x)=f(-x)
x³-2*x²=(-x)³-2*(-x)²
x³-2*x²=-x³-2*x²
x³=-x³
=> nicht achsensymmetrisch.
-
volkard schrieb:
Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:
(f(x)=x³-2*x²)Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(1)=-1
f(-1)=-3
f(1)!=f(-1)
Da die Bedingung f(x)=f(-x) für x=1 nicht erfüllt ist, kann sie auch nicht für alle x erfüllt sein. Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".Was er haben will, und mit vollen Punkten versieht, ist folgendes:
Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(x)=f(-x)
x³-2*x²=(-x)³-2*(-x)²
x³-2*x²=-x³-2*x²
x³=-x³
=> nicht achsensymmetrisch.Genau so hab ichs gemeint :p
-
Bashar schrieb:
Schlechter Stil gibt Abzug. Ich geb doch nicht volle Punktzahl für ein schlechtes Programm? Dass es funktioniert, ist sehr gut, aber ein Programm muss auch wartbar sein.
Im Studium gab es bei uns zwei parallele Programmierveranstaltungen. In der einen bekam man bei einem nicht lauffähigen Programm am Schluss automatisch eine 5 oder 6, und der Programmierstil war vollkommen egal. Der andere Lehrer hat sich wiederum mit dem Code auseinander gesetzt, geschaut ob dieser a) der Aufgabe entspricht und b) der Codestil akzeptabel war.
Ich war zum Glück in der zweiten Gruppe, da meines Erachtens mehr als nur lauffähig/nicht lauffähig relevant ist. An der Arbeit würde ich auch einen "Punktabzug" bei schlechten Code bekommen (sofern der Code nicht nur von einem selbst gelesen werden soll), und der Zeitfaktor der Fertigstellung ist auch Situationsabhängig (und meinen bisherigen Chefs [wobei sie es teilweise noch lernen mussten] war es im Zweifel lieber, einen Auslieferungstermin ein wenig zu verschieben, als das die Kunden durch schwere Fehler verscheucht werden).
Bashar schrieb:
BTW wenn das goto sinnvoll und berechtigt ist,...
Ich persönlich kenne kaum eine Sprache wo ein goto wirklich sinnvoll ist, auch wenn ich dir recht gebe, das man niemals ganz vereinheitlichen kann. Ich habe aber tendenziell für den Punkteabzug gestimmt, da mir bislang keine Ausnahme in meinen bevorzugten Sprachen untergekommen ist (Ausnahme C# in Kombination mit switch, in dem es eine etwas andere Behandlung erfährt).
-
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 x3=-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?
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
DEvent schrieb:
void main() { ....
Für das
void main
würde ich aber Punkte abziehen.