Es gibt keine universell "richtige" Verzeichnisstruktur - aber zumindest gibt es ein paar Hinweise deren Einhaltung hilft die Übersicht zu behalten:
Trennt Quellcode und Dokumentation:
Neben dem Quellcode noch zahlreiche andere Dokumente im Verzeichnis liegen zu haben erschwert nachher das Entwickeln und das "Packagen" von .jar Files.
Trennt Testklassen vom Produktivcode:
Wenn damit begonnen wird die Klassen mit JUnit zu testen, wird es extrem schwer, den Überblick zu behalten, was zum Produkt-Code gehört und was nicht. Selbst mit entsprechende Namenskonvention werden die Verzeichnislistings irgendwann unübersichtlich lang. Besser man trennt den Source-Tree in zwei Verzeichnis auf: "src" für den Produktivcode und "test" für alle JUnit Tests.
Separiert Ressourcen (z.B. .properties-Dateien und Bilder) vom Quellcode:
Oft werden Bilder oder Properties-Dateien per Classloader geladen. Ähnlich zu oben ist auch hier eine deutliche Trennung von Quellcode und Ressourcen hilfreich. Zwar kann man diese Probleme umgehen, indem man Unterverzeichnisse anlegt, aber auch das wird auf Dauer unübersichtlich. Eclipse bietet bequemerweise die Möglichkeit mehrere Source-Verzeichnise anzulegen. Eines davon kann extra für die Ressourcen reserviert werden.
Das gleiche gilt für Ressourcen, die für Tests benötigt werden. Zum Beispiel braucht ihr diverse Properties-Dateien um Einstellungen zu speichern, das Logging-System zu konfigueren und, und, und. Auch hierfür sollte ein extra Verzeichnis erstellt werden.
Package-Strukturen mit möglichst wenig Überschneidungen
Wenn in Kleingruppen gearbeitet wird, sollte klar sein, wer woran arbeitet. Unterteilt Packages in spezifische Bereiche. Wird getrennt voneinander entwickelt, kann jeder in seinem Package entwickeln, überarbeiten, usw. ohne andere zu stören.
Alle generierten Dateien in ein separates Verzeichnis
Alles was generiert wird - egal ob z.B. per RMIC erzeugter Quellcode, Test-Reports oder Javadocs etc. werden am Besten in ein separates Verzeichnis gelegt. Hierfür bietet sich die Bezeichnung "build" an. In diesem Verzeichnis wird dann weiter organisiert - also zum Beispiel "test-reports", "javadoc", "src", etc.
Eclipse bietet die Möglichkeit, "Code-Formatter" Einstellungen zu ex- und importieren. Legt einen Standard fest und speichert die Datei innerhalb eures Projekts. Sind die Einstellungen nicht mehr zufriedenstellend, werden diese geändert, eingecheckt und stehen ab dann wieder jedem zur Verfügung.
Gleiches gilt für Compiler-Einstellungen, Checkstyle-Settings und vieles mehr. Im Menü Window -> Preferences -> Java -> Code Style -> Code Formatter oben befindet sich ein Export-Button. Für andere Einstellungen existieren ähnliche Buttons in den jeweiligen Menüs.
Sollte es Dateien geben, die persönliche Einstellungen (zum Beispiel arbeitsplatzabhängige Pfade etc.) enthalten, lagert diese in eine extra Datei mit (zum Beispiel) dem Prefix "local." aus. Diese Dateien dann noch in der Datei ".cvsignore" eintragen, so dass sie nicht mehr in das CVS hochgeladen werden.
Obwohl CVS binäre Dateien (z.B. jars, kompilierte Klassen oder Bilder) nicht praxisgerecht auf Änderungen untersuchen kann, sollten diese dennoch eingecheckt werden, bevor sie umständlich per Mail herumgeschickt oder auf einem FTP-Server zum Download bereit gelegt werden. Für benötigte Bibliotheken sollte z.B. ein Verzeichnis "lib" im Projekt angelegt werden, das alle notwendigen jars beinhaltet - eventuell auch mit Quellcodes.
Was auf jeden Fall nicht ins CVS repository gehört sind sogenannte "derived Files"- also Dateien, die aus anderen erzeugt wurden. Beispiele hierfür sind javaDocs, Class-Dateien oder Test-Reports. Die lassen sich lokal schnell neu erzeugen und müssen somit nicht mit eingecheckt werden
Vor dem Bearbeiten eines Dokuments per "update" die neueste Version des Dokuments aus-checken (hilfreich).
Vor dem Ein-checken überprüfen, ob Änderungen im CVS vorgenommen wurden (hilfreich)
Vor dem Ein-checken dürfen keine Compile-Fehler existieren (notwendig!)
Vor dem Ein-checken muss die Testsuite durchlaufen und eventuelle Fehlschläge behoben werden (wünschenswert)
Wenig ist nervenaufreibender, als kaputter Code, den man selbst nicht verursacht hat und dessen Reparatur deshalb beliebig langwierig ausfallen kann.
Viel Erfolg beim Entwickeln!