Προγραμματισμός

10 κακές συνήθειες προγραμματισμού που λατρεύουμε κρυφά

Το έχουμε κάνει όλα: πήγαινε ένα μπισκότο όταν η μαμά δεν κοιτούσε, είχε λίγο πολύ κρασί για δείπνο, άφησε το αυτοκίνητο να καθίσει σε θέση στάθμευσης μετά τη λήξη του μετρητή. Έχουμε περάσει ακόμη και γύρω από το Deadman's Curve λίγο πολύ γρήγορα. Και ναι, παραβιάσαμε όλους τους βασικούς κανόνες προγραμματισμού, αυτοί που όλοι συμφωνούν είναι κακοί. Και μας άρεσε κρυφά.

Έχουμε πειράξει τους κανόνες του καλού προγραμματισμού, πληκτρολογήσαμε κώδικα που είναι εντελώς άσχημος και έχουμε ζήσει. Δεν υπήρχαν κεραυνοί από τους θεούς προγραμματισμού. Οι επιτραπέζιοι υπολογιστές μας δεν εκρήχθηκαν. Στην πραγματικότητα, ο κωδικός μας καταρτίστηκε και στάλθηκε, και οι πελάτες φαινόταν αρκετά ευχαριστημένοι.

Αυτό συμβαίνει επειδή ο κακός προγραμματισμός δεν είναι στο ίδιο πρωτάθλημα όπως, για παράδειγμα, να γλείφεις ηλεκτρικό φράχτη ή να τραβάς την ουρά μιας τίγρης. Τις περισσότερες φορές, λειτουργεί. Οι κανόνες είναι πιο συχνά οδηγίες ή στιλιστικές προτάσεις, όχι δύσκολες και γρήγορες οδηγίες που πρέπει να τηρούνται ή θα ακολουθεί ο κώδικας. Σίγουρα, ο κώδικάς σας μπορεί να γελοιοποιηθεί, πιθανώς ακόμη και δημόσια. Αλλά το γεγονός ότι κρατάτε τις συμβάσεις προσθέτει λίγο από τη συγκίνηση στην ανατροπή, ακόμη και ακούσια, που ισοδυναμεί με (πιο συχνά από ό, τι όχι) τα κοινωνικά ήθη του ευχάριστου κώδικα.

Για να κάνετε τα πράγματα πιο περίπλοκα, μερικές φορές είναι καλύτερα να παραβιάσετε τους κανόνες. (Shhhh!) Ο κωδικός βγαίνει καθαρότερος. Μπορεί να είναι ακόμη πιο γρήγορο και απλούστερο. Οι κανόνες είναι συνήθως λίγο υπερβολικοί και ένας έξυπνος προγραμματιστής μπορεί να βελτιώσει τον κώδικα σπάζοντάς τους. Μην πείτε στο αφεντικό σας, αλλά μερικές φορές έχει νόημα να κωδικοποιήσετε τον δικό σας τρόπο.

Αυτό που ακολουθεί είναι μια λίστα με εννέα κανόνες που ορισμένοι μπορεί να θεωρήσουν απαράδεκτο, αλλά πολλοί από εμάς σπάνε συχνά, τόσο με επιτυχία όσο και με ευχαρίστηση.

Κακή συνήθεια προγραμματισμού αριθ. 1: Αντιγραφή

Είναι λάθος να το κάνεις στο σχολείο. Στην εργασία, οι κανόνες δεν είναι τόσο σαφείς. Υπάρχουν σίγουρα ορισμένα τμήματα κώδικα που δεν πρέπει να κλαπεί. Εάν προέρχεται από ιδιόκτητο κώδικα, μην τον διπλώνετε στη στοίβα σας, ειδικά εάν έχει επισημανθεί με μήνυμα πνευματικών δικαιωμάτων. Γράψτε τη δική σας έκδοση. Είναι αυτό που σας πληρώνουν για να κάνετε.

Η πιο δύσκολη ερώτηση έρχεται όταν ο αρχικός δημιουργός θέλει να μοιραστεί. Ίσως είναι σε ένα από τα διαδικτυακά φόρουμ προγραμματισμού. Ίσως ο κώδικας ανοιχτού κώδικα με άδεια (BSD, MIT) που επιτρέπει την εμπλοκή μιας λειτουργίας ή τριών. Δεν υπάρχει κανένας νόμιμος λόγος να σας σταματήσει. Και πληρώνεστε για την επίλυση προβλημάτων, όχι για να ανακαλύψετε ξανά τον τροχό.

Τις περισσότερες φορές, τα πλεονεκτήματα της αντιγραφής είναι συναρπαστικά και τα μειονεκτήματα μπορούν να περιοριστούν με λίγη προσοχή. Ο κώδικας που λαμβάνετε από μια αξιόπιστη πηγή έχει ήδη εφαρμόσει τουλάχιστον έναν γύρο σκέψης. Ο αρχικός συγγραφέας έψαξε μια λύση και βρήκε κάτι. Οι αναλλοίωτες βρόχοι και η ροή δεδομένων έχουν επεξεργαστεί.

Οι δύσκολες ερωτήσεις είναι εάν υπάρχουν κάποια αβάσιμα σφάλματα ή κάποιες διαφορετικές παραδοχές σχετικά με το ρόλο ή τα υποκείμενα δεδομένα. Ίσως ο κώδικάς σας να αναμιγνύεται σε μηδενικούς δείκτες, ενώ ο αρχικός κώδικας δεν τους έλεγξε ποτέ. Εάν μπορείτε να επιλύσετε τα προβλήματα, είναι σαν το αφεντικό σας να λαμβάνει τη συμβολή από δύο προγραμματιστές. Είναι προγραμματισμός ζευγών χωρίς τα φανταχτερά γραφεία.

Κακή συνήθεια προγραμματισμού αριθ. 2: Μη λειτουργικός κωδικός

Για την τελευταία δεκαετία, το λειτουργικό παράδειγμα ανεβαίνει. Οι ακολότες για την οικοδόμηση του προγράμματός σας από ένθετες λειτουργίες καλούν να αναφέρουν μελέτες που δείχνουν πώς ο κώδικας είναι ασφαλέστερος και χωρίς σφάλματα από το παλαιότερο στυλ μεταβλητών και βρόχων, όλα ενωμένα με οποιονδήποτε τρόπο κάνει τον προγραμματιστή ευτυχισμένο. Οι οπαδοί μιλούν με το ζήλο των αληθινών πιστών, τιμωρώντας τις μη λειτουργικές προσεγγίσεις σε κριτικές κώδικα και αιτήματα έλξης. Μπορεί να έχουν δίκιο ακόμη και για τα πλεονεκτήματα.

Αλλά μερικές φορές απλά πρέπει να βγάζετε ένα ρολό κολλητικής ταινίας. Ο υπέροχος σχεδιασμένος και χαριτωμένος προγραμματισμένος κώδικας απαιτεί χρόνο, όχι μόνο για να φανταστεί κανείς, αλλά και για την κατασκευή και αργότερα για πλοήγηση. Όλα αυτά τα επίπεδα προσθέτουν πολυπλοκότητα και η πολυπλοκότητα είναι ακριβή. Οι προγραμματιστές όμορφου λειτουργικού κώδικα πρέπει να προγραμματίσουν μπροστά και να διασφαλίσουν ότι όλα τα δεδομένα διαβιβάζονται σε κατάλληλες διαδρομές. Μερικές φορές είναι πιο εύκολο να προσεγγίσετε και να αλλάξετε μια μεταβλητή. Ίσως βάλτε ένα σχόλιο για να το εξηγήσετε. Ακόμη και η προσθήκη μιας μακράς, εξωφρενικής συγγνώμης στις μελλοντικές γενιές στο σχόλιο είναι ταχύτερη από την εκ νέου κατασκευή ολόκληρου του συστήματος για να το κάνει με τον σωστό τρόπο.

Κακή συνήθεια προγραμματισμού αριθ. 3: Μη τυπική απόσταση

Οι περισσότεροι χώροι στο λογισμικό δεν επηρεάζουν την απόδοση του προγράμματος. Εκτός από μερικές γλώσσες όπως η Python που χρησιμοποιούν το διάστιχο για να υποδείξουν μπλοκ κώδικα, οι περισσότεροι χώροι έχουν μηδενική επίδραση στον τρόπο συμπεριφοράς του προγράμματος. Ωστόσο, υπάρχουν εμμονικοί προγραμματιστές που τους μετράνε και επιμένουν ότι έχουν σημασία. Ένας από αυτούς είπε κάποτε στο αφεντικό μου με τον πιο σοβαρό τόνο ότι έγραψα «Non Standard Code» και μπορούσε να το δει αμέσως. Η αμαρτία μου; Παραβίαση του κανόνα space-infix-ops του ESLint αποτυπώνοντας ένα κενό και στις δύο πλευρές ενός ίσου σημείου.

Μερικές φορές απλά πρέπει να σκεφτείτε κάτι βαθύτερο από την τοποθέτηση χώρων. Ίσως ανησυχείτε για την υπερφόρτωση της βάσης δεδομένων. Ίσως ανησυχείτε για κάποιο τρόπο που ένας μηδενικός δείκτης θα μπορούσε να καταστρέψει τον κωδικό σας. Σχεδόν οποιοδήποτε μέρος του κώδικα είναι πιο σημαντικό από τα κενά, ακόμα κι αν οι νέες επιτροπές προτύπων έχουν συμπληρώσει σελίδες κανόνων σχετικά με την τοποθέτηση αυτών των κενών ή καρτελών.

Το εκπληκτικό είναι ότι υπάρχουν πολλά καλά εργαλεία που θα αναδιαμορφώσουν αυτόματα τον κώδικά σας ώστε να συμμορφώνονται με οποιουσδήποτε καλά καθορισμένους κανόνες χνούδι. Οι άνθρωποι δεν χρειάζεται να ξοδεψουν χρόνο να το σκεφτούν. Εάν είναι τόσο σημαντικό, μπορούν να το εκτελέσουν μέσω του εργαλείου για να καθαρίσουν το πρόβλημα.

Κακή συνήθεια προγραμματισμού αριθ. 4: Χρήση παω σε

Η απαγόρευση χρήσης παω σε χρονολογείται στην εποχή πριν από την ύπαρξη πολλών εργαλείων δομημένου προγραμματισμού. Εάν οι προγραμματιστές ήθελαν να δημιουργήσουν ένα βρόχο ή να μεταβούν σε άλλη ρουτίνα, θα πρέπει να πληκτρολογήσουν ΠΑΩ ΣΕ ακολουθούμενο από έναν αριθμό γραμμής. Μετά από λίγα χρόνια, οι ομάδες μεταγλωττιστών επιτρέπουν στους προγραμματιστές να χρησιμοποιούν μια ετικέτα συμβολοσειράς αντί για έναν αριθμό γραμμής. Αυτό θεωρήθηκε ένα καυτό νέο χαρακτηριστικό τότε.

Κάποιοι χαρακτήρισαν το αποτέλεσμα «κώδικας σπαγγέτι». Ήταν αδύνατο για κανέναν να διαβάσει τον κωδικό σας αργότερα και να ακολουθήσει τη διαδρομή εκτέλεσης. Ήταν ένα μείγμα νημάτων, μπερδεμένο για πάντα. Ο Edsger Dijkstra απαγόρευσε την εντολή με ένα χειρόγραφο με τίτλο «Η δήλωση Goto θεωρείται επιβλαβής».

Αλλά η απόλυτη διακλάδωση δεν είναι το πρόβλημα. Είναι το μπερδεμένο αποτέλεσμα. Συχνά ένας επιδέξιος Διακοπή ή ΕΠΙΣΤΡΟΦΗ θα προσφέρει μια πολύ καθαρή δήλωση σχετικά με το τι κάνει ο κώδικας σε αυτήν την τοποθεσία. Μερικές φορές προσθήκη παω σε σε μια δήλωση περίπτωσης θα παράγει κάτι που είναι πιο απλό να γίνει κατανοητό από μια πιο σωστά δομημένη λίστα των μπλοκ if-then-else.

Υπάρχουν αντιπαραδείγματα. Η τρύπα ασφαλείας "goto fail" στη στοίβα SSL της Apple είναι μια από τις καλύτερες περιπτώσεις. Αλλά αν είμαστε προσεκτικοί για να αποφύγουμε μερικά από τα σοβαρά ζητήματα των δηλώσεων περίπτωσης και των βρόχων, μπορούμε να εισάγουμε καλά, απόλυτα άλματα που διευκολύνουν τον αναγνώστη να κατανοήσει τι συμβαίνει. Μπορούμε να βάλουμε σε ένα Διακοπή ή α ΕΠΙΣΤΡΟΦΗ που είναι καθαρότερο και πιο ευχάριστο για όλους - εκτός ίσως από το παω σε μίσους.

Κακή συνήθεια προγραμματισμού αριθ. 5: Μη δήλωση τύπων

Οι λαοί που αγαπούν τις δακτυλογραφημένες γλώσσες έχουν ένα σημείο. Γράφουμε καλύτερα, περισσότερο κώδικα χωρίς σφάλματα όταν προσθέτουμε σαφείς δηλώσεις του τύπου δεδομένων κάθε μεταβλητής. Η παύση μιας στιγμής για να διευκρινιστεί ο τύπος βοηθά τον μεταγλωττιστή να επισημάνει ηλίθια σφάλματα πριν ξεκινήσει η εκτέλεση του κώδικα. Μπορεί να είναι πόνος, αλλά βοηθάει. Πρόκειται για μια προσέγγιση με ζώνες και αναστολείς στον προγραμματισμό που σταματά τα σφάλματα.

Οι καιροί έχουν αλλάξει. Πολλοί από τους νεότερους μεταγλωττιστές είναι αρκετά έξυπνοι για να συμπεράνουν τον τύπο κοιτάζοντας τον κωδικό. Μπορούν να λειτουργήσουν προς τα πίσω και προς τα εμπρός μέσω του κώδικα μέχρι να μπορούν να είναι σίγουροι ότι η μεταβλητή πρέπει να είναι α σειρά ή ένα int ή κάτι άλλο. Και αν αυτοί οι συμπερασμένοι τύποι δεν ευθυγραμμιστούν, τότε οι μεταγλωττιστές μπορούν να επισημάνουν μια σημαία σφάλματος. Δεν χρειάζονται πλέον να πληκτρολογούμε τις μεταβλητές.

Αυτό σημαίνει ότι είναι πλέον ευκολότερο να εξοικονομήσετε μερικά bit αφήνοντας μερικές από τις πιο απλές δηλώσεις. Ο κώδικας γίνεται λίγο πιο καθαρός και ο αναγνώστης είναι συνήθως αρκετά ικανός να μαντέψει ότι η μεταβλητή ονομάζεται Εγώ στο a for loop είναι ακέραιος.

Κακή συνήθεια προγραμματισμού αριθ. 6: Yo-yo code

Οι προγραμματιστές θέλουν να τον αποκαλούν «yo-yo code». Αρχικά οι τιμές αποθηκεύονται ως συμβολοσειρές. Στη συνέχεια αναλύονται σε ακέραιους αριθμούς. Στη συνέχεια μετατρέπονται σε χορδές. Είναι εξαιρετικά αναποτελεσματικό. Μπορείτε να νιώσετε σχεδόν τον αγώνα της CPU κάτω από όλο το επιπλέον φορτίο. Οι έξυπνοι προγραμματιστές που γράφουν γρήγορο κώδικα σχεδιάζουν τις αρχιτεκτονικές τους για να ελαχιστοποιήσουν τις μετατροπές. Ο κωδικός τους τρέχει πιο γρήγορα λόγω του σχεδιασμού τους.

Αλλά το πιστεύετε ή όχι, μερικές φορές έχει νόημα. Μερικές φορές έχετε μια βιβλιοθήκη που κάνει έξυπνα πράγματα κατά ένα δισεκατομμύριο μέσα στο ιδιόκτητο μαύρο κουτί της. Μερικές φορές το αφεντικό έγραψε μια επταψήφια επιταγή για την άδεια όλων των ιδιοφυών μέσα σε αυτό το μαύρο κουτί. Εάν η βιβλιοθήκη θέλει τα δεδομένα σε συμβολοσειρές, τα δίνετε στη βιβλιοθήκη σε συμβολοσειρές ακόμα και αν τα μετατρέψατε πρόσφατα σε ακέραιους αριθμούς.

Σίγουρα, θα μπορούσατε να ξαναγράψετε ολόκληρο τον κωδικό σας για να ελαχιστοποιήσετε τη μετατροπή, αλλά αυτό θα απαιτούσε χρόνο. Μερικές φορές είναι εντάξει για τον κώδικα να εκτελείται ένα επιπλέον λεπτό, ώρα, ημέρα ή ακόμα και εβδομάδα, επειδή η επανεγγραφή του κώδικα θα χρειαστεί ακόμη περισσότερο χρόνο. Μερικές φορές, η εξάντληση του τεχνικού χρέους είναι φθηνότερη από την αρχική κατασκευή του.

Μερικές φορές η βιβλιοθήκη δεν είναι ιδιόκτητος κώδικας, αλλά κωδικός που γράψατε τον εαυτό σας εδώ και πολύ καιρό. Μερικές φορές είναι πιο γρήγορο να μετατρέψετε τα δεδομένα μία ακόμη φορά από το να ξαναγράψετε τα πάντα σε αυτήν τη βιβλιοθήκη. Συνεχίστε λοιπόν και γράφετε yo-yo code. Είναι εντάξει - όλοι ήμασταν εκεί.

Κακή συνήθεια προγραμματισμού αριθ. 7: Γράφοντας τις δικές σας δομές δεδομένων

Ένας από τους τυπικούς κανόνες είναι ότι ο προγραμματιστής δεν πρέπει ποτέ να γράφει κώδικα για την αποθήκευση δεδομένων μετά την ολοκλήρωση του μαθήματος δομών δεδομένων στο δεύτερο έτος του. Κάποιος άλλος έχει ήδη γράψει όλες τις δομές δεδομένων που θα χρειαζόμαστε ποτέ και ο κώδικάς του έχει δοκιμαστεί και δοκιμαστεί ξανά με την πάροδο των ετών. Συνοδεύεται από τη γλώσσα και είναι πιθανώς δωρεάν. Ο κωδικός σας θα μπορούσε να έχει μόνο σφάλματα.

Αλλά μερικές φορές οι βιβλιοθήκες δομής δεδομένων είναι λίγο αργές. Μερικές φορές μας αναγκάζουν σε μια δομή που μπορεί να είναι τυπική αλλά λάθος για τον κώδικα μας. Μερικές φορές οι βιβλιοθήκες μας ωθούν να αναδιαμορφώσουμε τα δεδομένα μας προτού χρησιμοποιήσουμε τη δομή. Μερικές φορές οι βιβλιοθήκες περιλαμβάνουν προστατευτικές ζώνες και αναστολείς με χαρακτηριστικά όπως κλείδωμα νήματος και ο κώδικάς μας δεν τις χρειάζεται.

Όταν συμβεί αυτό, ήρθε η ώρα να γράψουμε τις δικές μας δομές δεδομένων. Μερικές φορές είναι πολύ, πολύ πιο γρήγορα. Και μερικές φορές καθιστά τον κώδικά μας πολύ πιο καθαρό, διότι δεν συμπεριλαμβάνουμε όλο τον επιπλέον κώδικα για τη διαμόρφωση των δεδομένων ακριβώς.

Κακή συνήθεια προγραμματισμού αριθ. 8: Παλιομοδίτικοι βρόχοι

Πριν από πολύ καιρό, κάποιος που δημιούργησε τη γλώσσα Γ ήθελε να ενσωματώσει όλες τις αφηρημένες δυνατότητες σε μια απλή κατασκευή. Υπήρχαν κάποια πράγματα που πρέπει να γίνουν στην αρχή, κάποια πράγματα να κάνουμε κάθε φορά μέσω του βρόχου και κάποιος τρόπος να πούμε πότε όλα έγιναν. Εκείνη την εποχή, φαινόταν σαν μια τέλεια καθαρή σύνταξη για τη λήψη απεριόριστων δυνατοτήτων.

Αυτό ήταν τότε. Τώρα μερικές σύγχρονες επιπλήξεις βλέπουν μόνο προβλήματα. Υπάρχουν πάρα πολλά πράγματα που συμβαίνουν. Όλες αυτές οι δυνατότητες για καλοσύνη είναι επίσης εξίσου ικανές για κακό. Κάνει την ανάγνωση και το grokking πολύ πιο δύσκολο. Αγαπούν το πιο λειτουργικό παράδειγμα όπου δεν υπάρχουν βρόχοι, απλώς λειτουργίες που εφαρμόζονται σε λίστες, υπολογιστικά πρότυπα χαρτογραφημένα σε ορισμένα δεδομένα.

Υπάρχουν στιγμές που ο αδιάλειπτος τρόπος είναι καθαρότερος, ειδικά όταν υπάρχει μόνο μία καθαρή λειτουργία και ένας πίνακας. Αλλά υπάρχουν στιγμές που ο παλιομοδίτικος βρόχος είναι πολύ πιο απλός γιατί μπορεί να κάνει πολύ περισσότερα. Η αναζήτηση για τον πρώτο αγώνα, για παράδειγμα, είναι πιο απλή όταν μπορείτε να σταματήσετε μόλις βρεθεί.

Επιπλέον, οι λειτουργίες χαρτογράφησης ενθαρρύνουν την κωδικοποίηση sloppier όταν υπάρχουν πολλά πράγματα που πρέπει να γίνουν στα δεδομένα. Φανταστείτε ότι θέλετε να πάρετε την απόλυτη τιμή και μετά την τετραγωνική ρίζα κάθε αριθμού. Η πιο γρήγορη λύση είναι να χαρτογραφήσετε την πρώτη συνάρτηση και μετά τη δεύτερη, να περάσετε δύο φορές τα δεδομένα.

Κακή συνήθεια προγραμματισμού αριθ. 9: Σπάσιμο βρόχων στη μέση

Κάπου κατά μήκος της γραμμής, μια ομάδα δημιουργίας κανόνων δήλωσε ότι κάθε βρόχος πρέπει να έχει ένα «αμετάβλητο», δηλαδή μια λογική δήλωση που ισχύει σε ολόκληρο τον βρόχο. Όταν το αμετάβλητο δεν ισχύει πλέον, ο βρόχος τελειώνει. Είναι ένας καλός τρόπος να σκεφτούμε περίπλοκους βρόχους, αλλά οδηγεί σε τρελές απαγορεύσεις, όπως να μας απαγορεύουμε να χρησιμοποιούμε ένα ΕΠΙΣΤΡΟΦΗ ή α Διακοπή στη μέση του βρόχου. Αυτό είναι ένα υποσύνολο του απαγορευτικού κανόνα παω σε δηλώσεις.

Αυτή η θεωρία είναι καλή, αλλά συνήθως οδηγεί σε πιο περίπλοκο κώδικα. Εξετάστε αυτήν την απλή περίπτωση που σαρώνει έναν πίνακα για μία καταχώριση που περνάει μια δοκιμή:

καθώς εγώ<>

   ...

εάν (δοκιμή (a [i]) τότε επιστρέψτε ένα [i];

   ...

}

Οι αμετάβλητοι λάτρεις του βρόχου προτιμούν να προσθέσουμε μια άλλη boolean μεταβλητή, να την ονομάσουμε δεν βρέθηκεκαι χρησιμοποιήστε το ως εξής:

ενώ ((notFound) && (i<>

...

εάν (test (a [i])) τότε notFound = false;

...

}

Εάν αυτό το boolean είναι σωστό, είναι ένα υπέροχο κομμάτι αυτο-τεκμηρίωσης κώδικα. Μπορεί να διευκολύνει την κατανόηση όλων. Προστίθεται όμως και πολυπλοκότητα. Και αυτό σημαίνει την εκχώρηση μιας άλλης τοπικής μεταβλητής και την απόφραξη ενός μητρώου που ο μεταγλωττιστής μπορεί ή όχι να είναι αρκετά έξυπνος για να διορθώσει.

Μερικές φορές παω σε ή ένα άλμα είναι καθαρότερο.

Κακή συνήθεια προγραμματισμού αριθ. 10: Επαναπροσδιορισμός χειριστών και λειτουργιών

Μερικές από τις πιο διασκεδαστικές γλώσσες σάς επιτρέπουν να κάνετε πραγματικά παραπλανητικά πράγματα όπως να επαναπροσδιορίσετε την αξία των στοιχείων που μοιάζουν να είναι σταθερά. Η Python, για παράδειγμα, σας επιτρέπει να πληκτρολογείτε TRUE = ΛΑΘΟΣ, τουλάχιστον στην έκδοση 2.7 και πριν. Αυτό δεν δημιουργεί κάποια λογική κατάρρευση και το τέλος του σύμπαντος. αλλάζει απλά την έννοια του ΑΛΗΘΗΣ και ΨΕΥΔΗΣ. Μπορείτε επίσης να παίξετε επικίνδυνα παιχνίδια όπως αυτό με προεπεξεργαστές C και ορισμένες άλλες γλώσσες. Ακόμα άλλες γλώσσες σάς επιτρέπουν να επαναπροσδιορίσετε τους τελεστές όπως το σύμβολο συν.

Αυτό είναι ένα τέντωμα, αλλά θα υπάρχουν σημεία μέσα σε ένα μεγάλο τμήμα κώδικα όταν είναι πιο γρήγορο να επαναπροσδιορίσετε μία ή περισσότερες από αυτές τις λεγόμενες σταθερές. Μερικές φορές το αφεντικό θέλει ο κώδικας να κάνει κάτι εντελώς διαφορετικό. Σίγουρα, θα μπορούσατε να εργαστείτε μέσω του κώδικα και να αλλάξετε κάθε εμφάνιση, ή θα μπορούσατε να επαναπροσδιορίσετε την πραγματικότητα. Μπορεί να σε κάνει να μοιάζεις με ιδιοφυΐα. Αντί να ξαναγράψετε μια τεράστια βιβλιοθήκη, απλώς γυρίστε λίγο και κάνει το αντίθετο.

Ίσως είναι καλό να σχεδιάσετε τη γραμμή εδώ. Δεν πρέπει να το δοκιμάσετε στο σπίτι, ανεξάρτητα από το πόσο έξυπνο και διασκεδαστικό μπορεί να είναι. Αυτό είναι πολύ επικίνδυνο - πραγματικά ... ειλικρινές.

$config[zx-auto] not found$config[zx-overlay] not found