13 Αξιοσημείωτα σημεία από τον Οδηγό στυλ JavaScript της Google

Για όσους δεν είναι ήδη εξοικειωμένοι με αυτό, η Google παρουσιάζει έναν οδηγό στυλ για τη σύνταξη JavaScript που εκθέτει (αυτό που πιστεύει η Google) τις καλύτερες στιλιστικές πρακτικές για τη σύνταξη καθαρού, κατανοητού κώδικα.

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

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

Τα παρακάτω είναι δεκατρία από αυτά που πιστεύω ότι είναι οι πιο ενδιαφέρουσες και σχετικές ρυθμίσεις από τον Οδηγό στυλ JS της Google.

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

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

Χρησιμοποιήστε κενά και όχι καρτέλες

Εκτός από την ακολουθία τερματισμού γραμμής, ο χαρακτήρας οριζόντιου διαστήματος ASCII (0x20) είναι ο μόνος χαρακτήρας κενού χώρου που εμφανίζεται οπουδήποτε σε ένα αρχείο προέλευσης. Αυτό σημαίνει ότι… οι χαρακτήρες Tab δεν χρησιμοποιούνται για εσοχή.

Ο οδηγός καθορίζει αργότερα ότι πρέπει να χρησιμοποιήσετε δύο κενά (όχι τέσσερα) για εσοχή.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Απαιτούνται ερωτηματικά

Κάθε δήλωση πρέπει να τερματίζεται με ερωτηματικό. Απαγορεύεται η αυτόματη εισαγωγή ερωτηματικού.

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

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

Μην χρησιμοποιείτε μονάδες ES6 (ακόμη)

Μην χρησιμοποιείτε ακόμη τις ενότητες ES6 (δηλ. Τις λέξεις-κλειδιά exportκαι τις importλέξεις-κλειδιά), καθώς η σημασιολογία τους δεν έχει ακόμη ολοκληρωθεί. Λάβετε υπόψη ότι αυτή η πολιτική θα επανεξεταστεί μόλις η σημασιολογία είναι πλήρως τυπική.
// Don't do this kind of thing yet:
//------ lib.js ------export function square(x) { return x * x;}export function diag(x, y) { return sqrt(square(x) + square(y));}//------ main.js ------import { square, diag } from 'lib';

Η οριζόντια ευθυγράμμιση αποθαρρύνεται (αλλά δεν απαγορεύεται)

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

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

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

Μην χρησιμοποιείτε πια το var

Δηλώστε όλες τις τοπικές μεταβλητές είτε με constείτε let. Χρησιμοποιήστε το const από προεπιλογή, εκτός εάν πρέπει να εκχωρηθεί εκ νέου μια μεταβλητή. Η varλέξη-κλειδί δεν πρέπει να χρησιμοποιείται.

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

// badvar example = 42;
// goodlet example = 42;

Προτιμώνται οι λειτουργίες βέλους

Οι λειτουργίες βέλους παρέχουν μια συνοπτική σύνταξη και διορθώνουν ορισμένες δυσκολίες this. Προτιμήστε τις λειτουργίες βέλους από τη functionλέξη-κλειδί, ειδικά για ένθετες συναρτήσεις

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

// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});

Χρησιμοποιήστε συμβολοσειρές προτύπου αντί συνένωσης

Χρησιμοποιήστε συμβολοσειρές προτύπων (οριοθετημένες με `) πάνω από σύνθετες συνδυασμούς συμβολοσειρών, ειδικά εάν εμπλέκονται πολλαπλά γράμματα συμβολοσειρών. Οι συμβολοσειρές προτύπων μπορεί να εκτείνονται σε πολλές γραμμές.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}

Μην χρησιμοποιείτε συνεχείς γραμμές για μεγάλες χορδές

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

Είναι αρκετά ενδιαφέρον, αυτός είναι ένας κανόνας στον οποίο διαφωνούν η Google και η Airbnb (εδώ είναι η προδιαγραφή της Airbnb).

Ενώ η Google προτείνει να συνδυάσετε μεγαλύτερες χορδές (όπως φαίνεται παρακάτω) ο οδηγός στυλ της Airbnb συνιστά ουσιαστικά να μην κάνετε τίποτα και να επιτρέψετε στις μακρές χορδές να συνεχίσουν όσο χρειάζεται.

// bad (sorry, this doesn't show up well on mobile)const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.';
// goodconst longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';

«Για… από» είναι ο προτιμώμενος τύπος «για βρόχο»

Με το ES6, η γλώσσα έχει τώρα τρία διαφορετικά είδη forβρόχων. Όλοι μπορούν να χρησιμοποιηθούν, ωστόσο for- οι ofβρόχοι πρέπει να προτιμώνται όταν είναι δυνατόν.

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

Είχα πάντα την εντύπωση ότι οι for... inβρόχοι ήταν καλύτεροι για αντικείμενα, ενώ for... ofήταν πιο κατάλληλοι για συστοιχίες. Μια κατάσταση τύπου «σωστό εργαλείο για τη σωστή δουλειά».

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

Μην χρησιμοποιείτε το eval ()

Μην χρησιμοποιείτε evalή τον Function(...string)κατασκευαστή (εκτός από τους φορτωτές κώδικα). Αυτές οι δυνατότητες είναι δυνητικά επικίνδυνες και απλά δεν λειτουργούν σε περιβάλλον CSP.

Η σελίδα MDN για eval()ακόμη και έχει μια ενότητα που ονομάζεται "Μην χρησιμοποιείτε το eval!"

// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

Οι σταθερές πρέπει να ονομάζονται σε ALL_UPPERCASE διαχωρισμένες με κάτω παύλες

Χρησιμοποιούνται σταθερά ονόματα CONSTANT_CASE: όλα τα κεφαλαία γράμματα, με λέξεις διαχωρισμένες με κάτω παύλες.

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

Μια αξιοσημείωτη εξαίρεση σε αυτόν τον κανόνα είναι εάν η σταθερά καλύπτει τη λειτουργία. Σε αυτήν την περίπτωση θα πρέπει να γραφτεί σε camelCase.

// badconst number = 5;
// goodconst NUMBER = 5;

Μία μεταβλητή ανά δήλωση

Κάθε δήλωση τοπικής μεταβλητής δηλώνει μόνο μία μεταβλητή: δηλώσεις όπως let a = 1, b = 2;δεν χρησιμοποιούνται.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Χρησιμοποιήστε μεμονωμένα εισαγωγικά και όχι διπλά εισαγωγικά

Οι συνηθισμένες γραμματοσειρές συμβολοσειρών οριοθετούνται με μεμονωμένα εισαγωγικά ( ') και όχι με διπλά εισαγωγικά ( "). Συμβουλή: εάν μια συμβολοσειρά περιέχει έναν μοναδικό χαρακτήρα προσφοράς, σκεφτείτε να χρησιμοποιήσετε μια συμβολοσειρά προτύπου για να αποφύγετε να ξεφύγετε από την προσφορά.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Μια τελευταία σημείωση

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

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

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

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