Was ist für euch guter Programmcode?

[@Optimizer]

Optimizer schrieb:

Das Studium ist ein bisschen anders, als ich mir das vorgestellt habe. Ich möchte nicht sagen schlecht. Aber wenn du mit der Erwartung reinkommst "jetzt voll was über Computer zu lernen", wirst du enttäuscht werden. Das musst du dir in der Freizeit selber beibringen.
Zumindest in den ersten Semestern ist es eher ein Mathematik-Studium, so Fächer wie Compilerbau und Software-Engineering klingen aber natürlich vielversprechend. Alles in allem habe ich jetzt gerade erst mein (99% Mathematik-) Grundstudium beendet, also kann ich dir dazu noch nicht so wirklich viel sagen.

Ohh, ich dachte nur an einer Uni hat man soviel Mathe? Ich hab nur GK und damit auch noch einige Probleme...

Wir war Deine Vorbildung in Mathe?

[Walli]

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

[wieder M.]

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

Wenigstens ist meine Signatur etwas besser geworden.

[simon.phoenix]

wieder M. schrieb:

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

Wenigstens ist meine Signatur etwas besser geworden.

Wenn man nen lustigen Tag hat kann man sich über diesen Satz totlachen.

Aber wohl leider Fake, so kennen wir unseren Mecnels garnicht

[otze]

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

100% agree, der thread ist richtig gut

fast sogut wie der eine von vor ca nem halben jahr, der einen auf dicke hose gemacht hat, und dann von den mods aus dem forum vertrieben wurde

[simon.phoenix]

otze schrieb:

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

100% agree, der thread ist richtig gut

fast sogut wie der eine von vor ca nem halben jahr, der einen auf dicke hose gemacht hat, und dann von den mods aus dem forum vertrieben wurde

War nicht zufällig "ProjecktX" oder so :D?

[Gast]

@Optimizer schrieb:

Ohh, ich dachte nur an einer Uni hat man soviel Mathe? Ich hab nur GK und damit auch noch einige Probleme...

Naja mein Studiengang heißt ja auch schon bezeichnenderweise Informatik/Mathematik. Ich erwarte jetzt allerdings schon auch, dass es sich "bessert". War aber schon krass bis jetzt, IMHO.
War bis zur zehnten aufm Gymnasium und hab dann FOS Technik gemacht.

[Mecnels]

simon.phoenix schrieb:

otze schrieb:

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

100% agree, der thread ist richtig gut

fast sogut wie der eine von vor ca nem halben jahr, der einen auf dicke hose gemacht hat, und dann von den mods aus dem forum vertrieben wurde

War nicht zufällig "ProjecktX" oder so :D?

Ist Euch eigentlich schon einmal aufgefallen, dass nicht ich die ganze Zeit Euch einreden will, was IHR in Euren Codes besser machen solltet, sondern genau umgekehrt - ich kann ja gar nicht wissen, was Eure Aufgabenstellung war. Ein Alien mit telepathischen Fähigkeiten bin ich nicht, und darum maße ich mich auch nicht an, den Code anderer herunter zu machen, wenn ich die Aufgabenstellung nicht genau kenne. Gute Kommentierung ist in jedem Fall das Wichtigste überhaupt, speziell wenn andere auch mit dem Code etwas anfangen können soll.

Stell Dir vor es gäbe eine Funktion, die hieße
SetCooperativeLevel(). Toll wie der Bezeichner über sich selber spricht, oder? Weißt Du jetzt anhand des Namens, was die Funktion macht? Worauf Du bei der Parameterübergabe eventuell besondere Rücksicht nehmen solltest? In welchem Kontext und nach welchen zuvor stattgefundenen Initialisierungen Du die Funktion überhaupt aufrufen darfst, wenn Du schwere Systemfehler verhindern willst? Nein. Der Bezeichner sagt nichts über alles das aus, Du kannst die Funktion natürlich einfach aufrufen, und Dich dann wundern, warum etwa das Betriebssystem die Kontrolle über die Tastatur verloren hat und ein Kaltstart fällig geworden ist. Im Falle wie Funktionen wie dieser stehen die Kommentare, die Dir das ersparen hätten können, zwar nicht irgendwo im Quelltext, sondern als Lektüre in Büchern und der DirectX Hilfe, aber es sind nichtsdesto trotz Kommentare, die Dir den sinnvollen Umgang mit der Funktion überhaupt erst erläutern.

Darum kann es so etwas wie 'Deine Kommentare erzählen Romane und darum ist der Quellcode schlecht' gar nicht geben, eher können gar nicht genügend Kommentare dastehen, vor allem wenn andere mit dem Quellcode etwas anfangen sollen. Jeder Extra Kommentar ist da ein Fehler weniger, den man später debuggen muss.

Nein, ich bin es nicht, der behauptet, alles besser zu wissen. Das seid schon ihr mit 'nimm Konstanten statt defines', 'nimm explicit statt Elementfunktionen', 'nimm <vector> statt einen massgeschneiderten Container selber zu schreiben', 'vermeide um jeden Preis Schleifen', 'mach Fehlerbehandlung mit Exceptions anstatt mit bool-Rückgabewerten', 'verwende keine WINAPI und nie und nimmer MessageBox', UND UND UND

Das sind alles EURE Kommentare. Alles was ich mache, ist, einen optimierten Quellcode für ein funktionsfähiges Programm, das eh nur für meinen Enkel gedacht ist und das ich mir in zwei Tagen aus dem Ärmel geschüttelt habe - ohne Leistungsdruck und völlig aus freien Stücken - so gut es mir möglich ist, zu verteidigen. Vielleicht könntet Ihr ja in Zukunft schreiben, wie IHR es anders gemacht hättet, und ab und zu ein Eingeständnis dass man selber nicht ALLES wissen kann, wie ich es gerade (und nicht zum ersten Mal) mache, würde das Diskussionsklima sicher wieder auf ein gesundes Level abkühlen.

Mich interessiert ja auch, wie Ihr Projekte angeht, weil ich da ja sicher auch genug lernen kann.

Gute Nacht.

[Gregor]

@JBeni: ...zwar etwas spät, aber ich sag auch nochmal etwas zu deinem Code.

<DISCLAIMER: Was ich sagen werde bezieht sich größtenteils expilzit auf Java-Code und die bei Javaprogrammierern vorherrschende "Design-Philosophie". Mit anderen Worten: Das ist nicht auf C++ Code und den dortigen Prinzipien übertragbar und wird teilweise in die genau entgegengesetzte Richtung gehen.>

1. Im Großen und Ganzen ist dein Code gut. Die Anmerkungen, die ich im Folgenden mache betreffen größtenteils nur den "Feinschliff".

2. Du nutzt zu wenig "final" für Variablen. "final" sollte bei lokalen Variablen, Parametern und Membervariablen so oft wie möglich genutzt werden, da hierdurch gewisse Fehler zur Comilezeit erkannt werden können, die sonst schwer zu finden wären. Bei Konstanten kommt bezüglich final außerdem noch ein Optimierungsaspekt hinzu.

3. Du machst zu wenig bzw. nahezu gar keine Checks auf Gültigkeit von Parametern, Zwischenergebnissen usw.! Schmeiß doch mal bezüglich Fehlern bei der Benutzung der Klasse entsprechende RuntimeExceptions und nutze für innere Checks assert. Du wirst den Vorteil davon nach den nächsten paar Bugs, die du produziert hast, zu schätzen gelernt haben. Ein Performanceargument gegen solche Checks zählt im Übrigen nur begrenzt: (Angeblich) kann die JVM überflüssige Checks zur Laufzeit eliminieren.

4. Irgendwo hast so eine if ... else if ... else if ... Orgie im Code. Das das nicht gerade ideal ist, sondern äußerst redundant, ist dir sicherlich klar. Überleg dir mal, wie du das eliminieren kannst. Wird vermutlich nicht ganz einfach sein, mir fällt auf anhieb zumindest nichts ein, aber irgendwas geht immer. Wenn du es wirklich restlos entfernen willst, wirst du wohl um eine Änderung des Designs im etwas größeren Rahmen nicht vorbeikommen. Mußt du selbst wissen, ob es dir das wert ist. Sooo schlimm ist diese Orgie noch nicht, aber es wäre sicherlich mal ne gute Übung, das restlos zu beseitigen, weil du dir dann in jedem Fall eine Designalternative für solche Fälle klar machst.

5. Gut finde ich, dass du anscheinend mindestens alle öffentlichen Dinge mit Javadoc-Kommentaren versehen hast.

6. Bei Java 1.5 Code kann ich dir für jede überschriebene Methode @Override als Marker-Annotation empfehlen, um weitere Fehler zur Compilezeit zu finden.

7. In einem Code, in dem alle Bezeichner auf englisch sind, kommt ein Bezeichner "typ" sehr überraschend. ...ist sicher ein Versehen, oder?

So, das reicht erstmal. Ist gar nicht viel Kritik geworden. Abschließend noch ein Tipp: Du bist, nach deinem Code zu urteilen, gerade an einem Punkt, an dem sich das Buch "Effektiv Java programmieren" von Joshua Bloch für dich vermutlich sehr lohnt. Schau da mal rein. ...oder warte noch etwas auf die Version für Java 1.5 davon (kommt bestimmt demnächst irgendwann raus).

[scrub]

Mecnels schrieb:

Darum kann es so etwas wie 'Deine Kommentare erzählen Romane und darum ist der Quellcode schlecht' gar nicht geben, eher können gar nicht genügend Kommentare dastehen, vor allem wenn andere mit dem Quellcode etwas anfangen sollen. Jeder Extra Kommentar ist da ein Fehler weniger, den man später debuggen muss.

wenn es darum geht, quelltext möglichst gut zu formulieren, redet man aber zwangsläufig über prinzipielle erwägungen. oder änderst du von projekt zu projekt deinen programmierstil?
soweit ich das überflogen habe, sind auch meistens nur kommentierungen kritisiert worden, die redundant oder trivial waren. sowas ist ja auch müll...

Mecnels schrieb:

Nein, ich bin es nicht, der behauptet, alles besser zu wissen. Das seid schon ihr mit 'nimm Konstanten statt defines', 'nimm explicit statt Elementfunktionen', 'nimm <vector> statt einen massgeschneiderten Container selber zu schreiben', 'vermeide um jeden Preis Schleifen', 'mach Fehlerbehandlung mit Exceptions anstatt mit bool-Rückgabewerten', 'verwende keine WINAPI und nie und nimmer MessageBox', UND UND UND

ja, du beschreibst hier verschiedene zustände eines fortwährenden prozesses. du weigerst dich aber beharrlich, die vorteile von neuerungen zu nutzen. wahrscheinlich fährst du einen golf I, in den du dir ein unsynchronisiertes getriebe hast einbauen lassen.

Mecnels schrieb:

Das sind alles EURE Kommentare. Alles was ich mache, ist, einen optimierten Quellcode für ein funktionsfähiges Programm, das eh nur für meinen Enkel gedacht ist und das ich mir in zwei Tagen aus dem Ärmel geschüttelt habe - ohne Leistungsdruck und völlig aus freien Stücken - so gut es mir möglich ist, zu verteidigen. Vielleicht könntet Ihr ja in Zukunft schreiben, wie IHR es anders gemacht hättet, und ab und zu ein Eingeständnis dass man selber nicht ALLES wissen kann, wie ich es gerade (und nicht zum ersten Mal) mache, würde das Diskussionsklima sicher wieder auf ein gesundes Level abkühlen.

hier sagen doch alle, wie man es anders besser macht. hast du doch selbst zitiert: echte konstanten statt symbolische verwenden, fehlerbehandlung mit exception statt bool return usw.
ich sags dir nochmal: c++ bietet auf sprachlicher ebene dinge, die man sich vorher mühsam zusammenpfriemeln mußte. es macht z. b. keine probleme, mit c an oop herangehen zu wollen. warum macht das aber niemand? weil c++ ne menge sachen von sich aus bereitstellt, die man mit c nicht so einfach haben kann.

[Shade Of Mine]

Mecnels schrieb:

Stell Dir vor es gäbe eine Funktion, die hieße
SetCooperativeLevel(). Toll wie der Bezeichner über sich selber spricht, oder? Weißt Du jetzt anhand des Namens, was die Funktion macht? Worauf Du bei der Parameterübergabe eventuell besondere Rücksicht nehmen solltest? In welchem Kontext und nach welchen zuvor stattgefundenen Initialisierungen Du die Funktion überhaupt aufrufen darfst, wenn Du schwere Systemfehler verhindern willst? Nein.

Doch. Dadurch dass ich die Domain kenne, sind die meisten dieser Sachen klar. Und dass die Funktion keine abhängigkeiten haben sollte, sollte klar sein.
idr kann ich eine Funktion immer aufrufen, wenn nicht, dann muss dass einen verdammt guten Grund haben.

Und wenn ich blödsinn mache, dann wirft die Funktion eine exception oder asserted oder dergleichen.

Das ist wohl der Unterschied zwischen deinem und meinem Code.

Darum kann es so etwas wie 'Deine Kommentare erzählen Romane und darum ist der Quellcode schlecht' gar nicht geben, eher können gar nicht genügend Kommentare dastehen, vor allem wenn andere mit dem Quellcode etwas anfangen sollen. Jeder Extra Kommentar ist da ein Fehler weniger, den man später debuggen muss.

Aber nicht jeder Kommentar ist sinnvoll.

//erstell ein Object
void CreateObject()

bringt doch nix, oder?

Nein, ich bin es nicht, der behauptet, alles besser zu wissen.

Kommt aber anders rüber. denn du gehst auf keine vorschläge und keine kritik ein sondern bringst immer nur andere punkte, die ich dir idr wiederlege. nun kommst du wieder mit neuen sachen - naja, irgendwann gehen sie dir aus

Das seid schon ihr mit 'nimm Konstanten statt defines', 'nimm explicit statt Elementfunktionen', 'nimm <vector> statt einen massgeschneiderten Container selber zu schreiben', 'vermeide um jeden Preis Schleifen', 'mach Fehlerbehandlung mit Exceptions anstatt mit bool-Rückgabewerten',

Da hätte ich gerne Gründe warum diese Vorschläge schlecht sind.
Alle diese Vorshläge sollten idr umgesetzt werden, weil sie keine nachteile, wohl aber vorteile bringen. (ausnahmen bestätigen die regel)

'verwende keine WINAPI und nie und nimmer MessageBox', UND UND UND

Hat niemand behauptet.

Das sind alles EURE Kommentare. Alles was ich mache, ist, einen optimierten Quellcode für ein funktionsfähiges Programm, das eh nur für meinen Enkel gedacht ist und das ich mir in zwei Tagen aus dem Ärmel geschüttelt habe - ohne Leistungsdruck und völlig aus freien Stücken - so gut es mir möglich ist, zu verteidigen.

Ne, du verteidigst nicht. Du bringst nämlich keine Argumente. Das ist schade

Wenn es nur etwas zusammen gehacktes ist, warum postest du dann hier? Hier geht es um guten Stil, um schöne wartbare programme und saubere strukturierung und nicht um einen hack.

Vielleicht könntet Ihr ja in Zukunft schreiben, wie IHR es anders gemacht hättet, und ab und zu ein Eingeständnis dass man selber nicht ALLES wissen kann, wie ich es gerade (und nicht zum ersten Mal) mache, würde das Diskussionsklima sicher wieder auf ein gesundes Level abkühlen.

Das _haben_ wir ja gemacht. Wir haben gesagt was wir anders machen würden.

Natürlich kann man nicht alles wissen, aber die meisten Punkte die ich gebracht habe, wissen die meisten hier (sogar viele neulinge).

Nichts für ungut, aber mich dünkt du lebst in einer C Welt. Damit stehst du hier in einer Diskussion um C++ (und teilweise auch Java) auf verlorenem Posten.

[JBeni]

Gregor schrieb:

2. Du nutzt zu wenig "final" für Variablen. "final" sollte bei lokalen Variablen, Parametern und Membervariablen so oft wie möglich genutzt werden, da hierdurch gewisse Fehler zur Comilezeit erkannt werden können, die sonst schwer zu finden wären. Bei Konstanten kommt bezüglich final außerdem noch ein Optimierungsaspekt hinzu.

Hm, ich bin schon viele Stunden vor dem Debugger gesessen, aber an ein Fehler der durch das Überschreiben einer Variable/etc entstanden ist mag ich mich wirklich nicht erinnern (weder bei meinem Code, noch bei dem von anderen Leuten).

Gregor schrieb:

3. Du machst zu wenig bzw. nahezu gar keine Checks auf Gültigkeit von Parametern, Zwischenergebnissen usw.! Schmeiß doch mal bezüglich Fehlern bei der Benutzung der Klasse entsprechende RuntimeExceptions und nutze für innere Checks assert. Du wirst den Vorteil davon nach den nächsten paar Bugs, die du produziert hast, zu schätzen gelernt haben. Ein Performanceargument gegen solche Checks zählt im Übrigen nur begrenzt: (Angeblich) kann die JVM überflüssige Checks zur Laufzeit eliminieren.

Das kann die VM? Das hätt ich echt nicht gedacht.
Aber du hast recht (ich kann mir auch gut vorstellen, wo du diese Tests sehen würdest), werd ich nachholen.

Gregor schrieb:

4. Irgendwo hast so eine if ... else if ... else if ... Orgie im Code. Das das nicht gerade ideal ist, sondern äußerst redundant, ist dir sicherlich klar. Überleg dir mal, wie du das eliminieren kannst. Wird vermutlich nicht ganz einfach sein, mir fällt auf anhieb zumindest nichts ein, aber irgendwas geht immer. Wenn du es wirklich restlos entfernen willst, wirst du wohl um eine Änderung des Designs im etwas größeren Rahmen nicht vorbeikommen. Mußt du selbst wissen, ob es dir das wert ist. Sooo schlimm ist diese Orgie noch nicht, aber es wäre sicherlich mal ne gute Übung, das restlos zu beseitigen, weil du dir dann in jedem Fall eine Designalternative für solche Fälle klar machst.

Es geht an dieser Stelle um das verschicken eines Events. In einem Event steht der Type, der bestimmt an welche Listener-Methode das Event geschickt wird. Ich wollte eine Automatisierung einbauen, damit nicht der Code (bzw, der Programmierer) entscheiden muss, wohin ein Event gehört. Ich muss mal darüber schlafen, vielleicht erträume ich mir eine bessere Lösung.

Gregor schrieb:

6. Bei Java 1.5 Code kann ich dir für jede überschriebene Methode @Override als Marker-Annotation empfehlen, um weitere Fehler zur Compilezeit zu finden.

Ich hab mich mit Annotations noch nicht beschäftigt (ich hab nur von anderen gehört, dass das nichts weltbewegendes sei), aber das kommt in die ToDo-Liste

Gregor schrieb:

7. In einem Code, in dem alle Bezeichner auf englisch sind, kommt ein Bezeichner "typ" sehr überraschend. ...ist sicher ein Versehen, oder?

Wenn ich englisch könnte...

Gregor schrieb:

...das Buch "Effektiv Java programmieren" von Joshua Bloch für dich vermutlich sehr lohnt.

Ich bin ja ein sehr grosser Anhänger der API, und hab noch nie gross anderes gelesen, wäre wohl mal ein guter Anfang

Danke für die Analyse Gregor
(dein Code wurd schon auseinandergerissen, ich könnte da nichts mehr beitragen, aber vielleicht kommt hier ja noch ein bisschen mehr Java :p )

[M.1946]

scrub schrieb:

hier sagen doch alle, wie man es anders besser macht.

Ja, sie wissen sicher, wie man es ANDERS machen könnte, aber ob das auch BESSER ist, steht in einem anderen Buch.

Sie schwärmen von 'Errungenschaften', die in einem halbwegs optimierten Programm keinen Platz haben:

Exceptions?
Alles kostet Zeit, so auch die Fehlerprüfung. Um die zusätzliche Sicherheit gewährleisten zu könnten, sind natürlich intern gewisse Abfragen nötig, die eben Zeit kosten. Und Zeit ist genau das, was man bei sehr vielen Anwendungen NICHT hat (bei Spielen schon gar nicht). Fast überall muss Zeit gespart und optimiert werden. Exceptions können vielleicht während der Entwicklungsphase eines größeren Projektes hilfreich sein, Fehler schneller zu finden, aber sicher NICHT in einem fertigen Produkt - dort nur in schwerwiegenden Ausnahmefällen.
(Und das Tolle an diesem Statement ist, dass ich es aus einem der Bücher zitiere, die ihr mir aufgeschwatzt habt, das ist also keine Besserwisserei meinerseits)
<vector> ohne Exceptions ist kein <vector>, sondern ein genau so schlecht implementierter Container, wie er jedem einfallen kann.

Aber hey, ihr seid doch alle smart, ihr kennt doch wahrscheinlich sicher noch jede Menge mehr Nachteile von exceptions als ich, aber die wenigen prinzipiellen, die mir bisher bekannt waren, haben mir schon immer gereicht, mir den Unsinn erst gar nicht anzufangen. Meine Meinung - keine Belehrung.

[otze]

simon.phoenix schrieb:

otze schrieb:

MaSTaH schrieb:

@Mecnels: Danke, so köstlich habe ich mich seit einiger Zeit nicht mehr amüsiert.

100% agree, der thread ist richtig gut

fast sogut wie der eine von vor ca nem halben jahr, der einen auf dicke hose gemacht hat, und dann von den mods aus dem forum vertrieben wurde

War nicht zufällig "ProjecktX" oder so :D?

ja genau der, der war cool

@mecnels

SetCooperativeLevel(). Toll wie der Bezeichner über sich selber spricht, oder? Weißt Du jetzt anhand des Namens, was die Funktion macht? Worauf Du bei der Parameterübergabe eventuell besondere Rücksicht nehmen solltest? In welchem Kontext und nach welchen zuvor stattgefundenen Initialisierungen Du die Funktion überhaupt aufrufen darfst, wenn Du schwere Systemfehler verhindern willst?

welche meinst du? es gibt genau 3. eine für DirectSound, eine für DirectDraw und eine für DirectInput.

aber zurück zum thema: natürlich braucht man für solch eine library ne doku. Immerhin ist sie für wildfremde menschen gedacht, die nicht an diesem projekt mitgearbeitet haben, und keine ahnung davon haben, was sich im hintergrund abspielt. ein weiterer punkt ist aber auch, dass Dx an dieser stelle soviele freiheiten wie möglich lasen muss, was sich natürlich auf die verständlichkeit des codes auswirkt. Je kleiner die komplexität einer klasse ist, desto weniger doku braucht man(deshalb sollte man auch modularisieren, allein wegen der verständlichkeit).

wenn eine keyboard klasse aber so aussähe:

class Keyboard{

    Keyboard(HWND applicationWindow,DWORD flags=DISCL_FOREGROUND, REFGUID guid=GUID_SysKeyboard);

    bool isKeyPressed(int virtualKeycode);

};

wer brächte dafür eine doku? normalerweise muss er nur das fenster seines programms angeben, und dann kanns auch schon losgehen. Der kalsse fehlts einfach an komplexität. natürlich könnte man noch dazu schreiben, ob und welche exceptions geworfen werden(was der fall ist), aber in dem fall reichen dann 2 zeilen über der Klasse.

[Shade Of Mine]

M.1946 schrieb:

Exceptions?
Alles kostet Zeit, so auch die Fehlerprüfung.

Nur schade, dass Exception weniger runtime overhead haben als die ganzen ifs zur fehlerabfrage.

Fast überall muss Zeit gespart und optimiert werden.

Kennst du die 90-10 Regel?

(Und das Tolle an diesem Statement ist, dass ich es aus einem der Bücher zitiere, die ihr mir aufgeschwatzt habt, das ist also keine Besserwisserei meinerseits)

Oh, welches denn?

<vector> ohne Exceptions ist kein <vector>, sondern ein genau so schlecht implementierter Container, wie er jedem einfallen kann.

Begründung?
Welche Exception soll vector denn werfen? Es _kann_ ja nicht fehlschlagen.

Meine Meinung - keine Belehrung.

Deine Meinung - keine Tatsachen.

[Gast]

Deine Schlussfolgerungen bzgl. Exceptions und anderer Dinge sind allesamt grundlegend falsch, weil sie sich auf diese Aussage stützen:

Fast überall muss Zeit gespart und optimiert werden.

Und die ist nicht korrekt. Tatsache ist: Nur an wenigen Stellen im Programm muss Zeit gespart und optimiert werden. Und überall woanders kann nahezu ohne Auswirkungen ohne schlechtes Gewissen tolle Features nutzen.
Und man rät auch nicht wild drauf los und benutzt deshalb keine Exceptions oder sonstwas, sondern man tut vielleicht mal eine Exception raus, wenn sich herausstellt, dass sie dort doch nicht so gut aufgehoben ist.

[Gregor]

JBeni schrieb:

Ich hab mich mit Annotations noch nicht beschäftigt (ich hab nur von anderen gehört, dass das nichts weltbewegendes sei), aber das kommt in die ToDo-Liste

Die Auswirkungen von Annotations sind noch nicht wirklich abzusehen. Für kleine Projekte sind sie sicherlich relativ uninteressant, da wird man nicht viel mehr als ein @Override nutzen. Für große Projekte könnten sie einem aber vollkommen neue Möglichkeiten beim Programmieren eröffnen. Sie könnten zu einem deutlich deklarativeren Programmierstil führen und das ist in der Java-Welt äußerst weltbewegend. Von den neuen Sprachfeatures aus Java 1.5 könnten die Annotations für größere Projekte also das absolut relevanteste Sprachfeature sein: Viel wichtiger als Generics. Annotations wirken sich nicht als syntaktischer Zucker aus, indem sie etwas Code reduzieren können (wozu sie allerdings auf Dauer sicherlich auch genutzt werden) oder ein paar Casts eliminieren oder so. Stattdessen wirken sie sich auf das Design im Großen aus. ...wobei ich hier nicht @Override oder @Deprecated oder so meine: Mach dich bezüglich Annotations mal schlau und überleg dir dann mal, wofür man die gerade in Verbindung mit Reflection nutzen könnte. Vielleicht kommst du ja da drauf, was ich meine.

http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html

[Gregor]

JBeni schrieb:

Hm, ich bin schon viele Stunden vor dem Debugger gesessen, aber an ein Fehler der durch das Überschreiben einer Variable/etc entstanden ist mag ich mich wirklich nicht erinnern (weder bei meinem Code, noch bei dem von anderen Leuten).

Das betrifft nicht nur das Überschreiben von Variablen. Es gibt auch andere Fehler, die dadurch frühzeitig erkannt werden. Zum Beispiel fällt es auf, wenn man vergißt, einer solchen Variablen/Konstanten in einem Konstruktor einen Wert zuzuweisen.

[groovemaster]

DrGreenthumb schrieb:

äh, wie war das... wenn man keine Ahung hat, ...

Begründung?

M.1946 schrieb:

Exceptions?
Alles kostet Zeit, so auch die Fehlerprüfung. Um die zusätzliche Sicherheit gewährleisten zu könnten, sind natürlich intern gewisse Abfragen nötig, die eben Zeit kosten. Und Zeit ist genau das, was man bei sehr vielen Anwendungen NICHT hat (bei Spielen schon gar nicht).

Seltsam, ich hab schon einige Spiele gesehen, die mit Exceptions arbeiten. Dann machen die das ja alle falsch.
Natürlich kosten Exceptions Zeit, das tut die Abfrage von Rückgabewerten aber auch. Der theoretische Unterschied ist jedenfalls nicht vorhanden. Im Gegenteil, Exceptions tendieren zu einem besseren Laufzeitverhalten, weil der Compiler nunmal besser optimieren kann als du. Leider setzen das Compiler noch nicht wirklich gut um (ich kenn zumindest keinen).
Und niemand sagt, dass du Exceptions in zeitkritischen Situationen einsetzen musst. Aber gerade in Initialisierungsphasen sind sie sinnvoll, und dort ist Performance nur sekundär.

[DrGreenthumb]

Mecnels schrieb:

Ist Euch eigentlich schon einmal aufgefallen, dass nicht ich die ganze Zeit Euch einreden will, was IHR in Euren Codes besser machen solltet, sondern genau umgekehrt

nuja, da gehen schonmal die Gemüter hoch, wenn man sich öfter mit solchen "int i,j,k,l,m;"-Quelltexten rumschlagen muss und dann ist da auf einmal jemand, der das auch nocht vehement verteidigt, worüber man sich selbst so oft ärgert.
Wir versuchen ja nur die Welt zu verbessern

groovemaster schrieb:

DrGreenthumb schrieb:

äh, wie war das... wenn man keine Ahung hat, ...

Begründung?

/usr/src/linux/Documentation
Aber dazu sag ich nichts mehr, ein Flame pro Thread reicht