Χρησιμοποιείτε πάντα τις ίδιες συμβάσεις κωδικοποίησης για όλα τα JavaScript σας έργα.
Οι συμβάσεις κωδικοποίησης είναι οδηγίες στυλ προγραμματισμού. Συνήθως καλύπτουν:
Κανόνες ονομασίας και δήλωσης για μεταβλητές και συναρτήσεις.
Κανόνες για τη χρήση του λευκού διαστήματος, των εσοχών και των σχολίων.
Πρακτικές και αρχές προγραμματισμού.
Οι συμβάσεις κωδικοποίησης ασφαλούς ποιότητας:
Βελτιώστε την αναγνωσιμότητα κώδικα
Κάντε τη συντήρηση του κώδικα ευκολότερη
Οι συμβάσεις κωδικοποίησης μπορούν να είναι τεκμηριωμένοι κανόνες που πρέπει να ακολουθούν οι ομάδες ή απλώς να είναι η ατομική σας πρακτική κωδικοποίησης.
Αυτή η σελίδα περιγράφει τις γενικές συμβάσεις κώδικα JavaScript που χρησιμοποιούνται από το W3Schools.
Θα πρέπει επίσης να διαβάσετε το επόμενο κεφάλαιο "Βέλτιστες πρακτικές" και να μάθετε πώς να αποφύγετε παγίδες κωδικοποίησης.
Στο W3schools χρησιμοποιούμε το camelCase για ονόματα αναγνωριστικών (μεταβλητές και συναρτήσεις).
Όλα τα ονόματα ξεκινούν με ένα γράμμα.
Στο κάτω μέρος αυτής της σελίδας, θα βρείτε μια ευρύτερη συζήτηση σχετικά με την ονομασία κανόνες.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);Να βάζετε πάντα κενά γύρω από τους τελεστές (=+ - */) και μετά τα κόμματα:
let x = y + z;
const myArray = ["Volvo", "Saab",
"Fiat"];Να χρησιμοποιείτε πάντα 2 κενά για την εσοχή των μπλοκ κώδικα:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}Μη χρησιμοποιείτε καρτέλες (tabulators) για εσοχές. Διαφορετικοί συντάκτες ερμηνεύουν διαφορετικά τις καρτέλες.
Γενικοί κανόνες για απλές δηλώσεις:
Τελειώνετε πάντα μια απλή δήλωση με ερωτηματικό.
const cars = ["Volvo", "Saab",
"Fiat"];
const person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};Γενικοί κανόνες για σύνθετες (σύνθετες) δηλώσεις:
Βάλτε το στήριγμα ανοίγματος στο τέλος της πρώτης γραμμής.
Χρησιμοποιήστε ένα κενό πριν το ανοιγόμενο στήριγμα.
Τοποθετήστε το στήριγμα κλεισίματος σε νέα γραμμή, χωρίς κενά.
Μην τελειώνετε μια σύνθετη πρόταση με ερωτηματικό.
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}for (let i = 0; i < 5; i++) {
x += i;
}if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}Γενικοί κανόνες για ορισμούς αντικειμένων:
Τοποθετήστε το στήριγμα ανοίγματος στην ίδια γραμμή με το όνομα του αντικειμένου.
Χρησιμοποιήστε άνω και κάτω τελεία συν ένα κενό μεταξύ κάθε ιδιότητας και της τιμής της.
Χρησιμοποιήστε εισαγωγικά γύρω από τιμές συμβολοσειράς, όχι γύρω από αριθμητικές τιμές.
Μην προσθέτετε κόμμα μετά το τελευταίο ζεύγος ιδιότητας-τιμής.
Τοποθετήστε το στήριγμα κλεισίματος σε μια νέα γραμμή, χωρίς οδηγούς χώρους.
Τελειώνετε πάντα έναν ορισμό αντικειμένου με ερωτηματικό.
Τα σύντομα αντικείμενα μπορούν να γραφτούν συμπιεσμένα, σε μία γραμμή, χρησιμοποιώντας μόνο κενά μεταξύ ιδιοτήτων, όπως αυτό:
Για αναγνωσιμότητα, αποφύγετε γραμμές μεγαλύτερες από 80 χαρακτήρες.
Εάν μια δήλωση JavaScript δεν χωράει σε μία γραμμή, το καλύτερο μέρος για να σπάσετε είναι μετά από έναν τελεστή ή ένα κόμμα.
document.getElementById("demo").innerHTML =
"Hello Dolly.";Δοκιμάστε το μόνοι σας →
<!DOCTYPE html>
<html>
<body>
<h2>My Web Page</h2>
<p>The best place to break a code line is after an operator or a comma.</p>
<p id="demo"></p>
<script>
document.getElementById("demo").innerHTML =
"Hello Dolly.";
</script>
</body>
</html>
Χρησιμοποιείτε πάντα την ίδια σύμβαση ονομασίας για όλο τον κώδικά σας. Για παράδειγμα:
Τα ονόματα μεταβλητών και συναρτήσεων γράφονται ως camelCase
Καθολικές μεταβλητές γραμμένες με ΚΕΦΑΛΑΙΑ (Δεν το κάνουμε, αλλά είναι αρκετά_συχνό)
Σταθερές (όπως PI) γραμμένες με ΚΕΦΑΛΑΙΑ
Εάν χρησιμοποιείτε hyp-hens, camelCase ή under_scores σε ονόματα μεταβλητών;
Αυτό είναι ένα ερώτημα που συζητούν συχνά οι προγραμματιστές. Η απάντηση εξαρτάται από το ποιος είσαι παρακαλώ:
ενωτικά σε HTML και CSS:
Τα χαρακτηριστικά HTML5 μπορούν να ξεκινούν με data- (data-quantity, data-price).
Το CSS χρησιμοποιεί παύλες στα ονόματα ιδιοτήτων (μέγεθος γραμματοσειράς).
Οι παύλες μπορεί να θεωρηθούν λανθασμένες ως προσπάθειες αφαίρεσης. Οι παύλες δεν επιτρέπονται στα ονόματα JavaScript.
Υπογράμμιση:
Πολλοί προγραμματιστές προτιμούν να χρησιμοποιούν υπογράμμιση (date_of_birth), ειδικά σε SQL βάσεις δεδομένων.
Οι υπογραμμίσεις χρησιμοποιούνται συχνά στην τεκμηρίωση της PHP.
PascalCase:
Το PascalCase προτιμάται συχνά από προγραμματιστές C.
camelCase:
Το camelCase χρησιμοποιείται από την ίδια τη JavaScript, από το jQuery και άλλα JavaScript βιβλιοθήκες.
Μην ξεκινάτε τα ονόματα με το σύμβολο $. Θα σας φέρει σε σύγκρουση με πολλά ονόματα βιβλιοθηκών JavaScript.
Χρησιμοποιήστε απλή σύνταξη για τη φόρτωση εξωτερικών σεναρίων (το χαρακτηριστικό type δεν είναι απαραίτητη):
<script src="myscript.js"></script>Μια συνέπεια της χρήσης "ακατάστατων" στυλ HTML, μπορεί να οδηγήσει σε σφάλματα JavaScript.
Αυτές οι δύο δηλώσεις JavaScript θα παράγουν διαφορετικά αποτελέσματα:
const obj = getElementById("Demo")
const obj = getElementById("demo")Εάν είναι δυνατόν, χρησιμοποιήστε την ίδια σύμβαση ονομασίας (όπως η JavaScript) σε HTML.
Επισκεφτείτε τον Οδηγό στυλ HTML.
Τα αρχεία HTML θα πρέπει να έχουν επέκταση .html (επιτρέπεται το .htm). <p>Τα αρχεία CSS θα πρέπει να έχουν επέκταση .css.
Τα αρχεία JavaScript θα πρέπει να έχουν επέκταση .js.
Οι περισσότεροι διακομιστές ιστού (Apache, Unix) κάνουν διάκριση πεζών-κεφαλαίων σχετικά με τα ονόματα αρχείων:
Το london.jpg δεν είναι προσβάσιμο ως London.jpg.
Άλλοι διακομιστές ιστού (Microsoft, IIS) δεν κάνουν διάκριση πεζών-κεφαλαίων:
Το london.jpg μπορεί να προσπελαστεί ως London.jpg ή london.jpg.
Εάν χρησιμοποιείτε ένα συνδυασμό κεφαλαίων και πεζών, πρέπει να είστε εξαιρετικά σταθερός.
Εάν μετακινηθείτε από διακομιστή χωρίς διάκριση πεζών-κεφαλαίων, σε διακομιστή με διάκριση πεζών-κεφαλαίων, έστω και μικρού μεγέθους σφάλματα μπορεί να σπάσουν τον ιστότοπό σας.
Για να αποφύγετε αυτά τα προβλήματα, χρησιμοποιείτε πάντα ονόματα αρχείων με πεζά γράμματα (αν είναι δυνατόν).
Οι συμβάσεις κωδικοποίησης δεν χρησιμοποιούνται από υπολογιστές. Οι περισσότεροι κανόνες έχουν μικρή επίδραση στην εκτέλεση των προγραμμάτων.
Οι εσοχές και τα επιπλέον κενά δεν είναι σημαντικά σε μικρά σενάρια.
Για κώδικα υπό ανάπτυξη, θα πρέπει να προτιμάται η αναγνωσιμότητα. Μεγαλύτερη παραγωγή τα σενάρια πρέπει να ελαχιστοποιηθούν.