break; - Veraltet?
lima-city → Forum → Programmiersprachen → Java
bedingung
beispiel
break
code
frage
jemand
kopf
lehrerin
leute
machen
point
problem
programm
quellcode
schleife
schleifen
technik
theoretisches geschwafel
umfangreichem quellcode
verstehen
-
Hallo LC-Community,
meine Informatiklehrerin (die wollt ihr nicht kennenlernen, außerdem hat sie eig. keine Ahnung :D) hat meinen Programmcode bemänglet, dass ich das Schlüsselwort break in einer for-Schleife verwendet habe, da break veraltet ist und nur noch ein Überbleibsel aus Basic-Zeiten sei.
Ist das wirklich so, oder ist es ganz legitim, break zu verwenden?
Bedanke mich für Antworten
mfg
Mator -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Ich halte Dinge wie break und continue für sehr wertvolle Werkzeuge, um Sonderfälle abzufangen. Von daher sehe ich das keineswegs als veraltet an. Genausogut könnte man switch-Statements als veraltet ansehen, denn das sind auch nur etwas hübschere gotos.
Wenn das so veraltet ist, dann soll sie dir zeigen, wie man es ohne break macht. Sie ist schließlich deine Lehrererin und ist dafür verantwortlich dir zu zeigen, wie man es besser macht. Und dann kannst du gerne entscheiden, ob die Lösung deiner Lehrerin hübscher/lesbarer ist, als wenn man einen Sonderfall einfach mit break behandelt. -
Wenn du break in einem if verwendest, könntest du diese Bedingung auch in den Schleifenkopf schreiben. Es ist in der Tat ein eher schlechter Stil. Break ist eigentlich nur noch in Switch-case gern gesehen und solltest du in einem öffentlichen Projekt mit proggen solltest du es unterlassen, ansonsten machst du dir wohl nur Feinde, denn es macht den Sourcecode höchstwahrscheinlich schwer leserlich. Break also nur verwenden, wenn du weißt, was du tust.
Würde mich aber mal der Sourcecode der Schleife interessieren.
€dit da bladehunter schneller war: Continue finde ich aber auch manchmal ganz nützlich, da die Alternative ein if um den gesamten weiteren Schleifeninhalt ist.
Beitrag zuletzt geändert: 22.4.2011 9:58:10 von reimann -
Danke für die SEEEHHHR schnellen Antworten :D
Wenn du break in einem if verwendest, könntest du diese Bedingung auch in den Schleifenkopf schreiben.
Also du meinst, man sollte das so machen:
for(int i = 0; i < var && [BEDINGUNG]; i++) {/* Anweisungen */}
Darf man das denn so machen?
mfg
Mator -
Also meine persönliche Ansicht dazu ist: Ich finde es häßlich und hätte lieber ein separates break;
Und wenn man die zusätzliche Abbruchbedingung im Schleifenkopf versteckt, überliest man sie relativ leicht. Da investiere ich lieber 1-2 zusätzliche Zeilen im Schleifenkörper, um den Code lesbarer zu gestalten.
Beitrag zuletzt geändert: 22.4.2011 10:09:07 von bladehunter -
Ich finde nämlich auch, dass das nicht wie eine normale for-Schleife aussieht. Danke für die Antworten.
mfg
Mator -
Das kommt drauf an welche Sprache du benutzt, aber in Java und C++ ja. In einem Struktogramm hingegen leider nicht, obwohl selbst da meine Lehrerin einen Aussprung (break) verboten hat. Ich bin also auch betroffen davon.
@bladehunter: Ja naja, aber ich finde es schöner gleich zu Anfang zu wissen, warum etwas aus einer Schleife springt, als in endlosen ifs alle breaks rauszusuchen. In einer kleinen Schleife mag das noch gehn, aber ab 100 Zeilen Schleifeninhalt mit mindestens 20 ifs würde ich den Progger am liebsten erwürgen, köpfen und vierteiln. Höchstes Ziel ist immer Leserlichkeit und da kann mans nicht jedem recht machen, aber man sollte schon darauf achten, dass jemand der es liest nicht mit 50 Parametern debuggen muss, um den Ablauf der Schleife zu verstehn. Ein generelles Verbot kann man aber nicht aussprechen, da ansonsten diese Funktion schon aus der Spezifikation entfernt worden wäre.
@mator-kaleen:
Es ist ja nicht so, als ob es nur for-Schleifen geben würde. Kannst auch gleich eine Zählvariable benutzen, aber das passt wohl auch nicht in die Ästhetik
Beitrag zuletzt geändert: 22.4.2011 10:12:42 von reimann -
Ich kenne immer ein gutes Mittel: Kommentare
Ich denke, es ist am einfachsten, einfach ein paar Zeilen Kommentar vor eine schleife zu schreiben, um so etwas gleich klar zu stellen.
@reimann
Außerdem: im Bedingungsteil einer Schleife 20 Bedingungen unterbringen? Das sieht doch auch nicht gut aus und so kann man wenigsten irgendwo ausgeben, an welchem if man aus der Schleife raus ist. Das kannst du im Bedingungsteil der Schleife nicht. -
reimann schrieb:
@bladehunter: Ja naja, aber ich finde es schöner gleich zu Anfang zu wissen, warum etwas aus einer Schleife springt, als in endlosen ifs alle breaks rauszusuchen. In einer kleinen Schleife mag das noch gehn, aber ab 100 Zeilen Schleifeninhalt mit mindestens 20 ifs würde ich den Progger am liebsten erwürgen, köpfen und vierteiln. Höchstes Ziel ist immer Leserlichkeit
Vollkommen richtig. Ich denke bei solchen Breaks an Bedingungen, die sehr nah am Anfang des Schleifenkörpers getestet werden. Dass irgendwo hinten im Schleifenkörper noch ein break kommt, ist in der Tat schlechter Stil.
Unabhängig davon sollte man immer versuchen seine Blöcke möglichst kurz zu halten und größere Teile in Funktionen auslagern, sofern es Sinn ergibt. -
reimann schrieb:
Ich sehe das auch so, dass der Einsatz eines break; eher ein schlechter Programmierstil ist. Sollte also wirklich nur in Switch-Anweisungen (oder Case, je nach Programmiersprache) und Ausnahmefällen verwendet werden.
Wenn du break in einem if verwendest, könntest du diese Bedingung auch in den Schleifenkopf schreiben. Es ist in der Tat ein eher schlechter Stil. Break ist eigentlich nur noch in Switch-case gern gesehen und solltest du in einem öffentlichen Projekt mit proggen solltest du es unterlassen, ansonsten machst du dir wohl nur Feinde, denn es macht den Sourcecode höchstwahrscheinlich schwer leserlich. Break also nur verwenden, wenn du weißt, was du tust.
mator-kaleen schrieb:
Danke für die SEEEHHHR schnellen Antworten :D
Wenn du break in einem if verwendest, könntest du diese Bedingung auch in den Schleifenkopf schreiben.
Also du meinst, man sollte das so machen:
for(int i = 0; i < var && [BEDINGUNG]; i++) {/* Anweisungen */}
Darf man das denn so machen?
mfg
Mator
In so einem Fall würde ich von einer FOR-Schleife aufgrund der schwereren Lesbarkeit abraten und dafür eine WHILE- oder DO-WHILE-Schleife einsetzen.
Beitrag zuletzt geändert: 22.4.2011 10:22:15 von wagnerm -
Ähm naja bei 20 Bedingungen, warum die Schleife vorzeitig verlassen werden soll, sollte man vielleicht das Design nochmal überdenken. Ich streite wie auch bei break nicht ab, dass es solche Situationen gibt, aber ich persönlich bin noch nie über 4 Bedingungen hinausgekommen. Es gab icher schon ifs mit mehr Bedingungen, aber so einen Schleifenkopf (auch (do) while eingeschlossen) habe ich noch nie gesehen.
Vllt hat da bladehunter ja mehr gesehn.
@bladehunter:
Ja, aber da ist sicher auch das Problem, dass diese Inhalte bis dahin nicht gelehrt wurden und deshalb sich die Schüler oftmals schon nen Kopf machen, um Dinge die dann später eigentlich nie auftreten werden. Merke ich auch in meiner Ausbildung. Da sind Unterprozeduren oder Funktionen noch nicht dran gewesen und einige verstehen deshalb nicht, warum manches so oder so gemacht werden muss/soll. -
reimann schrieb:
@bladehunter:
Ja, aber da ist sicher auch das Problem, dass diese Inhalte bis dahin nicht gelehrt wurden und deshalb sich die Schüler oftmals schon nen Kopf machen, um Dinge die dann später eigentlich nie auftreten werden. Merke ich auch in meiner Ausbildung. Da sind Unterprozeduren oder Funktionen noch nicht dran gewesen und einige verstehen deshalb nicht, warum manches so oder so gemacht werden muss/soll.
Ich bin zwar Schüler und das stimmt zwar, aber:
1. Machen wir nichts das so komplex ist, dass das nicht nötig
2. Haben wir Funktionen schon gemacht
3. Habe ich einen Nebenjob in C#
Das Problem ist eher die Lehrerin: Die mach alles genauestens aus dem Buch und lässt sich nicht auf andere Ideen ein. Das ist das Problem. Die hat in meinem Code nur das Schlüsselwort break gesehen -> "Break ist veraltet. Der Code ist schlecht.". Mehr hat sie sich gar nicht angeschaut.
@wagnern
Das könnte u.U. heißen, dass man am Ende mit i++ noch höher zählen muss. Darüber könnte man nun auch diskutieren und ich denke, dass ich jetzt eineige Ideen bekommen habe. -
mator-kaleen schrieb:
Hmm ... wie meinst du das? Die WHILE-Schleife ist genauso kopfgesteuert wie die FOR-Schleife...
[...]@wagnern
Das könnte u.U. heißen, dass man am Ende mit i++ noch höher zählen muss.[...]
-
reimann schrieb:
@bladehunter:
Ja, aber da ist sicher auch das Problem, dass diese Inhalte bis dahin nicht gelehrt wurden und deshalb sich die Schüler oftmals schon nen Kopf machen, um Dinge die dann später eigentlich nie auftreten werden. Merke ich auch in meiner Ausbildung. Da sind Unterprozeduren oder Funktionen noch nicht dran gewesen und einige verstehen deshalb nicht, warum manches so oder so gemacht werden muss/soll.
Ich denke das Problem ist weniger dass gewisse Themen nicht behandelt wurden, sondern dass die Problematik mit bestimmten Techniken nicht deutlich genug wird. Wenn du nur nen 0815-Informatik-Kurs hast, der nicht über 300-Zeilen-Programme hinausgeht, dann entstehen viele Probleme aus der Praxis erst gar nicht, da die entsprechende Komplexität nicht gegeben ist.
Daher wäre es wahrscheinlich ratsam die Schüler mit umfangreichem Quellcode (von jemand anderem) zu konfrontieren, damit sie kapieren, welche Techniken für das Verständnis hinderlich sind. Ansonsten ist das alles nur theoretisches Geschwafel.
Achja, die for-Schleifen, die mir so über den Weg laufen haben selten mehr als eine kopfgesteuerte Abbruchbedingung.
@mator-kaleen: Ich kenne deine Lehrerin (zum Glück?) ja nicht. Aber wenn sie sowas sagt, wie "Break ist veraltet, der Code ist schlecht", dann solltest du eben Rückfragen stellen und sie soll dir genau erklären, was daran problematisch ist. -
Das Problem ist, dass wir alles auch erst in Struktogrammen machen müssen und die sind sehr platzintensiv, wenn man >300 Zeilen erreichen will.
Das Problem ist aber, dass in den Prüfungen auch nur Struktogramme drankommen und demzufolge wird es nie wirklich komplex. Wir Anwendungsentwickler machen deshalb auch immermal so unsere Späßchen und versuchen den anderen n bisschen Hilfe zu geben. (Anwendungsentwickler und Systemadministratoren werden größtenteils gemeinsam unterrichtet, was Probleme in der Programmierung zur Folge hat, lustigerweise aber nicht andersrum in dem Computerbasteln
)
Und ich meinte auch generell andere Schleifen bzw. auch Bedingungen für break. Mich würde es wundern, wenn eine Schleife, ob nun im Kopf/Fuß oder per if und break mehr als 5 Abbruchbedingungen hat. -
@wagnerm
Bei einer for-Schleife geht es ja meistens darum einen Counter zu haben. Also muss man dann z.B. ein i++; am Edner der Schleife anhängen.
@bladehunter
Daher wäre es wahrscheinlich ratsam die Schüler mit umfangreichem Quellcode (von jemand anderem) zu konfrontieren, damit sie kapieren, welche Techniken für das Verständnis hinderlich sind. Ansonsten ist das alles nur theoretisches Geschwafel.
Klar wäre das sinnvoll, nur muss man die Grundlagen von Java erst mal verstehen, bevor man anfangen, Quellcode von anderen Leuten anzuschauen. Das Problem ist, unsere Lehrerin macht das alles wortwörtlich aus dem Buch, d.h. das versteht sowieso niemand, der keine Erfahrung im Programmieren hat.
@mator-kaleen: Ich kenne deine Lehrerin (zum Glück?) ja nicht. Aber wenn sie sowas sagt, wie "Break ist veraltet, der Code ist schlecht", dann solltest du eben Rückfragen stellen und sie soll dir genau erklären, was daran problematisch ist.
Wollte ich auch, aber sie hat sich meinen Code erst in der letzten Minute vor Stundenende angeschaut. Außerdem geht sie nicht auf die Fragen der Schüler richtig ein. -
break benutze ich vor allem bei erweiterten for-Schleifen. Wenn ich die Zählvariable nicht brauche, ist das die imho eleganteste Lösung:
Point x5y3Point; for(Point p : points) if(p.x ==5 && p.y == 3){ x5y3Point = p; break; }
Und nein, ein blöderes Beispiel fällt mir grad nun wirklich nicht ein. -
mator-kaleen schrieb:
@bladehunter
Daher wäre es wahrscheinlich ratsam die Schüler mit umfangreichem Quellcode (von jemand anderem) zu konfrontieren, damit sie kapieren, welche Techniken für das Verständnis hinderlich sind. Ansonsten ist das alles nur theoretisches Geschwafel.
Klar wäre das sinnvoll, nur muss man die Grundlagen von Java erst mal verstehen, bevor man anfangen, Quellcode von anderen Leuten anzuschauen.
Java ist meiner Ansicht nach sowieso total ungeeignet für den Einstieg in die Programmierung. Java verwendet zu viele abstrakte Konzepte, die für kleinere Programme (die typisch für den Informatikunterricht sind) mehr hinderlich als hilfreich sind. Viel besser wäre zum Beispiel Lua.
Das Problem ist, unsere Lehrerin macht das alles wortwörtlich aus dem Buch, d.h. das versteht sowieso niemand, der keine Erfahrung im Programmieren hat.
Dann überrascht es mich auch nicht, dass sie nicht auf eure Fragen eingeht. Weißt du, ob sie überhaupt Informatik auf Lehramt studiert hat? -
Nein, sie hat nicht auf Lehramt studiert. Und JAVA steht halt mal im Lehrplan... also kann man da nicht viel machen. LUA kennen die vom Kultesministerium halt nicht.
-
Manche Lehrer fordern halt den Stil den sie im Kopf haben, weichst du von ihrem Muster ab, hast du nen "unsauberen" schreibstil.. ist mir schon oft genug passiert.. interessiert´ mich herzlich wenig... solange du nicht sitzenbleibst brauchts dich auch nicht kümmer..
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
