Da ist ja Assembler noch kürzer.audax hat geschrieben:Ungefähr das ist Enteprise Niveau:
http://paste.pocoo.org/show/99317/
MfG
HWK
HILFE!! Hausaufgabe/ zahlenrate programm!!
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Dafür hat Assembler keine so "tolle" IDE, die die Entwicklung ja sooo angenehm macht.HWK hat geschrieben:Da ist ja Assembler noch kürzer.
(Ok, ich habe mir jetzt mal Eclim installiert, mal sehen ob das was bringt)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wieso? Das scheint ja selbst einen Vi zu implementieren, mit Eclim kann ich entweder GVim einbetten oder Eclipse Headless im Hintergrund laufen lassen. Zudem ViPlugin Geld kostet und ein Eclipse-Plugin ist wohl eines der letzten Sachen für die ich Geld ausgeben würde.audax hat geschrieben:Eclipse + ViPlugin ist wesentlich besser.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Es läuft annehmbar und für den Kram an der Uni lässt man sowieso fast alles generieren...Leonidas hat geschrieben:Wieso? Das scheint ja selbst einen Vi zu implementieren, mit Eclim kann ich entweder GVim einbetten oder Eclipse Headless im Hintergrund laufen lassen. Zudem ViPlugin Geld kostet und ein Eclipse-Plugin ist wohl eines der letzten Sachen für die ich Geld ausgeben würde.audax hat geschrieben:Eclipse + ViPlugin ist wesentlich besser.
Mit eclim bin ich einfach nicht warm geworden.
@Lunar:
Es bietet sich an. Bei uns zumindest basiert alles auf Eclipse, die Hälfte der Lehre was Java angeht besteht aus Erklärungen zu Eclipse. Und es ist tatsächlich ganz gut für Java.
Ich find Netbeans wesentlich angenehmer =/
(Wir sind gar nicht OffTopic geworden, oder?)
(Wir sind gar nicht OffTopic geworden, oder?)
-
BlackJack
Wieso Offtopic? Wir sind bei Uni und Sachen, die man da machen muss, also noch ziemlich nahe an "Hausaufgaben" dran, und audax' schickes "Zahlenraten" in Java ist auch nur ein paar Beiträge her. Alles im grünen Bereich.
audax, deine Java-Lösung ist schon nicht schlecht, hat aber noch ein paar Probleme.
Das "new Random()" ist nicht nur schlecht testbar, sondern führt in schneller Folge aufgerufen auch immer zu der selben Zahl. Erzeuge daher nur einmal ein Random-Objekt und benutze dieses wiederholt. Dies ist ein idealer Fall, wo man Dependency Injection, z.B. mittels Spring oder Guice einsetzen kann. Da Random aber kein Interface sondern eine konkrete Klasse ist, musst du das zuvor allerdings noch abstrahieren. Dependency Injection kann auch bei der Factory-Methode helfen.
Die Ausgabe in "showResponse" sollte internationalisierbar sein. Ein ResourceBundle und ein MessageFormat ist nicht viel schwieriger einzusetzen als der jetzige Code. Dafür ist das "this" in dieser Zeile eher ungewöhnlich und entweder du benutzt überall "this" oder nirgends, wo es um Felder und Methoden der selben Klasse geht.
Dein "Trick", die einzelnen Nachrichten mit "%s" zusammenzusetzen und so ein bisschen Code zu sparen, ist unter Umständen nicht internationalisierbar, da es dort in jedem der Fälle anderer Formulierungen bedarf. Daher schlage ich vor, das anders zu lösen. Ein bisschen Redundanz bei den Texten ist in diesem Fall nicht schlimm.
Mache Klassen wie Guesser, die nicht zur Vererbung vorgesehen sind, final.
Statt einem "int" in GuessResponseFactory sollte ab Java 5 ein "enum" benutzt werden.
Bitte mache den String ERROR final. Das ist eine Konstante. Bei "bufRead" hättest du wirklich noch das "er" spendieren können. Namen sollten nicht unnötig gekürzt werden. Und mache auch diese Variable final. Das ist guter Stil.
Du fängst nicht die mögliche Exception bei parseInt ab. Das solltest du nachholen.
Mit fällt auf, dass "showResponse" stdout fest verdrahtet hat. Das ist nicht gut und dies in die Methode hineinzureichen wäre eine sinnvolle Abstraktion.
Deine Vorliebe für "do/while" statt eines einfachen "while" kann ich nicht nachvollziehen, aber das ist persönlicher Geschmack.
Ach ja, und wo ist die Javadoc-Dokumentation für alle Klassen und Methoden?
Stefan ;)
PS: Auch wenn das scherzhaft gemeint ist, sind das alles Punkte, die ich einem Kollegen in einem Code-Review von echtem Java-Code in einem größeren Projekt anmerken würde.
Das "new Random()" ist nicht nur schlecht testbar, sondern führt in schneller Folge aufgerufen auch immer zu der selben Zahl. Erzeuge daher nur einmal ein Random-Objekt und benutze dieses wiederholt. Dies ist ein idealer Fall, wo man Dependency Injection, z.B. mittels Spring oder Guice einsetzen kann. Da Random aber kein Interface sondern eine konkrete Klasse ist, musst du das zuvor allerdings noch abstrahieren. Dependency Injection kann auch bei der Factory-Methode helfen.
Die Ausgabe in "showResponse" sollte internationalisierbar sein. Ein ResourceBundle und ein MessageFormat ist nicht viel schwieriger einzusetzen als der jetzige Code. Dafür ist das "this" in dieser Zeile eher ungewöhnlich und entweder du benutzt überall "this" oder nirgends, wo es um Felder und Methoden der selben Klasse geht.
Dein "Trick", die einzelnen Nachrichten mit "%s" zusammenzusetzen und so ein bisschen Code zu sparen, ist unter Umständen nicht internationalisierbar, da es dort in jedem der Fälle anderer Formulierungen bedarf. Daher schlage ich vor, das anders zu lösen. Ein bisschen Redundanz bei den Texten ist in diesem Fall nicht schlimm.
Mache Klassen wie Guesser, die nicht zur Vererbung vorgesehen sind, final.
Statt einem "int" in GuessResponseFactory sollte ab Java 5 ein "enum" benutzt werden.
Bitte mache den String ERROR final. Das ist eine Konstante. Bei "bufRead" hättest du wirklich noch das "er" spendieren können. Namen sollten nicht unnötig gekürzt werden. Und mache auch diese Variable final. Das ist guter Stil.
Du fängst nicht die mögliche Exception bei parseInt ab. Das solltest du nachholen.
Mit fällt auf, dass "showResponse" stdout fest verdrahtet hat. Das ist nicht gut und dies in die Methode hineinzureichen wäre eine sinnvolle Abstraktion.
Deine Vorliebe für "do/while" statt eines einfachen "while" kann ich nicht nachvollziehen, aber das ist persönlicher Geschmack.
Ach ja, und wo ist die Javadoc-Dokumentation für alle Klassen und Methoden?
Stefan ;)
PS: Auch wenn das scherzhaft gemeint ist, sind das alles Punkte, die ich einem Kollegen in einem Code-Review von echtem Java-Code in einem größeren Projekt anmerken würde.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Doch. Einige Features sind auch gar nicht übel wie etwa der JUnit-Support, andere Dinge wären besser wenn die Autoren beim Implementieren auch nachgedacht hätten. Aber dass die IDE keine Vorschläge per Tabs hat wundert mich. Vielleicht ist das ja irgendwo konfigurierbar.lunar hat geschrieben:Leonidas, du nutzt doch nicht ernsthaft Eclipse für den Kram an der Uni?
Und nun mit Eclim kann ich vielleicht auch einen brauchbaren Editor verwenden.
sma, danke für das Code-Review. Jetzt weiß ich noch besser, was ich in Zukunft nicht machen will
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Oh, glückliche Uni-Zeit. Ich schreibe dies, während ich warte, dass mein Java-Code kompiliert und getestet wird... Übrigens ist natürlich Intellij IDEA die beste IDE ;)Leonidas hat geschrieben:Jetzt weiß ich noch besser, was ich in Zukunft nicht machen will :)
Stefan
Zwischenstand: http://paste.pocoo.org/show/99416/
Internationalisierung und JavaDoc fehlt noch
€dit:
Mit Ansätzen von JavaDoc:
http://paste.pocoo.org/show/99421/
Internationalisierung und JavaDoc fehlt noch
€dit:
Mit Ansätzen von JavaDoc:
http://paste.pocoo.org/show/99421/
Mhm, genau das versucht ja Audax zu vermeiden. Sein Programm verhöhnt scherzhaft das overengineering der Javaprogrammierer... Und das hat nix mit "Was ist OOP" von Leonidas zu tun, weil er OOP meiner Meinung nach realistisch und gut sieht. Der durchschnittliche Javaprogrammierer meiner Meinung nach aber nicht.hendrikS hat geschrieben:@Audax
Hast Du Dir mal Leonidas' Beitrag "Was ist OOP eigentlich?" durchgelesen.
Mach mal und versuch mal ein paar Dinge, speziell Absatz 4, "Nehmen..." auf Dein Programm zu uebertragen.
Warum gibt es eigenlich immer noch "Hello World"-Programme? Ein Zahlerateprogramm zum Vorstellen einer Sprache ist doch viel besser!
Und Nein, ich schreib das hier jetzt nicht in AWL
Und Nein, ich schreib das hier jetzt nicht in AWL
Lebe jeden Tag, als wäre es Absicht.
-
lunar
Du schreibst doch nicht tatsächlich Unittests für deine Hausaufgaben?Leonidas hat geschrieben:Doch. Einige Features sind auch gar nicht übel wie etwa der JUnit-Support,lunar hat geschrieben:Leonidas, du nutzt doch nicht ernsthaft Eclipse für den Kram an der Uni?
Ich weiß nicht, aber für das bisschen Code habe ich ja noch schneller Emacs gestartet, den Code und die build.xml geschrieben und das ganze per Mail verschickt, bevor Eclipse überhaupt gestartet hat
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Doch. Gerade für einige wie das parsen von unglückseligen Kommandozeilenoptionen sind Unittests recht praktisch. Wenn sie durchlaufen - fertigimplementiert. Allerdings mag Eclipse TDD nicht sonderlich und blinkt böse, macht Boxen und Icons auf (grad dass es nicht anfängt zu hupen und mich beschimpft) wenn ich in Tests Methoden verwende, die noch nicht definiert sind. Noch nie was von Top-Down gehört oder solunar hat geschrieben:Du schreibst doch nicht tatsächlich Unittests für deine Hausaufgaben?
Das Testen in der ``main()`` kann ich mir hingegen sparen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ah, wird besser :) Bitte beachte, dass der erste Satz eines Kommentars mit einem Punkt abgeschlossen werden sollte. Daraus generiert JavaDoc dann die Übersichtskommentare. Er sollte in der dritten Person singluar verfasst sein ("Returns foo"). PEP8 schreibt ja eine Imperativform vor ("Return foo"). Den "@author" empfinde ich kontraproduktiv zur Idee einer gemeinsamen "code ownership" im Programm und würde ihn dir daher anstreichen. Auch hinter einer } schreibt man IMHO klein weiter. Du meinst bei "Object" ja nicht "java.lang.Object" sondern einfach ein Objekt. Allgemein könnten die Kommentare noch etwas weniger redundant sein, denn Typen oder das etwas eine Klassse ich, kann ich auch aus dem Rest ersehen. Und sie enthalten noch Rechtschreibfehler. Hast du nicht Eclipse benutzt? Diese IDE sucht auch Rechtschreibfehler in JavaDoc-Kommentaren, wenn man sie lässt. Kann manchmal echt praktisch sein...audax hat geschrieben:Mit Ansätzen von JavaDoc
Stefan
Im Gegenteil sind Eclipse oder auch Intellij IDEA ideal für TDD, da sie einem helfen, den Code, den man braucht damit's kompiliert, automatisch zu erzeugen. Eclipse kann bekanntlich ja auch fehlerhafte Programme übersetzen und starten (war damals ein Novum für Java-IDEs und IDEA kann's 7 Jahre später immer noch nicht).Leonidas hat geschrieben:Allerdings mag Eclipse TDD nicht sonderlich und blinkt böse, macht Boxen und Icons auf (grad dass es nicht anfängt zu hupen und mich beschimpft) wenn ich in Tests Methoden verwende, die noch nicht definiert sind.
Das schöne ist doch gerade, dass du nur deinen Unit-Test schreiben musst, und Eclipse dabei schon den Rumpf für deinen Code erzeugt.
Also z.B. "new Foo()" in einem Unittest schreiben. Foo gibt's nicht. Also bietet die IDE an, die Klasse zu erzeugen. Danach alles markieren, jetzt lokale Variable erzeugen lassen. Dann steht da "Foo foo = new Foo()". Jetzt in die nächste Zeile, IDE ergänzt den ";". Man tippt "f"+complete, IDE ergänzt foo (nicht wirklich sinnvoll bei nur 3 Buchstaben aber je länger, desto praktischer). Man tippt ".bar(3, 4)", IDE vermisst "bar"-Methode, bietet an sie anzulegen, erkennt automatisch sinnvolle Typvorschläge für die Parameter usw.
Schneller geht's doch kaum.
Stefan