4437
Comment:
|
5543
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
#acl Hannah Bast:read,write Niklas Schnelle:read,write All:-read Lesen Sie 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 dieser Lehrveranstaltung. Unwissenheit darüber schützt nicht vor späteren Konsequenzen. |
|
Line 6: | Line 10: |
1. Wir empfehlen als Programmiersprache ''Python''. Erstens wird auch in der Vorlesung Python benutzt und zweitens stehen die Vorlagen und Tests für die Programmieraufgaben in Python zur Verfügung. Die Aufgaben können auch in Java oder C++ bearbeitet werden, sie sind dann aber (je nach Aufgabe und Vorkenntnissen deutlich) mehr Arbeit. Für Programmieranfänger raten wir ausdrücklich davon ab! | '''1. Programmiersprache''' Wir empfehlen als Programmiersprache ''Python''. Erstens wird auch in der Vorlesung Python benutzt, zweitens stehen die Vorlagen und Tests für die Programmieraufgaben in Python zur Verfügungund drittens erlaubt die einfache Handhabbarkeit dieser Sprache die Konzentration auf das eigentliche Thema dieser Lehrveranstaltung: Algorithmen und Datenstrukturen. Die Aufgaben können auch in '''Java''' oder '''C++''' bearbeitet werden, sie sind dann aber (je nach Aufgabe und Vorkenntnissen deutlich) mehr Arbeit. Für Programmieranfänger raten wir ausdrücklich davon ab! Andere Programmiersprachen als die drei genannten sind nicht gestattet. |
Line 8: | Line 12: |
2. 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 hochgeladen, wie Sie möchten. Verspätete Abgaben oder Abgaben per Email werden nicht akzeptiert, fangen Sie also rechtzeitig mit der Bearbeitung an. | '''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 hochgeladen, 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 14: |
3. Zu jeder Abgabe gehört ein ''Makefile'' (für Python und C++) bzw. eine ''build.xml'' für Java mit den targets ''compile'', ''checkstyle'', ''test'' und ''clean'', wie in Vorlesung 1 erklärt und vorgeführt. 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. | '''3. Makefile''' Zu der Abgabe jedes Übungsblattes mit einer Programmieraufgabe gehört ein ''Makefile'' (für Python und C++) bzw. eine ''build.xml'' (für Java) 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 16: |
4. Achten Sie darauf, dass sie keine unnötigen Dateien hochladen, zum Beispiel ''.pyc'' oder ''.o'' oder ''.class'' Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum. | '''4. Unnötige Dateien''' Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, zum Beispiel ''.pyc'' oder ''.o'' oder ''.class'' Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum. |
Line 14: | Line 18: |
5. Das ''compile'' target muss grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt keine 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. | '''5. Kompilieren''' Das ''compile'' target muss grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt keine 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. |
Line 16: | Line 20: |
6. Wenn Tests vorgegeben sind, dürfen diese nicht verändert werden. Wird der Inhalt eines Tests geändert, gibt es für diesen Teil des Programms keine Punkte. Ausnahme sind kleinere syntaktische Änderungen aus guten Grund oder wenn der Fehler bei uns liegt. Schlägt ein Test fehl, gibt es für diesen Teil des Programms maximal 50% der Punkte. Sie können unsere Tests gerne um zusätzliche Testfälle erweitern, das ist aber kein Muss. | '''6. Tests''' Wenn Tests vorgegeben sind, dürfen diese nicht verändert werden. Wird der Inhalt eines Tests geändert, gibt es für diesen Teil des Programms keine Punkte. Ausnahme sind kleinere syntaktische Änderungen aus guten Grund oder wenn der Fehler bei uns liegt. Schlägt ein Test fehl, gibt es für diesen Teil des Programms maximal 50% der Punkte. Sie können unsere Tests gerne um zusätzliche Testfälle erweitern, das ist aber kein Muss. |
Line 18: | Line 22: |
7. Ihr Code sollte frei von ''checkstyle'' Fehler sein. Mit Checkstyle-Fehlern riskieren Sie einen Punktabzug bis zu 10% der Gesamtpunktzahl für eine Programmieraufgabe, bei sehr vielen Fehlern bis zu 20%. | '''7. Checkstyle''' Ihr Code sollte frei von ''checkstyle'' Fehler sein. Mit Checkstyle-Fehlern riskieren Sie einen Punktabzug bis zu 10% der Gesamtpunktzahl für eine Programmieraufgabe, bei sehr vielen Fehlern bis zu 20%. |
Line 20: | Line 24: |
8. 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. 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. Für unverständlichen Code riskieren Sie ebenfalls einen Punktabzug von bis zu 20%. | '''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. 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. Für unverständlichen Code riskieren Sie ebenfalls einen Punktabzug von bis zu 20%. |
Line 22: | Line 26: |
9. 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). | '''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). |
Line 25: | Line 29: |
!#html <p style="color: darkred">10. Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu <b>100% selber</b> geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer andere 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. |
#!html <p style="color: darkred"><b>10. Plagiate</b> Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu <b>100% selber</b> geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer andere 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. |
Line 31: | Line 35: |
Punkt 10 von der Liste oben gilt sinngemäß. | 1. Für die Abgaben zu den theoretischen Aufgaben gilt Punkt 10 von der Liste oben sinngemäß. 2. Für die Punktevergabe gelten folgende Leitlinien. Für eine sinnvolle Grundidee bzw. einen sinnvollen Ansatz gibt es 40% der Punkte. Für die ordentliche Ausarbeitung gibt es 60% der Punkte. |
Lesen Sie 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 dieser Lehrveranstaltung. Unwissenheit darüber schützt nicht vor späteren Konsequenzen.
Regeln für die Programmieraufgaben
1. Programmiersprache Wir empfehlen als Programmiersprache Python. Erstens wird auch in der Vorlesung Python benutzt, zweitens stehen die Vorlagen und Tests für die Programmieraufgaben in Python zur Verfügungund drittens erlaubt die einfache Handhabbarkeit dieser Sprache die Konzentration auf das eigentliche Thema dieser Lehrveranstaltung: Algorithmen und Datenstrukturen. Die Aufgaben können auch in Java oder C++ bearbeitet werden, sie sind dann aber (je nach Aufgabe und Vorkenntnissen deutlich) mehr Arbeit. Für Programmieranfänger raten wir ausdrücklich davon ab! Andere Programmiersprachen als die drei genannten sind nicht gestattet.
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 hochgeladen, 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 mit einer Programmieraufgabe gehört ein Makefile (für Python und C++) bzw. eine build.xml (für Java) 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. Unnötige Dateien Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, zum Beispiel .pyc oder .o oder .class Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum.
5. Kompilieren Das compile target muss grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt keine 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.
6. Tests Wenn Tests vorgegeben sind, dürfen diese nicht verändert werden. Wird der Inhalt eines Tests geändert, gibt es für diesen Teil des Programms keine Punkte. Ausnahme sind kleinere syntaktische Änderungen aus guten Grund oder wenn der Fehler bei uns liegt. Schlägt ein Test fehl, gibt es für diesen Teil des Programms maximal 50% der Punkte. Sie können unsere Tests gerne um zusätzliche Testfälle erweitern, das ist aber kein Muss.
7. Checkstyle Ihr Code sollte frei von checkstyle Fehler sein. Mit Checkstyle-Fehlern riskieren Sie einen Punktabzug bis zu 10% der Gesamtpunktzahl für eine Programmieraufgabe, bei sehr vielen Fehlern bis zu 20%.
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. 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. Für unverständlichen Code riskieren Sie ebenfalls einen Punktabzug von bis zu 20%.
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).
10. Plagiate Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu 100% selber geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer andere 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.
Regeln für die theoretischen Aufgaben
1. Für die Abgaben zu den theoretischen Aufgaben gilt Punkt 10 von der Liste oben sinngemäß.
2. Für die Punktevergabe gelten folgende Leitlinien. Für eine sinnvolle Grundidee bzw. einen sinnvollen Ansatz gibt es 40% der Punkte. Für die ordentliche Ausarbeitung gibt es 60% der Punkte.