|
Size: 3648
Comment:
|
Size: 4742
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Lesen Sie sich diese Seite bitte vor der Bearbeitung und Abgabe des ersten Übungsblattes sorgfältig und vollständig durch. Die Regeln gelten für alle Übungsblätter sowie für das Abschlussprojekt dieser Lehrveranstaltung. Unwissenheit darüber schützt nicht vor späteren Konsequenzen. | #acl Hannah Bast:read,write Claudius Korzen:read,write All:read = Die 10 Gebote (gültig für ALLE Übungsblätter und das Abschlussprojekt) = |
| Line 3: | Line 4: |
| = Die 10 Gebote (gültig für ALLE Übungsblätter und das Abschlussprojekt) = '''1. Erlaubte Konstrukte''': Im Laufe der Veranstaltung steigen sowohl die Anforderungen, als auch die Menge der Konstrukte, die Sie für Ihre Programme benutzen dürfen. Als Faustregel gilt: Sie dürfen grundsätzlich alles benutzen, was bereits dran war, aber nichts darüber hinaus. Wenn bei einem Übungsblatt eine Anforderung dazukommt, gilt diese auch für alle zukünftigen Übungsblätter. |
Lesen Sie sich diese Regeln bitte '''vor''' der Bearbeitung und Abgabe des ersten Übungsblattes sorgfältig und vollständig durch. Die Regeln gelten für '''alle''' Übungsblätter sowie für das Abschlussprojekt dieser Lehrveranstaltung. Unwissenheit darüber schützt nicht vor späteren Konsequenzen. <<BR>> <<BR>> |
| Line 6: | Line 8: |
| '''2. TIP Datei''': Die Designvorlage (TIP Datei, falls vorhanden) ist nicht verbindlich. Sie beruht aber auf vielErfahrung, von daher sollten Sie sich dreimal ̈uberlegen, wenn Sie davon abweichen. | '''1. Erlaubte Konstrukte''' Im Laufe der Veranstaltung steigen sowohl die Anforderungen, als auch die Menge der Konstrukte, die Sie für Ihre Programme benutzen dürfen. Als Faustregel gilt: Sie dürfen grundsätzlich alles benutzen, was bereits in der Vorlesung benutzt wurde, aber nichts darüber hinaus. Wenn bei einem Übungsblatt eine Anforderung dazukommt, gilt diese auch für alle zukünftigen Übungsblätter. |
| Line 8: | Line 10: |
| '''3. Code-Modularität''': Schreiben Sie Ihren Code modular. Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder im Code mehrfach verwendet wird, gehört er in eine eigene Funktion. | '''2. Abgabe''' Für die Korrektur maßgeblich ist die letzte Version Ihres Codes in unserem SVN vor dem Abgabetermin. Sie können davor so viele Zwischenversionen (zum Beispiel zu Sicherungszwecken) in unser SVN hochladen, wie Sie möchten. Verspätete Abgaben oder Abgaben per Email werden nicht akzeptiert, fangen Sie also rechtzeitig mit der Bearbeitung an. |
| Line 10: | Line 12: |
| '''4. Dokumentation''': Dokumentieren Sie Ihren Code. Jedes Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, sollte erklärt werden. Jede nicht-triviale Funktion sollte erklärt werden. Ihre Erklärungen sollten kurz und aussagekräftig sein. Manchmal ist ein Beispiel nützlicher (und kürzer) als eine abstrakte Erklärung. | '''3. Makefile''' Zu der Abgabe jedes Übungsblattes gehört ein ''Makefile'' mit den Targets ''compile'', ''checkstyle'', ''test'' und ''clean'', wie in Vorlesung 1 erklärt und vorgeführt und im SVN unter ''public/vorlesung-01/'' zur Verfügung gestellt. Unser Continuous Build System (Jenkins) prüft dann automatisch nach jedem Commit, ob diese Targets fehlerfrei durchlaufen. Sie können einen solchen Durchlauf auch manuell anstoßen. |
| Line 12: | Line 14: |
| '''5. Tests''': Schreiben Sie für jede nicht-triviale Funktion einen Unit Test. Jeder Unit Test sollte mindestens ein nicht-triviales Beispiel überprüfen. Wenn es kritische Grenzfälle gibt, die sich durch wenig Aufwand leicht nachprüfen lassen (z.B. Verhalten einer Methode bei leerem Eingabefeld), sollten Sie das ebenfalls tun. | '''4. Hochladen''' Laden Sie Ihren Code vollständig in unser SVN hoch. Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, wie zum Beispiel ''.o'' Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht mit hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum. |
| Line 14: | Line 16: |
| '''6. Hochladen''': Laden Sie Ihren Code vollständig in unser SVN hoch, inklusive Makefile. Andere Dateien (insbesondere .o Dateien, die wir ab der 2. Vorlesung kennenlernen) dürfen '''nicht''' mit hochgeladen werden, sonst gibt es Karma-Minuspunkte oder Zwangs-Exmatrikulation. | '''5. Kompilieren''' Das ''compile'' Target muss auf Jenkins grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code '''nicht''' korrigiert und es gibt 0 Punkte. Grund dafür ist, dass nicht kompilierbarer Code sehr schwer zu durchschauen sein kann und dies unzumutbar viel Arbeit für die Tutor:innen wäre. Fragen Sie bei Problemen bitte rechtzeitg im Forum, siehe Punkt 9. Zwischenversionen (siehe Punkt 2) müssen nicht fehlerfrei durchlaufen. |
| Line 16: | Line 18: |
| '''7. Jenkins''': Die finale Version von Ihrem Code muss fehlerfrei auf Jenkins durchlaufen. Zwischenversionen TODO müssen nicht auf Jenkins durchlaufen. | '''6. Tests''': Schreiben Sie für jede nicht-triviale Funktion einen Unit Test. Jeder Unit Test sollte mindestens ein nicht-triviales Beispiel überprüfen. Wenn es kritische Grenzfälle gibt, die sich durch wenig Aufwand leicht nachprüfen lassen (z.B. Verhalten einer Methode bei leerem Eingabefeld), sollten Sie das ebenfalls tun. ''Wichtig: wenn ein Test korrekt ist, aber fehlschlägt, weil die Funktion fehlerhaft ist, kriegen Sie trotzdem volle Punktzahl für diesen Test. Sie sollen den Test *nicht* an das fehlerhafte Ergebnis anpassen.'' |
| Line 18: | Line 20: |
| '''8. Kompilieren''': Code, der auf Jenkins nicht kompiliert (''make compile'') oder der keine Tests hat, wird '''nicht''' korrigiert (= 0 Punkte), weil das unzumutbar viel Arbeit für unsere Tutoren wäre. | '''7. Checkstyle''' Ihr Code muss frei von ''checkstyle'' Fehlern sein. |
| Line 20: | Line 22: |
| '''9. Forum''': Wenn Sie ein Problem bei der Implementierung haben, suchen Sie ein paar Minuten (auf Google oder auch auf dem Forum, da wurden sehr viele Fragen schon mal gestellt) nach dem Fehler. Wenn Sie nicht fündig werden, fragen Sie gerne auf dem Forum, da wird Ihnen in der Regel schnell geholfen. Eine Anleitung für das richtige Fragen auf dem Forum findet sich auf dem Wiki (Stichwort: konkret fragen mit Fehlermeldung + Zeilennummer + relevantem Code, und nicht nur "''Mein Code geht nicht''", sonst kann Ihnen keiner helfen). | '''8. Lesbarkeit''' Schreiben Sie modularen und verständlichen Code. Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, gehört er in eine eigene Funktion. Dokumentieren Sie Ihren Code. Jedes Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, sollte erklärt werden. Die Erklärung sollte kurz und aussagekräftig sein. Manchmal ist ein Beispiel nützlicher (und kürzer) als eine abstrakte Erklärung. |
| Line 22: | Line 25: |
| '''10. Zusammenarbeit''': Sie können gerne zusammen ̈uber die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu 100% selbst geschrieben werden. Auch das teilweise ̈Ubernehmen gilt als Täuschungsversuch, mit den entsprechenden Konsequenzen. Wir müssen das so deutlich sagen, weil es in der Vergangenheit immer wieder vorgekommen ist. Man lernt nichts, wenn man Code bzw. Lösungen von anderen ̈ubernimmt und es ist auch einfach unfair gegen ̈uber dem Großteil der Teilnehmer, die sich ehrlich Mühe geben. | '''9. Forum''' Wenn Sie ein Problem bei der Implementierung haben, suchen Sie ein paar Minuten (auf Google oder auch auf dem Forum, da wurden sehr viele Fragen schon mal gestellt) nach dem Fehler. Wenn Sie nicht fündig werden, fragen Sie gerne auf dem Forum, da wird Ihnen in der Regel schnell geholfen. Hier ist unsere [[Manuals/AskingOnAForum|Anleitung für das richtige Fragen auf dem Forum]]. {{{ #!html <p style="color: darkred"><b>10. Zusammenarbeit</b> Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu <b>100% selbst</b> geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer anderen Person, der Musterlösung aus einer vergangenen Vorlesung oder aus dem Internet, gilt als Täuschungsversuch, mit den entsprechenden Konsequenzen. Wir müssen das so deutlich sagen, weil es in der Vergangenheit immer wieder vorgekommen ist. Man lernt nichts, wenn man Code bzw. Lösungen von anderen übernimmt und es ist unfair gegenüber dem Großteil der Teilnehmer:innen, die sich ehrlich Mühe geben. }}} |
Die 10 Gebote (gültig für ALLE Übungsblätter und das Abschlussprojekt)
Lesen Sie sich diese Regeln bitte vor der Bearbeitung und Abgabe des ersten Übungsblattes sorgfältig und vollständig durch. Die Regeln gelten für alle Übungsblätter sowie für das Abschlussprojekt dieser Lehrveranstaltung. Unwissenheit darüber schützt nicht vor späteren Konsequenzen.
1. Erlaubte Konstrukte Im Laufe der Veranstaltung steigen sowohl die Anforderungen, als auch die Menge der Konstrukte, die Sie für Ihre Programme benutzen dürfen. Als Faustregel gilt: Sie dürfen grundsätzlich alles benutzen, was bereits in der Vorlesung benutzt wurde, aber nichts darüber hinaus. Wenn bei einem Übungsblatt eine Anforderung dazukommt, gilt diese auch für alle zukünftigen Übungsblätter.
2. Abgabe Für die Korrektur maßgeblich ist die letzte Version Ihres Codes in unserem SVN vor dem Abgabetermin. Sie können davor so viele Zwischenversionen (zum Beispiel zu Sicherungszwecken) in unser SVN hochladen, wie Sie möchten. Verspätete Abgaben oder Abgaben per Email werden nicht akzeptiert, fangen Sie also rechtzeitig mit der Bearbeitung an.
3. Makefile Zu der Abgabe jedes Übungsblattes gehört ein Makefile mit den Targets compile, checkstyle, test und clean, wie in Vorlesung 1 erklärt und vorgeführt und im SVN unter public/vorlesung-01/ zur Verfügung gestellt. Unser Continuous Build System (Jenkins) prüft dann automatisch nach jedem Commit, ob diese Targets fehlerfrei durchlaufen. Sie können einen solchen Durchlauf auch manuell anstoßen.
4. Hochladen Laden Sie Ihren Code vollständig in unser SVN hoch. Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, wie zum Beispiel .o Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht mit hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum.
5. Kompilieren Das compile Target muss auf Jenkins grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt 0 Punkte. Grund dafür ist, dass nicht kompilierbarer Code sehr schwer zu durchschauen sein kann und dies unzumutbar viel Arbeit für die Tutor:innen wäre. Fragen Sie bei Problemen bitte rechtzeitg im Forum, siehe Punkt 9. Zwischenversionen (siehe Punkt 2) müssen nicht fehlerfrei durchlaufen.
6. Tests: Schreiben Sie für jede nicht-triviale Funktion einen Unit Test. Jeder Unit Test sollte mindestens ein nicht-triviales Beispiel überprüfen. Wenn es kritische Grenzfälle gibt, die sich durch wenig Aufwand leicht nachprüfen lassen (z.B. Verhalten einer Methode bei leerem Eingabefeld), sollten Sie das ebenfalls tun. Wichtig: wenn ein Test korrekt ist, aber fehlschlägt, weil die Funktion fehlerhaft ist, kriegen Sie trotzdem volle Punktzahl für diesen Test. Sie sollen den Test *nicht* an das fehlerhafte Ergebnis anpassen.
7. Checkstyle Ihr Code muss frei von checkstyle Fehlern sein.
8. Lesbarkeit Schreiben Sie modularen und verständlichen Code. Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, gehört er in eine eigene Funktion. Dokumentieren Sie Ihren Code. Jedes Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, sollte erklärt werden. Die Erklärung sollte kurz und aussagekräftig sein. Manchmal ist ein Beispiel nützlicher (und kürzer) als eine abstrakte Erklärung.
9. Forum Wenn Sie ein Problem bei der Implementierung haben, suchen Sie ein paar Minuten (auf Google oder auch auf dem Forum, da wurden sehr viele Fragen schon mal gestellt) nach dem Fehler. Wenn Sie nicht fündig werden, fragen Sie gerne auf dem Forum, da wird Ihnen in der Regel schnell geholfen. Hier ist unsere Anleitung für das richtige Fragen auf dem Forum.
10. Zusammenarbeit Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu 100% selbst geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer anderen Person, der Musterlösung aus einer vergangenen Vorlesung oder aus dem Internet, gilt als Täuschungsversuch, mit den entsprechenden Konsequenzen. Wir müssen das so deutlich sagen, weil es in der Vergangenheit immer wieder vorgekommen ist. Man lernt nichts, wenn man Code bzw. Lösungen von anderen übernimmt und es ist unfair gegenüber dem Großteil der Teilnehmer:innen, die sich ehrlich Mühe geben.