Αναπνέοντας αέρα στον Οδηγό στυλ JavaScript της AirBnB

Κανείς δεν θέλει να γράψει άσχημο, ασυνεπές στυλ κώδικα. Απλώς συμβαίνει.

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

Γι 'αυτό χρειάζεστε έναν οδηγό στυλ.

Έχω ζήσει από πρώτο χέρι πόσες περισσότερες ομάδες μπορούν να επιτύχουν μετά την έγκριση ενός οδηγού στυλ.

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

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

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

Εισαγάγετε το AirBnB + ESLint

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

Όμως, καθώς το οικοσύστημα ωριμάζει, οι έμπειροι προγραμματιστές αρχίζουν να λαχταρούν για «τον τυπικό τρόπο» να κάνουν πράγματα που προσφέρουν πιο σταθερά οικοσυστήματα.

Φυσικά είστε ευπρόσδεκτοι να περάσετε λίγες μέρες για να εξερευνήσετε το οικοσύστημα JavaScript και να συγκρίνετε διαφορετικά εργαλεία, αλλά θα προσπαθήσω να σας εξοικονομήσω λίγο χρόνο : Το ESLint είναι το πιο δημοφιλές εργαλείο χειρισμού JavaScript και ο οδηγός στυλ της AirBnB είναι ο πιο ευρέως χρησιμοποιούμενος οδηγός στυλ.

Για περισσότερες λεπτομέρειες σχετικά με την προσθήκη ESLint στο έργο σας, ελέγξτε αυτόν τον σύνδεσμο.

Μόλις το αποκτήσετε, μπορείτε να διαμορφώσετε το έργο σας για να επιβάλλετε τον οδηγό στυλ της AirBnB εγκαθιστώντας το πακέτο npm:

npm install --save-dev eslint-config-airbnb

Προσθέστε την ακόλουθη γραμμή στο αρχείο .eslintrc

"extends": "airbnb"

Και voilà! Ο κώδικάς σας υπόκειται πλέον στους κανόνες του πιο δημοφιλούς οδηγού στυλ JavaScript. Καλή κωδικοποίηση!

Τα πρότυπα υπερτιμούνται

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

Επιτρέψτε μου να εξηγήσω λεπτομερώς το σκεπτικό πίσω από κάθε μια από αυτές τις προσαρμογές.

Εσοχή

Οι καρτέλες VS Space War μπορούν δυνητικά να καταστρέψουν τις φιλίες και πιθανώς να σαμποτάρουν τις ρομαντικές σχέσεις.

Προτιμώ να εσοχή στον κώδικά μου 4 κενά, παρόλο που η συντριπτική πλειονότητα των ρυθμίσεων εκεί προτιμά μια εσοχή 2.

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

Σίγουρα δεν πρέπει να τοποθετείτε κώδικα βαθύτερα από 3 ή 4 επίπεδα μέσα σε ένα αρχείο JavaScript (είναι μια μυρωδιά κώδικα). Έτσι, έχοντας 4 κενά, σας προσφέρει καλύτερη αναγνωσιμότητα, διατηρώντας παράλληλα άλλους κανόνες όπως η διατήρηση του κωδικού σας εντός ορίου 80 ή 120 χαρακτήρων ανά γραμμή.

Επίσης, η εσοχή είναι ένας από τους κανόνες που εισπνέουν περισσότερο «αέρα» στον προεπιλεγμένο οδηγό στυλ της AirBnB. Ως αποτέλεσμα, ο κώδικάς σας δεν συσσωρεύεται στην αριστερή πλευρά του προγράμματος επεξεργασίας τόσο άσχημα.

Διάστημα

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

Τι σημαίνουν λοιπόν αυτοί οι κανόνες; Λοιπόν, ρίξτε μια ματιά στον παρακάτω κώδικα. Τηρεί τεχνικά τους κανόνες του επίσημου οδηγού στυλ της AirBnB.

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

Τώρα ρίξτε μια ματιά στον ίδιο κώδικα, αλλά με τους πρόσθετους κανόνες απόστασης:

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

Ελέγξτε επίσης τη διαφορά μεταξύ της εσοχής 2 και 4 διαστημάτων στα δύο παραδείγματα.

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

Παραθέτω πολέμους

Ενώ οι δύο πρώτες κατηγορίες είχαν κάποια σαφή επιχειρήματα, πρέπει να πω ότι η απόφαση single vs double εισαγωγικά είναι πολύ υποκειμενική.

Η προτίμησή μου για διπλά εισαγωγικά προέρχεται πιθανώς από το να δουλεύω πολύ με το React, όπου συνδυάζετε JavaScript με ετικέτες JSX. Δεδομένου ότι το JSX είναι πιο κοντά στο HTML, η τάση είναι η προσθήκη χαρακτηριστικών μεταξύ διπλών εισαγωγικών. Άρχισα λοιπόν να χρησιμοποιώ διπλά εισαγωγικά για όλα, μόνο για συνέπεια.

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

Ρύθμιση κώδικα

Ο επίσημος οδηγός στυλ AirBnB έχει έναν κανόνα «χωρίς χρήση πριν από τον ορισμό», ο οποίος δημιουργεί ένα σφάλμα εάν προσπαθήσετε να χρησιμοποιήσετε κάτι πριν το ορίσετε. Αυτός είναι ένας καλός κανόνας - ειδικά για τις μεταβλητές - επειδή δεν πρέπει να βασίζεστε στην ανύψωση και πρέπει να έχετε κατά νου το πρόβλημα της χρονικής νεκρής ζώνης όταν χρησιμοποιείτε το let and const.

Προτιμώ να επιτρέψω τη χρήση συναρτήσεων προτού καθοριστούν. Ο λόγος είναι απλός: τις περισσότερες φορές, θα χωρίσετε τις λειτουργίες σας σε μικρότερες δευτερεύουσες λειτουργίες. Ωστόσο, ο κανόνας "χωρίς χρήση πριν από τον ορισμό" θα σας πει να τοποθετήσετε αυτές τις δευτερεύουσες λειτουργίες πριν από την αρχική λειτουργία.

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

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

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

Συνεχίζω

Ακολουθεί μια άλλη μικρή απόκλιση από τον οδηγό στυλ. Μπορείτε να παρατηρήσετε στη διαμόρφωση μου:

"prefer-const": 1

Στη διαμόρφωση AirBnB, αυτό έχει οριστεί σε 2, το οποίο σημαίνει σφάλμα , ενώ το 1 σημαίνει προειδοποίηση .

Τώρα, αν δεν καταλαβαίνετε γιατί πρέπει να προτιμάτε το const από το let, μπορείτε να διαβάσετε περισσότερα γι 'αυτό εδώ και εδώ.

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

Ρίξτε μια ματιά σε αυτόν τον κωδικό:

Οι κανόνες θα σας πουν ότι αυτό είναι σωστό - το hash πρέπει να είναι const επειδή δεν έχει εκχωρηθεί ξανά. Αλλά αυτό δεν είχε νόημα ποτέ για μένα. Πρέπει να γνωρίζω ότι υπάρχει μεγάλη αλλαγή στο εσωτερικό του κατακερματισμού.

Έτσι θα χρησιμοποιήσω το let για να δείξω το γεγονός ότι η μεταβλητή υπόκειται σε αλλαγή. Το const και let πρέπει να δίνει περισσότερο νόημα στις μεταβλητές σας και δεν πρέπει να κρύβει την αλήθεια με κανέναν τρόπο.

Πολυπλοκότητα κώδικα

Μπορείτε να κυκλώσετε την πολυπλοκότητα κώδικα για να υπολογίσετε την πολυπλοκότητα καθεμιάς από τις λειτουργίες σας.

Η απόφαση για ένα ανώτατο επίπεδο πολυπλοκότητας είναι δύσκολη. Στην ιδανική περίπτωση, πρέπει να είναι όσο το δυνατόν χαμηλότερο, πράγμα που σημαίνει ότι οι λειτουργίες σας πρέπει να έχουν το πολύ 1 ή 2 δυνατότητες διακλάδωσης.

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

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

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

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

Μια σημείωση για το React

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

Ο κύριος στόχος των παρακάμψεων του React μου είναι να περιορίσω τη διαφοροποίηση μεταξύ των κανονικών ενοτήτων JavaScript και των στοιχείων του React, καθώς και μεταξύ του κώδικα JavaScript και του JSX. Γι 'αυτό επιλέγω παρόμοια εσοχή και τη χρήση διπλών εισαγωγικών για όλα τα χαρακτηριστικά JSX. Γι 'αυτό προτιμώ να αφήνω όλα τα αρχεία μου με την επέκταση .js.

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

Για αυτό πρόκειται! Ελπίζω να σας άρεσε να το διαβάζετε. Χαιρετίζω τα σχόλιά σας παρακάτω.

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