Goto Punkteabzug?

Marc++us

Das ist genau wie bei einer Lösung in Mathematik, wo jemand einen genialen Weg findet, der nicht dem Sinne des Aufgabenstellers entsprach - aber wenn die Lösung richtig ist, wo ist dann der Kritikpunkt?

Ich halte das krankhafte Festhalten an der goto-Vermeidung für eine seltsame Überinterpretation von gewissen Vorgehensweisen.

Das folgende goto finden schließlich alle Leute gut:

void func()
{
   try
   {
      while (happy())
         something();
   }
   catch (ex& e)
   {
      bla();
   }
}

Lupo4u2

Kein Punktabzug, aber vielleicht ein Hinweis darauf das man es auch hätte anders machen können?

P.S. Bei uns gab es damals immer volle Punkte, wenn das Programm das gemacht hat, was es sollte... vollkommen egal, wie der Code aussah...

edit: Yeah! ab jetzt schreib ich keinen Beitrag mehr!

Marc++us

Lupo4u2 schrieb:

vollkommen egal, wie der Code aussah...

Das ist sicher auch nicht gut, aber wenn man "kein goto verwenden" nicht als Eingangsparameter in die Aufgabenstellung reinnimmt, darf man sich über die Verwendung bei der Lösung nicht beschweren.

Bashar

Marc++us schrieb:

Das ist genau wie bei einer Lösung in Mathematik, wo jemand einen genialen Weg findet, der nicht dem Sinne des Aufgabenstellers entsprach - aber wenn die Lösung richtig ist, wo ist dann der Kritikpunkt?

Du findest goto genial?

Das folgende goto finden schließlich alle Leute gut:

Das ist ja auch keins.

Jockelx

Lupo4u2 schrieb:

P.S. Bei uns gab es damals immer volle Punkte, wenn das Programm das gemacht hat, was es sollte... vollkommen egal, wie der Code aussah...

Hehe, ich hatte mal ein Programm in einer Klausur geschrieben, was wahrscheinlich sogar das einzige war, was man 1:1 durch den Kompiler hätte jagen können
und was funktioniert hätte.
Punkte hab ich aber recht wenig bekommen, zumindest weniger als z.B. mein Nachbar, dessen Programm eine syntaktische Katastrophe war,
dafür aber voll mit tollen Komentaren ala 'Diese For-Schleife zählt i von 0 bis 100 hoch'.

Walli

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.

Bashar

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.

DEvent

In welcher Sprache den? In C brauchst du goto s. Wenn man nicht sehr komplizierte goto s im Code hat, anstelle von break oder continue 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;
}

volkard

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?

Samyboy

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

Bashar

volkard schrieb:

Gibst Du auch in Mathe für eine unschöne aber korrekte Rechnung keine Punkte?

Ich finde das nicht vergleichbar.

Michael E.

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.

volkard

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.

Samyboy

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

asc

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

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