Οδηγίες για τις εργασίες
Αντιγραφές
Ο κανόνας είναι απλός και αυτονόητος: κάθε γραμμή κώδικα που παραδίδετε πρέπει ναι είναι 100% γραμμένη από εσάς. Είστε ελεύθεροι να συμβουλευτείτε οποιαδήποτε πηγή θέλετε (βιβλία, web sites, φίλους, φροντιστήρια, κλπ) για τις τεχνικές και τους αλγορίθμους που θα χρησιμοποιήσετε, αλλά τον κώδικα τον γράφετε εσείς και μόνον εσείς.
Τα προγράμματά σας θα ελεγχθούν αυτόματα για ομοιότητες και αντιγραφές από γνωστές πηγές, χρησιμοποιώντας κατάλληλο λογισμικό. Αν υπάρχουν ομοιότητες, μηδενίζεστε αυτόματα (πιθανότατα σε ολόκληρη την εργασία, και σε ακραίες περιπτώσεις σε ολόκληρο το μάθημα). Δεν δίνονται λεπτομέρειες για το πώς και το γιατί, και δε θα έχετε τη δυνατότητα να μιλήσετε με τον καθηγητή ή τους βοηθούς του μαθήματος για περιπτώσεις αντιγραφής.
Επίσης, στο τέλος της χρονιάς, θα υπάρξει κοινή προσωπική εξέταση για εργαστήριο και εργασίες.
Χρήση του git
Η παράδοση όλων των εργασιών γίνεται μέσω της πλατφόρμας github. Μπορείτε να χρησιμοποιήσετε το υπάρχον github account σας, αν έχετε ήδη, διαφορετικά δημιουργήστε ένα. Το “Free” plan (δωρεάν) είναι αρκετό για τις ανάγκες των εργασιών. Ως φοιτητής, έχετε δικαίωμα να μετατρέψετε το account σας σε “Pro” επίσης δωρεάν ακολουθώντας τις παρακάτω οδηγίες (δεν είναι όμως απαραίτητο κάτι τέτοιο για τις εργασίες).
Σε κάθε εργασία σας δίνεται ένα link εγγραφής που δημιουργεί ένα προσωπικό private git repository με υλικό για την εργασία, όπως ακριβώς και στα εργαστήρια. Το repository μπορείτε να το χρησιμοποιείτε σε ολόκληρη τη διάρκεια της εργασίας. Σας συστήνεται να κάνετε τακτικά push τον κώδικα στο repository, το οποίο είναι χρήσιμο για backup αλλά και μεταφορά του κώδικα σε άλλους υπολογιστές.
(Μόνο αν δεν έχετε παραδώσει κανένα εργαστήριο, την πρώτη φορά που θα επισκεφτείτε το link θα σας ζητηθεί να αντιστοιχίσετε το github account με το sdiXXXXXXX account σας. Βεβαιωθείτε ότι επιλέξατε το σωστό!)
Μόλις παρέλθει η προθεσμία της εργασίας, η έκδοση που υπάρχει εκείνη τη στιγμή στο repository θεωρείται τελική και είναι αυτή που βαθμολογείται. Βεβαιωθείτε ότι έχετε κάνει push την τελική έκδοση! Το repository θα εξακολουθεί να λειτουργεί και μετά την προθεσμία (τουλάχιστον μέχρι το τέλος του εξαμήνου), αλλά επιπλέον αλλαγές απλά αγνοούνται. Αν θέλετε να κρατήσετε τον κώδικα μετά το τέλος του εξαμήνου μπορείτε να κάνετε fork το repository στον προσωπικό σας λογαριασμό.
Automatic compilation από το github
Στα repositories που σας δίνονται, έχει ρυθμιστεί να γίνεται αυτόματα από
το github σε κάθε push ένα δοκιμαστικό compilation (τρέχοντας το make
στο root του project). Έτσι αν κάνετε push κάτι που δεν κάνει compile θα
λάβετε ειδοποίηση μέσω email. Το αποτέλεσμα του αυτόματου ελέγχου εμφανίζεται
και στην αρχική σελίδα του repository, μέσα στο README.md
.
Κύριο πρόγραμμα / unit tests
Σε κάθε εργασία, πέρα από τυχόν modules που ζητούνται να υλοποιηθούν, πρέπει να παραδώσετε και κάποιο εκτελέσιμο πρόγραμμα, το οποίο μπορεί να είναι:
- είτε κάποιο πρόγραμμα του οποίου η είσοδος και η έξοδος περιγράφονται στην εκφώνηση,
- είτε unit tests, τα οποία ελέγχουν τις διάφορες λειτουργίες.
Σε κάθε άσκηση θα διευκρινίζεται τί από τα δύο ζητείται.
README.md
Στον αρχικό κατάλογο του git repository κάθε εργασίας υπάρχει ένα αρχείο
README.md
(απλό αρχείο κειμένου που χρησιμοποιεί το
Markdown
format). Στο αρχείο αυτό θα πρέπει να προσθέσετε
- Όνομα και Α.Μ.
- Όσο documentation χρειάζεται ώστε οι βαθμολογητές να κατανοήσουν πλήρως τις λύσεις σας και να τις βαθμολογήσουν ανάλογα. Αυτό θα πρέπει να γίνει ανεξάρτητα με το αν ο κώδικάς σας είναι καλά σχολιασμένος, πράγμα που συνιστάται.
Παρατηρήσεις
Οι λύσεις σας για όλες τις ασκήσεις πρέπει να είναι οργανωμένες σε modules της C όπως έχουμε συζητήσει στο μάθημα.
Πέρα από την ορθότητα του κώδικα, βαθμολογείται και το πόσο ευανάγνωστος και κατανοητός είναι. Συστήνεται η χρήση του στυλ και των naming conventions του κώδικα των διαλέξεων, και βέβαια η χρήση κατανοητών ονομάτων και κατάλληλος σχολιασμός. Θυμηθείτε: όταν προγραμματίζουμε δεν μας ενδιαφέρει μόνο να τρέχει σωστά το πρόγραμμα, αλλά και να μπορεί να γίνει κατανοητό από κάποιον που το διαβάζει (το διορθωτή, στην προκειμένη περίπτωση)
Δεν χρειάζεται να ελέγχετε παντού ότι τα ορίσματα μιας συνάρτησης είναι σύμφωνα με τις προδιαγραφές. Ενας τέτοιος έλεγχος μπορεί να είναι χρονοβόρος (πχ στην
list_insert_next(list, node, value)
να ελέγξουμε ότι ο κόμβος ανήκει όντως στη λίστα), και άσκοπος (αν πχ η συνάρτηση καλείται μόνο από άλλες συναρτήσεις, όχι απ'ευθείας από το χρήστη, και πάντα με σωστό τρόπο). Σε τέτοιου είδους συναρτήσεις η σύμβαση συνήθως είναι ότι αν η είσοδος είναι λάθος το αποτέλεσμα είναι μη ορισμένο.Ακόμα και όταν ο έλεγχος είναι απλός (πχ ο έλεγχος ότι το
node
δεν είναιNULL
) είναι συχνά προτιμότερο να το ελέγχουμε με κάποιο assert, πχassert(node != NULL)
, παρά να το χειριζόμαστε με πιο “ήπιο” τρόπο (πχ να αγνοούμε την κλήση). Μία κλήση μεnode == NULL
σημαίνει πιθανότατα κάποιο λάθος στον κώδικα που καλεί τη συνάρτηση, οπότε με έναassert
θα το ανακαλύψουμε άμεσα.Συχνά πάλι είναι χρήσιμο να υπάρχουν τέτοιοι έλεγχοι, πχ όταν: τα δεδομένα έρχονται απ'ευθείας από το χρήστη, ο έλεγχος είναι εύκολος, γίνεται μια φορά μόνο στην αρχή, κλπ. Προσθέστε ελεύθερα ελέγχους όπου νομίζετε ότι είναι κατάλληλοι.
Τα προγράμματα σας πρέπει να τρέχουν στους Linux υπολογιστές του τμήματος αφού μεταφραστούν με τον μεταγλωττιστή gcc.