Konwencje nazewnicze JavaScriptu

Wprowadzenie do konwencji nazewniczych JavaScriptu na przykładzie — które daje zdrowy rozsądek jeśli chodzi o nazewnictwo zmiennych, funkcji, klas lub komponentów w JavaScripcie. Nikt nie egzekwuje tych reguł konwencji nazewnictwa, jednakże są one powszechnie akceptowane jako standard w społeczności JS.

Konwencje nazewnictwa w JavaScript: Zmienne

Zmienne JavaScript rozróżniają wielkość liter. Dlatego zmienne JavaScript z małymi i dużymi literami są różne:

 var name = 'Robin Wieruch'; 
 
 var Name = 'Dennis Wieruch'; 
 
 var NAME = 'Thomas Wieruch'; 
 
 console.log(name); 
 // "Robin Wieruch" 
 
 console.log(Name); 
 // "Dennis Wieruch" 
 
 console.log(NAME); 
 // "Thomas Wieruch" 
Zmienna JavaScript powinna być samoopisowa. Nie powinno być konieczne dodawanie komentarza dla dodatkowej dokumentacji do zmiennej:
 // bad 
 var value = 'Robin'; 
 
 // bad 
 var val = 'Robin'; 
 
 // good 
 var firstName = 'Robin'; 
Najczęściej można spotkać zmienne JavaScript zadeklarowane z nazwą zmiennej camelCase z wiodącym znakiem małej litery:
 // bad 
 var firstname = 'Robin'; 
 
 // bad 
 var first_name = 'Robin'; 
 
 // bad 
 var FIRSTNAME = 'Robin'; 
 
 // bad 
 var FIRST_NAME = 'Robin'; 
 
 // good 
 var firstName = 'Robin'; 
Istnieją wyjątki dla stałych JavaScript, prywatnych oraz klas/komponentów — które zbadamy później. Jednakże, ogólnie rzecz biorąc, zmienna w JavaScript — łańcuch, boolean lub liczba, ale także obiekt, tablica lub funkcja — jest deklarowana z nazwą zmiennej w camelCase.
Krótki przegląd różnych stylów wielkości liter:

camelCase (używany w JS)
PascalCase (używany w JS)
snake_case
kebab-case

Konwencje nazewnictwa w JavaScript: Boolean
Przedrostek taki jak is, are, lub has pomaga każdemu programiście JavaScript odróżnić boolean od innej zmiennej przez samo spojrzenie na nią:
 // bad 
 var visible = true; 
 
 // good 
 var isVisible = true; 
 
 // bad 
 var equal = false; 
 
 // good 
 var areEqual = false; 
 
 // bad 
 var encryption = true; 
 
 // good 
 var hasEncryption = true; 
W przeciwieństwie do łańcuchów i liczb całkowitych, można to postrzegać jako kolejną miękką regułę dla konwencji nazewnictwa boolean w JavaScript poza tym, że jest pisana w camel case.
Konwencje nazewnictwa JavaScript: Function
Funkcje JavaScript są również pisane w camel case. Dodatkowo, najlepszą praktyką jest mówienie co funkcja robi poprzez nadanie nazwie funkcji czasownika jako prefiksu.
 // bad 
 function name(firstName, lastName) { 
 return `${firstName} ${lastName}`; 
 } 
 
 // good 
 function getName(firstName, lastName) { 
 return `${firstName} ${lastName}`; 
 } 

Tym czasownikiem jako prefiksem może być cokolwiek (np. get, fetch, push, apply, calculate, compute, post). Jest to kolejna miękka zasada do rozważenia dla posiadania bardziej samoopisowych zmiennych JavaScript.
Konwencje nazewnictwa JavaScript: Klasa
Klasa JavaScript jest deklarowana z PascalCase, w przeciwieństwie do innych struktur danych JavaScript:
 class SoftwareDeveloper { 
 constructor(firstName, lastName) { 
 this.firstName = firstName; 
 this.lastName = lastName; 
 } 
 } 
 
 var me = new SoftwareDeveloper('Robin', 'Wieruch'); 
Za każdym razem gdy konstruktor JavaScript jest wywoływany do instantyzacji nowej instancji klasy, nazwa klasy powinna pojawić się w Pascal Case, ponieważ klasa została zadeklarowana z Pascal Case w pierwszej kolejności.
 Konwencje nazewnictwa JavaScript: Komponent
Komponenty nie są wszędzie w JavaScript, ale powszechnie występują we frameworkach frontendowych takich jak React. Ponieważ komponent jest jakby instancjonowany — ale zamiast tego dołączany do DOM — jak klasa JavaScript, są one powszechnie deklarowane również za pomocą Pascal Case.
 // bad 
 function userProfile(user) { 
 return ( 
 <div> 
 <span>First Name: {user.firstName}</span> 
 <span>Last Name: {user.lastName}</span> 
 </div> 
 ); 
 } 
 
 // good 
 function UserProfile(user) { 
 return ( 
 <div> 
 <span>First Name: {user.firstName}</span> 
 <span>Last Name: {user.lastName}</span> 
 </div> 
 ); 
 } 
Kiedy komponent jest używany, odróżnia się od natywnych komponentów HTML i webowych, ponieważ jego pierwsza litera jest zawsze pisana wielkimi literami.
 <div> 
 <UserProfile 
 user={{ firstName: 'Robin', lastName: 'Wieruch' }} 
 /> 
 </div> 
Konwencje nazewnicze JavaScript: Methods
Tożsamo jak funkcje JavaScript, metoda w klasie JavaScript jest zadeklarowana z camelCase:
 class SoftwareDeveloper { 
 constructor(firstName, lastName) { 
 this.firstName = firstName; 
 this.lastName = lastName; 
 } 
 
 getName() { 
 return `${this.firstName} ${this.lastName}`; 
 } 
 } 
 
 var me = new SoftwareDeveloper('Robin', 'Wieruch'); 
 
 console.log(me.getName()); 
 // "Robin Wieruch" 
Mają tu zastosowanie te same zasady co dla funkcji JavaScript — np. dodanie czasownika jako prefiksu — dla uczynienia nazwy metody bardziej samoopisową.
Konwencje nazewnictwa JavaScript: Private
Rzadko można znaleźć podkreślnik (_) przed zmienną/funkcją/metodą w JavaScript. Jeśli go zobaczysz, oznacza to, że ma być on prywatny. Nawet jeśli nie może to być naprawdę wymuszone przez JavaScript, deklarowanie czegoś jako prywatne mówi nam o tym, jak to powinno być używane lub jak nie powinno być używane.

Na przykład, prywatna metoda w klasie powinna być używana tylko wewnętrznie przez klasę, ale powinno się unikać używania jej na instancji klasy:
 class SoftwareDeveloper { 
 constructor(firstName, lastName) { 
 this.firstName = firstName; 
 this.lastName = lastName; 
 this.name = _getName(firstName, lastName); 
 } 
 
 _getName(firstName, lastName) { 
 return `${firstName} ${lastName}`; 
 } 
 } 
 
 var me = new SoftwareDeveloper('Robin', 'Wieruch'); 
 
 // good 
 var name = me.name; 
 console.log(name); 
 // "Robin Wieruch" 
 
 // bad 
 name = me._getName(me.firstName, me.lastName); 
 console.log(name); 
 // "Robin Wieruch" 
Prywatna zmienna/funkcja może również wystąpić w pliku JavaScript. Może to oznaczać, że zmienna/funkcja nie powinna być używana poza tym plikiem, a jedynie wewnętrznie do obliczania dalszej logiki biznesowej dla innych funkcji w tym samym pliku..
Konwencje nazewnictwa JavaScript: Stałe
Ostatnie, ale nie mniej ważne, są stałe — przeznaczone do bycia niezmieniającymi się zmiennymi — w JavaScript, które są pisane wielkimi literami (UPPERCASE):
 var SECONDS = 60; 
 var MINUTES = 60; 
 var HOURS = 24; 
 
 var DAY = SECONDS * MINUTES * HOURS; 
Jeśli zmienna ma więcej niż jedno słowo w swojej nazwie deklaracji zmiennej, używa podkreślnika (_):
 var DAYS_UNTIL_TOMORROW = 1; 
Zwykle stałe JavaScript są definiowane na górze pliku JavaScript. Jak wspomniano wcześniej, nikt nie wymusza, aby nie zmieniać zmiennej w tym miejscu, z wyjątkiem deklaracji const zmiennej dla prymitywnych struktur danych, ale jej nazewnictwo pisane wielką literą sugeruje unikanie tego.
Konwencje nazewnictwa JavaScript: Zmienna globalna
Zmienna JavaScript jest zdefiniowana globalnie, jeśli cały jej kontekst ma do niej dostęp. Często kontekst jest definiowany przez plik JavaScript, w którym zmienna jest zadeklarowana/zdefiniowana, ale w mniejszych projektach JavaScript może to być cały projekt. Nie ma specjalnych konwencji nazewnictwa dla zmiennych globalnych JavaScript.

Zmienna globalna JavaScript jest deklarowana na górze projektu/pliku.
Zmienna globalna JavaScript jest pisana w camelCase jeśli jest mutowalna.
Zmienna globalna JavaScript jest pisana w UPPERCASE jeśli jest niezmienna.

Konwencje nazewnictwa JavaScript: Underscore
Co zatem z podkreślnikiem i myślnikiem w nazewnictwie zmiennych JavaScript? Ponieważ camelCase i PascalCase są głównie rozważane w JS, zauważyłeś, że podkreślnik jest rzadko używany dla prywatnych zmiennych lub stałych. Sporadycznie można spotkać podkreślenia przy pobieraniu informacji od stron trzecich, takich jak bazy danych lub API. Innym scenariuszem, gdzie możesz zobaczyć podkreślenie są nieużywane parametry funkcji, ale nie martw się o nie, jeśli jeszcze ich nie widziałeś 😉
Konwencje nazewnictwa JavaScript: Myślnik
Kreska w zmiennej JavaScript również nie jest zdroworozsądkowa. To tylko utrudnia sprawy; jak na przykład użycie go w obiekcie:
 // bad 
 var person = { 
 'first-name': 'Robin', 
 'last-name': 'Wieruch', 
 }; 
 
 var firstName = person; 
 
 // good 
 var person = { 
 firstName: 'Robin', 
 lastName: 'Wieruch', 
 }; 
 
 var firstName = person.firstName; 
Nie jest nawet możliwe użycie myślnika bezpośrednio w deklaracji zmiennej:
 var first-name = 'Robin'; 
 // Uncaught SyntaxError: Unexpected token '-' 
Dlatego lepiej ich unikać.
Konwencje nazewnicze JavaScript: Pliki
Istnieją dwie strategie nazywania plików w JavaScript: PascalCase i kebab-case. W aplikacjach frontendowych JavaScript, często można zobaczyć PascalCase do nazywania komponentów (np. komponentów React).
 - components/ 
 --- user/ 
 ----- UserProfile.js 
 ----- UserList.js 
 ----- UserItem.js 
 --- ui/ 
 ----- Dialog.js 
 ----- Dropdown.js 
 ----- Table.js 
W przeciwieństwie do tego, w JavaScript backend application, kebab-case jest zdrowym rozsądkiem:
 - routing/ 
 --- user-route.js 
 --- messages-route.js 
Zobaczysz też nazewnictwo camelCase, ale podobnie jak w przypadku PascalCase (przepraszam aplikacje frontendowe), istnieje ryzyko, że systemy operacyjne różnie je obsługują, co może prowadzić do bugów. Dlatego właśnie trzymanie się kebab-case powinno być normą dla nazw plików w JavaScript.
Jeśli chcesz dowiedzieć się więcej o stylu i formatowaniu kodu JavaScript, który nie jest tutaj omawiany ze względu na konwencje nazewnictwa, powinieneś zdecydowanie sprawdzić ESLint i Prettier for JavaScript.