Οι περισσότεροι προγραμματιστές μαθαίνουν να προγραμματίζουν ατομικά. Αυτό είναι κάτι αναμενόμενο αν σκεφθούμε ότι οι πρώτες εφαρμογές ενός εκκολαπτόμενου προγραμματιστή ολοκληρώνονται σε μερικές δεκάδες γραμμών (στην χειρότερη περίπτωση).
Όντας αυτές οι μίνι εφαρμογές, προϊόν εξάσκησης, σπάνια χρησιμοποιούνται από άλλους προγραμματιστές ή επαναχρησιμοποιούνται από τον ίδιο τον δημιουργό.
Η παραπάνω κατάσταση οδηγεί σε κάποιες κακές πρακτικές προγραμματισμού που έχουν σαν αποτέλεσμα την παραγωγή κακογραμμένου, δυσανάγνωστου κώδικα ο οποίος σχεδόν σίγουρα θα κάνει δύσκολη τη ζωή κάποιου άλλου προγραμματιστή ή, στην καλύτερη περίπτωση, θα καθυστερήσει το έργο.
Στο σημερινό μας άρθρο θα παρουσιάσουμε πέντε συχνά προγραμματιστικά λάθη που η αποφυγή τους οδηγεί σε αρκετά ανώτερο, ποιοτικά, κώδικα. Τυχόν παραδείγματα θα παρουσιαστούν σε Java για ευνόητους λόγους.
1. Η ονοματολογία είναι το ήμισυ του παντός
Η σωστή ονοματολογία είναι κάτι που φαντάζει απλό ωστόσο σπάνια γίνεται σωστά. Η γενική οδηγία προτείνει τα ονόματα να μην είναι ούτε πολύ μικρά, ούτε πολύ μεγάλα και να περιγράφουν με σαφήνεια την λειτουργία της εκάστοτε μεταβλητής ή μεθόδου.
Ένα παράδειγμα μεταβλητής θα μπορούσε να είναι:
private int numberOfAuthors;
αντί του:
private int nofAuthors;
και αντίστοιχα για μεθόδους:
public boolean connectToDatabase(...)
αντί του:
public boolean dbConn(...)
(πραγματικά παραδείγματα αμφότερα)
2. Μην χρησιμοποιείται ποτέ implementation types στις δηλώσεις μεταβλητών σας
ArrayList authors = new ArrayList(); //ΛΑΘΟΣ
List authors = new ArrayList(); //ΣΩΣΤΟ
Πρόκειται για λάθος που μου πήρε καιρό να αποβάλλω και οφείλεται αποκλειστικά στο γεγονός ότι για πολύ καιρό προγραμμάτιζα για τον εαυτό μου. Το να χρησιμοποιήσουμε μια τόσο συγκεκριμένη δομή όπως η ArrayList σε μια δήλωση μεταβλητής δημιουργεί προβλήματα όπως:
- “Βαραίνει” τον κώδικά μας μιας και η ArrayList αποτελεί πιο πολύπλοκη δομή από την List
- Μας περιορίζει στην υλοποίηση με τη λογική ότι δεν μπορούμε να χρησιμοποιήσουμε την γκάμα των υλοποιήσεων λίστας που μας προσφέρει η Java (π.χ. LinkedList κλπ.)
Εν γένει, η χρήση αφηρημένων τύπων δεδομένων βοηθά και στην καλύτερη κατανόηση του κώδικα από άτομα που έρχονται για πρώτη φορά σε επαφή με ένα κομμάτι κώδικα. Στο παραπάνω παράδειγμα η χρήση του αφηρημένου τύπου List δηλώνει ξεκάθαρα ότι σαν τύπος δεδομένων έχει επιλεγεί η λίστα, για το συγκεκριμένο κομμάτι κώδικα. Μία δήλωση τύπου ArrayList θα περιέπλεκε τα πράγματα και θα έκανε κάποιον “άσχετο” με τον κώδικα προγραμματιστή να ανατρέξει στα specifics της δομής ArrayList για να δει αν υπάρχει κάποιος ειδικός λόγος που επιλέχθηκε.
3. Copy-Paste κώδικα. Ευλογία ή κατάρα;
Εξαρτάται… Αν γίνει σωστή χρήση, τα οφέλη είναι πολλαπλά. Εδώ όμως θα αναφέρουμε τις περιπτώσεις στις οποίες πρέπει να αποφεύγεται.
Όταν χρειαστεί να επαναλάβουμε ένα τμήμα κώδικα μερικών γραμμών για να τρέξει με ένα set διαφορετικών μεταβλητών, η σωστή αντίδραση μας πρέπει να είναι η μετατροπή του τμήματος αυτού σε function ή method (ανάλογα με τη γλώσσα προγραμματισμού).
Μετατρέποντας ένα κομμάτι κώδικα που εκτελείται συχνά σε function ή method κερδίζουμε πολλαπλά:
- Ο κώδικάς μας γίνεται πιο σύντομος. Αν δεν καταλαβαίνεται το κέρδος που πηγάζει από αυτήν την πρόταση περιμένετε να αντιμετωπίσετε ένα σφάλμα το οποίο βρίσκεται κάπου μέσα στον κώδικά σας και είστε αναγκασμένη να ψάξετε παντού.
- Ο κώδικάς μας γίνεται πιο ευανάγνωστος και πιο κατανοητός.
- Αν χρειαστεί να γίνει κάποια αλλαγή στη λειτουργικότητα του συγκεκριμένου τμήματος κώδικα ανατρέχουμε σε ένα μόνον σημείο. Σε αντίθετη περίπτωση θα έπρεπε να αναζητήσουμε όλα τα σημεία εμφάνισης και να τα τροποποιήσουμε ένα προς ένα.
- Σε επίπεδο ψυχολογικό έχουμε την ικανοποίηση ότι έχουμε απομονώσει μια λειτουργία που κάνει κάτι συγκεκριμένο το οποίο θα είναι σαφές και για οποιονδήποτε άλλον κληθεί να κατανοήσει ή και να χρησιμοποιήσει τον κώδικά μας.
4. Δέσμευση μεταβλητών με τις επιστρεφόμενες τιμές μεθόδων ή συναρτήσεων
Κάποιες μέθοδοι ή συναρτήσεις επιστρέφουν τιμές. Αυτό δε σημαίνει ότι πρέπει υποχρεωτικά να τις αποθηκεύσουμε κάπου. Μία καλή τακτική είναι να δεσμεύετε μεταβλητές για επιστρεφόμενες τιμές μόνον εφόσον πρόκειται να τις χρησιμοποιήσετε.
Για παράδειγμα μία μέθοδος:
public boolean connectToDatabase(…) επιστρέφει μία boolean μεταβλητή για να δηλώσει ότι η σύνδεση έγινε με επιτυχία.
Σενάριο #1:
boolean connectedToDatabase = connectToDatabase(...); //ΛΑΘΟΣ
(υποθέτουμε ότι η connectionToDatabase δε χρησιμοποιείται ποτέ παρακάτω)
Σενάριο #2:
boolean connectedToDatabase = connectToDatabase(...);
if( connectedToDatabase ) //ΣΩΣΤΟ
{
κώδικας...
}
else
{
System.err.println(“Could not connect to database”);
}
Σε αυτήν την περίπτωση η μεταβλητή connectedToDatabase χρησιμοποιείται για να τεστάρουμε αν έχουμε συνδεθεί επιτυχώς στη βάση (συνήθως αποφεύγουμε null pointer exception errors με αυτόν τον τρόπο).
5. Ο κώδικας σε σχόλια πρέπει να διαγράφεται
Το ξέρω ότι μπορεί να πατάω τον κάλο μερικών αλλά είναι η αλήθεια. Και η αλήθεια μερικές φορές πονάει. Για πολύ καιρό συνήθιζα να βάζω κώδικα σε σχόλια, είτε γιατί ήθελα να δοκιμάσω κάτι άλλο, είτε γιατί έπρεπε να αλλάξω την υλοποίησή του και να μην τον διαγράφω στη συνέχεια από ανασφάλεια ότι μπορεί να μου χρειαστεί στο μέλλον και να μην μπορέσω ποτέ να τον παράγω ξανά.
Όταν ένα κομμάτι κώδικα έχει αντικατασταθεί με κάτι άλλο που φαίνεται να δουλεύει ή αποτελούσε κάποιο test που δεν έχει χρησιμοποιηθεί για καιρό, πρέπει να διαγράφεται.
Με αυτόν τον τρόπο:
- Δεν χάνουμε χρόνο να προσπαθούμε να καταλάβουμε τι λειτουργία επιτελούσε όταν τον είχαμε γράψει (μια φορά και έναν καιρό…).
- Δεν αποσπά την προσοχή μας κάθε φορά που τον προσπερνάμε.
- Δεν δημιουργεί τύψεις σε όποιον χρειαστεί να δει / χρησιμοποιήσει τον κώδικά μας. Βλέποντας ένα κομμάτι του κώδικά μας σε σχόλια το πρώτο πράγμα που θα σκεφθεί ένας προγραμματιστής είναι ότι το συγκεκριμένο κομμάτι εμφανίζει μια δυσλειτουργία την οποία κάποιος εξετάζει κάνοντας δοκιμές.
Συμβουλή προς όλους. Αν δουλεύετε σε κάποια ομάδα ανάπτυξης λογισμικού και σας δοθεί κώδικας ο οποίος περιέχει κώδικα σε σχόλια, απλά διαγράψτε τον. Εφόσον είναι σε σχόλια, σας είναι άχρηστος και δεν είστε σε καμία περίπτωση υποχρεωμένοι να μαντέψετε τον λόγο για τον οποίο ξέμεινε εκεί. Ούτως ή άλλως οι περισσότερες εταιρίες παρακολουθούν τα έργα λογισμικού καθώς εξελίσσονται και τηρούν ιστορικό τον αλλαγών. Άρα αν κάποιος, κάποτε το χρειαστεί, μπορεί να ανατρέξει σε παλαιότερες εκδόσεις και να τον εντοπίσει.
Η συγγραφή καλού κώδικα δεν αποτελεί υποχρέωση αλλά είναι καλό να γίνει συνήθεια σε όλους τους προγραμματιστές. Μπορεί να κοστίζει ελαφρώς σε χρόνο αλλά τα οφέλη μακροπρόθεσμα είναι πραγματικά πολλά. Δοκιμάστε τις παραπάνω συμβουλές και θα το διαπιστώσετε και μόνοι σας. Μέχρι την επόμενη φορά…
Να είστε καλά και να φροντίζετε τον εαυτό σας.
Κανένα Σχόλιο