JAVA, C++, Delphi - IT-Klasse
-
Und ohne goto kriegt mans nicht hin?
-
Redhead schrieb:
bool istPrim(unsigned int kandidat){ bool ret = false; if(kandidat<2) goto ausgang; if(kandidat%2==0) goto ausgang; ret = true; for(unsigned int teiler=3;teiler*teiler<=kandidat;teiler+=2) if(kandidat%teiler==0) { ret = false; break; } ausgang: return ret; }VORSICHT IRONIE
VORSICHT IRONIElol.
und das nehme ich mal als grundlage und mache mit den MIRA-regeln, die bestimmt auch goto verbieten, noch das goto weg.bool istPrim(unsigned int kandidat){ bool ret = false; if(kandidat<2) ; else if(kandidat%2==0) ; else{ ret = true; for(unsigned int teiler=3;teiler*teiler<=kandidat;teiler+=2) if(kandidat%teiler==0){ ret = false; break; } } return ret; } [cpp] naja, break ist auch ein heimliches goto. muss weg. [cpp] bool istPrim(unsigned int kandidat){ bool ret = false; if(kandidat<2) ; else if(kandidat%2==0) ; else{ ret = true; for(unsigned int teiler=3;teiler*teiler<=kandidat&&ret==true;teiler+=2) if(kandidat%teiler==0){ ret = false; } } return ret; }naja, ret ist jetzt mehrfach belegt, macht ja nix. alternativ hätte man teiler=kandidat schreiben können oder besonderts elegant noch ne variable bauen, die nur zum schleifennabbruch dient.
(ich weiß nicht, ob das jetzt ironisch ist. ich nenne es mal realsatire.)
-
In gemeinsamer Kooperation ist es uns endlich gelungen eine lehrbuchgemässe
Version des "Primzahl"-Programmes zu erstellen.
-
ich fürchte, es waren die MISRA-regeln. http://www.ida.liu.se/~snt/teaching/SCRTS/MisraSoftwareGuidelines[1].pdf
das les ich jetzt mal...
november 1994. gabs da schon c++?
zwischenstand: bis seite 12 nur buzzwords und bilder.
zwischenstand: bis seite 50 isses ein proposal für case-tools.
auf seite 56 fangen coding guidelines an.
5.3.6 ist lustig.
aber singe-entry/single-exit steht da nirgends.
waren wohl doch nicht die MISRA-regeln.
-
volkard schrieb:
bool istPrim(unsigned int kandidat){ if(kandidat<2) return false; if(kandidat%2==0) return false; for(unsigned int teiler=3;teiler*teiler<=kandidat;teiler+=2) if(kandidat%teiler==0) return false; return true; }bool istPrim(unsigned int kandidat) { bool result; if (kandidat < 2) result = false; else if (kandidat % 2 == 0) result = false; else { bool looping = true; for (unsigned int teile = 3; looping && teiler*teiler <= kandidat; teiler += 2) { if (kandidat % teiler == 0) { looping = false; result = false; } } result = true; } return result; }Nicht übermäßig häßlich. Ich frage mich, was du damit aussagen wolltest.
EDIT: Ich hab mal einfach deine Funktion nachprogrammiert. Normalerweise ist mir Korrektheit (2 ist prim!) minimal wichtiger als Stil
-
Ich spreche von einer 11. Klasse.
-
Bashar schrieb:
Nicht übermäßig häßlich. Ich frage mich, was du damit aussagen wolltest.
aber schon beachtlich häßlich. und zwar als direkte folge der "single-entry/single-exit"-forderung. ich denke, ich konnte zeigen, daß die "single-entry/single-exit"-forderung den code verschlechtern kann. außerdem gibt es keinen grund mehr für diese forderung.
also ein ding ganz ohne vorteile aber mit gelegentlichen nachteilen. weg damit.
-
volkard schrieb:
aber schon beachtlich häßlich. und zwar als direkte folge der "single-entry/single-exit"-forderung. ich denke, ich konnte zeigen, daß die "single-entry/single-exit"-forderung den code verschlechtern kann.
IMHO konntest du das nicht. Dass die Anweisungen zum Führen des Kontrollflusses bei SESE etwas mehr Raum einnehmen, ist ja bekannt. Und ich bin noch nichtmal Verfechter von SESE, wie willst du also mit so einem Beispiel überhaupt irgendwen überzeugen?
volkard schrieb:
außerdem gibt es keinen grund mehr für diese forderung.
Wenn es je einen gab, warum gibts den dann nicht mehr?
-
Bashar schrieb:
IMHO konntest du das nicht. Dass die Anweisungen zum Führen des Kontrollflusses bei SESE etwas mehr Raum einnehmen, ist ja bekannt.
raum? der ist eher egal. inhaltlich ist die funktion schlimm (abgesehen von meinem fehler).
bool istPrim(unsigned int kandidat) { bool result;//uninitialisiert if (kandidat < 2) result = false;//und nu? ein return false sagt eindeutig und klar: //jup, das ergebnis ist berechnet und false wird zurückgeliefert und //nix passiert in dieser funktion mehr. also eine neue stil-forderung //ist entstanden: "sobald ein funktionsergebnis berechnet wurde, muß //das sofort rausreturnt werden". else if (kandidat % 2 == 0) //dieses und das folgende else sind nur platz. naja, fast. die einzelnen //tests sind nicht mehr so unabhängig. result = false; else { //ganz seltsame variable namens looping. bool looping = true; //seltsame laufbedingung //sollte ich erwähnen, daß das auch speed kostet? nee, willste nicht haben, das //argument. for (unsigned int teile = 3; looping && teiler*teiler <= kandidat; teiler += 2) { if (kandidat % teiler == 0) { looping = false; result = false; } } result = true; } return result; }Und ich bin noch nichtmal Verfechter von SESE, wie willst du also mit so einem Beispiel überhaupt irgendwen überzeugen?
ich versteh nicht, warum du den SESE-code nicht für total häßlich hältst.
Wenn es je einen gab, warum gibts den dann nicht mehr?
weil wir sutter gelesen haben und exceptionsicheren code bauen. falls die funktion SESE braucht, dann wegen close oder delete oder sowas am exit-point. so code ist aber sicher nicht exceptionsicher. machen wir ihn sicher durch destruktoren, und wenn's als auto_ptr ist, dann gibt es keinen grund für SESE mehr. da die funktion überall durch eine exception verlassen werden kann, kann sie auch überall durch return verlassen werden.
-
das
result = true;sollte vor die schleife, nehm ich an. womit dein nächstes argument wegfällt, daß jede zuweisung an result gelesen werden darf wie ein return.
-
da es sonst noch niemand gesagt hat, tu ich's eben:
wie waer's mit Python?
Vorteile:
* kein Kompilieren und Linken noetig (d.h. eine typische Anfaengerfehlerquelle weniger)
* einfachere Syntax als C & Co. (wieder eine tyiche Anfaengerfehlerquelle weniger)
* moderne Sprache
Multiparadigmasprache: funktional, OO, prozedural... bietet mehr didaktischen Freiraum
* gratis (besonders bei ObejctPascal koennt ich mir vorstellen wie wieder mal x Schueler sich mal eben wieder Delphi raubkopieren)
* "batteries included": man kann damit mehr machen ohne erst lang Zusatzlibs zu installieren (ist wohl nur gegen C++ ein Argument, aber trotzdem)
-
Python kann der Lehrer nicht.
-
Python ist schon cool, aber den Umstieg von Python auf C++ stelle ich mir ziemlich fies vor.
-
Blue-Tiger schrieb:
wie waer's mit Python?
wenn sowas auch gilt, ist doch ruby sofort angemessener.
-
Hmm, also wie ich programmieren gelernt habe:
Ungefähr 6 Klasse: 1 Jahr lang privat VBA gelernt (rückblickend guter Einstieg aber schlechte Lektüre erwischt, so ein „in 21 Tagen“ Buch)
8 Klasse 1. Halbjahr: Programmierbaukasten (leicht zu verstehen, vor allem da ich schon VBA halbwegs konnte und schnelle Erfolge (nach 4 Monaten Schulunterricht hatte jeder sein eignes Programm erstellt, bei mir einfacher Moorhunclone)
9 Klasse 1. Halbjahr: HTML 2. Halbjahr Javascript
10 Klasse (leider nur noch Einstündig): Java
Demnach würde ich VBA als Einstieg empfehlen
Ps: Bitte kein Falmeware alla HTML ist doch eh keine Programmiersprache oder Programmierbaukästen sind nur was für Skriptkiddys
-
volkard schrieb:
Und ich bin noch nichtmal Verfechter von SESE, wie willst du also mit so einem Beispiel überhaupt irgendwen überzeugen?
ich versteh nicht, warum du den SESE-code nicht für total häßlich hältst.
Ich finde ihn häßlich, aber nicht so übermäßig, dass mich das überzeugen würde, wenn ich SESE für eine gute Idee halten würde.
Wenn es je einen gab, warum gibts den dann nicht mehr?
weil wir sutter gelesen haben und exceptionsicheren code bauen. falls die funktion SESE braucht, dann wegen close oder delete oder sowas am exit-point. so code ist aber sicher nicht exceptionsicher. machen wir ihn sicher durch destruktoren, und wenn's als auto_ptr ist, dann gibt es keinen grund für SESE mehr. da die funktion überall durch eine exception verlassen werden kann, kann sie auch überall durch return verlassen werden.
Da brauchst du gar nicht bis Sutter ausholen. Code, der Exceptions nutzt, ist im Allgemeinen prinzipiell nicht SESE.
Was hältst du hier von (das ist nach echtem Code):
int foobar() { int result = 0; if (f) { result = blablub ... if (result) { result = blublub ... if (result == 1) { if (was anderes) { Buffer = malloc(irgendwas); if (Buffer) { result = blubdiwub if (result == l) { blabla if (quux) { .... } else { // handle error ... } } else { // handle error ... } free(Buffer); } else { // handle error ... } } //etc.Da hat jemand SESE zur obersten Maxime gemacht und sich nichts dabei gedacht, dass der Code nicht mehr schmerzfrei lesbar war.
-
Hi
Sorry mein Fehler. Hab mich verschrieben es sind die MISRA regeln. Das Document das du gefunden hast meinte ich eigentlich nicht. Es gibt auch ein Regelwerk speziel für c. C ist nicht C++ somit nicht vergleichbar und mein Fehler.
Ich persönlich find SESE eine nette Idea die ihre daseinsberechtigung hat. Das wichtigste sollte aber sein das der Code lesbar bleibt.
gruss Termite
-
Also da ich auch mal Info-Grunzkurs hatte, hier mal meine persönlichen Erfahrungen:
Wir haben angefangen mit Delphi, das wir bis zum Ende der 12. gemacht haben wenn mich net alles trügt. Dann Lehrerwechsel und die Frage was machen wir, einer (Schüler) schlug html vor, der Lehrer wollte bissl Linux-Grundlagen machen, irgendwer erwähnte Applets und weil ich auf den ganzen Webkrams keinen Bock hatte hab ich dann nur Java durchgeboxt, irgendwie... (Ich hatte vorher schon n guten Batzen Progerfahrung, u.a. Java)
Wie schlug sich also der Grunzkurs in den Disziplinen Delphi und Java?
Delphi:
Grausam, einfach grausam... Angefangen mit der Tatsache das 90% der Schüler 90% ihrer Zeit mit dem herumschieben und basteln von schicken Fenstern beschäftigten, um dann ihren "button_click" Source von irgendwem zu kopieren oder von Vorlagen abzutippen, hin zur totalen verstümelung von Quelltext (ich durfte ja als etwas Fähigerer helfen
). Naja, ich glaube in den 2 Jahren oder so hat nur durch Delphi + Unterricht keiner was gelernt, nichtmal den Segen den tab bringen kann...Java:
Da wir in Java keine GUI's gemacht haben, sondern alles über Konsole wars hier schon etwas besser... Ich hab zwar n referat am Anfang zu OOP gehalten, aber das hat eigentlich nur gezeigt, dass das Thema recht anspruchsvoll ist vom Konzept her
Persönlich würd ich sagen nehmt Python (hab das vor n paar Tagen entdeckt als ich mich mit bash-scripts beschäftigt hatte (#!/usr/bin/python)), das ist recht einfach zu erlernen und die bessere variante zu Beginn als qbasic (damit hab ich auch mal angefangen!), und wenn Python rausfällt, hm, schwierig...
Ich würd glaub ich Java empfehlen... Wenn man OOP einigermaßen erklärt, kann man da wohl noch am meisten bei lernen...
-
Jap Python ist ne sehr feine Sprache, schau ich mir gerade selbst so nebenher an.
Das dumme ist nur, dass ich Python gerne für kleinere Tools einsetzen würde, aber meist greif ich doch auf C++ zurück da ich für Python extra nachschlagen müsste.
Aber das Problem betrifft natürlich nicht jeden *g*
-
Jo, das Nachschlagen bzw angewöhnen einer neuen Lib ist mir auch bissl nervig... da fehlt mir derzeit einfach der Biss... Werd mir wohl irgendwann Lektüre dafür zulegen müssen...