static Variablen in Methoden nicht erlaubt?
-
Dass C++ ziemlich komplex ist bestreite ich nicht, aber man muss nicht jedes Detail
wissen am Anfang, genau wie ich wunderbar Java programmieren kann ohne alles zu
wissen, aber ich erfahre ja hin und wieder was neues von euchDie Generics in Java sind aber keine Templates im C++ Sinne, zwischen den Generics
in Java 1.5 und den Templates in C++ liegen Welten.
-
Ich habe da auch eher Optimizers Größenvorstellungen. Wenn ich Zeilen angeben müßte, dann würde ich sagen:
kleine Klasse: bis 30 Codezeilen
mittlere Klasse: 30 bis 150 Codezeilen
große Klasse: 150 bis 400 Codezeilen
abnormal riesiege Klasse: mehr als 400 CodezeilenWenn man Kommentare und Leerzeilen mitrechnet, dann würden sich diese Zahlen wohl nochmal verdoppeln. Bei einer API würden sie sich sicherlich sogar verdreifachen bis verfünffachen, weil eine API relativ ausgiebig dokumentiert sein muss.
-
Optimizer schrieb:
Die Kommentare hab ich rausgenommen
Wo braucht so eine Klasse Kommentare? Vorallem: was steht in den Kommentaren?
-
Ist jetzt natürlich ein sehr triviales Beispiel, is halt für unser Praktikum an der FH, da muss ja alles perfekt sein.
Außerdem, wenn das ganze Projekt ausführlich dokumentiert ist, dann gibt es keinen Grund, die eine Klasse nicht zu dokumentieren. Zumal die Klasse von mir selber gar nicht benutzt wird, sondern von anderen.
Vielleicht kommen auch noch Erweiterungen hinzu, das wissen wir noch nicht genau. Ziel sollte es für jede Klasse sein, dass sich keiner den Quellcode anschauen muss.package battleship; /** Die Klasse Point repräsentiert Koordinaten auf dem * Spielfeld. Diese bestehen aus einer x- und einer y- * Komponente. Die Datenelemente sind innerhalb des * Package öffentlich abrufbar, aber unveränderbar. Von * dieser Klasse kann <i>nicht</i> mehr abgeleitet * werden. * * @author Michael Firbach * @version 1.00 */ final class Point { /** Konstruktor für ein Point-Objekt. * @param x Die x-Komponente der Koordinate. * @param y Die y-Komponente der Koordinate. */ Point(int x, int y) { this.x = x; this.y = y; } /** Die x-Komponente dieser Koordinate. * <i>Unveränderlich</i>. */ final int x; /** Die y-Komponente dieser Koordinate. * <i>Unveränderlich</i>. */ final int y; }
-
Wenns für die Schule ist, ist alles erlaubt
Aber ernsthaft würde ich sowas nie machen. Da schreibe ich ja länger an den Kommentaren als an dem Sourcecode...
-
Ja, das ist natürlich ein sehr extremes Beispiel, weil die Klasse so klein ist.
Allerdings, wenn du einen Blick in den Code der Java-API wirfst, stellst du fest, dass meistens gut 2/3 Kommentierung ist. Der Hintergedanke dabei ist natürlich, dass man keine seperate Dokumentation mehr schreiben muss, so wie die MSDN.
-
Optimizer schrieb:
Allerdings, wenn du einen Blick in den Code der Java-API wirfst, stellst du fest, dass meistens gut 2/3 Kommentierung ist. Der Hintergedanke dabei ist natürlich, dass man keine seperate Dokumentation mehr schreiben muss, so wie die MSDN.
Wobei ich persönlich die MSDN mies finde, aber immer noch besser als die Java Doku
Ne, im ernst: für eine Library sind viele Kommentare OK - wobei ich damit nicht den Quellcode zumüllen würde.
In C++ geht das schön, da man das Interface woanders stehen hat, als die Implementierung. Da stört es IMHO nicht so. Aber wenn ich die Kommentare quasi direkt im Quellcode habe... naja, ich finds halt ungut.
-
Ich sag dir jetzt lieber nicht, was ich von Header-Dateien halte.
-
Optimizer schrieb:
Ich sag dir jetzt lieber nicht, was ich von Header-Dateien halte.
Ich mag sie auch nicht - aber hier haben sie halt dann doch einen vorteil
Und dass das Übersetzungseinheiten-System von C++ mies ist - weiss ja jeder.