Prefiks podkreślenia dla nazw właściwości i metod w JavaScript

Czy prefiks podkreślenia w JavaScript jest tylko konwencją, jak na przykład w metodach klasy prywatnej Python?

Z dokumentacji języka Python 2.7:

„Prywatne” zmienne instancji, do których dostęp jest możliwy tylko z wnętrza obiektu, nie istnieją w Pythonie. Istnieje jednak konwencja, po której następuje większość kodu w języku Python: nazwa poprzedzona znakiem podkreślenia (np. _Spam) powinna być traktowana jako niepubliczna część interfejsu API (niezależnie od tego, czy jest to funkcja, metoda czy element danych) .

Czy dotyczy to również JavaScript?

Weźmy na przykład ten kod JavaScript:

function AltTabPopup() {
    this._init();
}

AltTabPopup.prototype = {
    _init : function() {
        ...
    }
}

Wykorzystywane są również zmienne z prefiksem podkreślenia.

    ...
    this._currentApp = 0;
    this._currentWindow = -1;
    this._thumbnailTimeoutId = 0;
    this._motionTimeoutId = 0;
    ...

Tylko konwencje? A może kryje się za tym prefiks?

Przyznaję, że moje pytanie jest dość podobne do tego pytania , ale nie uczyniło to mądrzejszego o znaczeniu prefiksu podkreślenia w JavaScript.

Witamy w 2019 roku!

Wydaje się, że zaakceptowano propozycję rozszerzenia składni klasy, aby pozwolić, aby #zmienna z prefiksem była prywatna. Chrome 74 jest dostarczany z tym wsparciem.

_ Prefiksowane nazwy zmiennych są z reguły uważane za prywatne, ale nadal są publiczne.

Ta składnia stara się być zwięzła i intuicyjna, chociaż różni się raczej od innych języków programowania.

Dlaczego sigil # został wybrany spośród wszystkich punktów kodu Unicode?

• @ był początkowym ulubieńcem, ale został wzięty przez dekoratorów. TC39 zastanawiał się nad wymianą dekoratorów i pieczęci państwowych, ale komitet postanowił odroczyć się do obecnego wykorzystania użytkowników transpilerów.
• _ spowodowałoby problemy z kompatybilnością z istniejącym kodem JavaScript, co pozwoliło _ na początku identyfikatora lub (publicznej) nazwy właściwości przez długi czas.

Ta propozycja osiągnęła etap 3 w lipcu 2017 r. Od tego czasu trwa wiele przemyśleń i długa dyskusja na temat różnych alternatyw. Ostatecznie ten proces myślowy i ciągłe zaangażowanie społeczności doprowadziły do ​​odnowienia konsensusu w sprawie wniosku w tym repozytorium. W oparciu o ten konsensus wdrażanie tego wniosku jest kontynuowane.

Zobacz https://caniuse.com/#feat=mdn-javascript_classes_private_class_fields

To tylko konwencja. Język JavaScript nie nadaje żadnego specjalnego znaczenia identyfikatorom rozpoczynającym się od znaków podkreślenia.

To powiedziawszy, jest to dość przydatna konwencja dla języka, który nie obsługuje enkapsulacji po wyjęciu z pudełka. Chociaż nie ma sposobu, aby zapobiec nadużywaniu implementacji twoich klas, przynajmniej wyjaśnia twoje zamiary i przede wszystkim dokumentuje takie zachowanie jako niewłaściwe .

JavaScript faktycznie obsługuje enkapsulację, za pomocą metody polegającej na ukrywaniu członków w zamknięciach (Crockford). To powiedziawszy, czasami jest kłopotliwe, a konwencja podkreślenia jest całkiem dobrą konwencją do użytku w przypadku rzeczy, które są w pewnym sensie prywatne, ale których tak naprawdę nie trzeba ukrywać.

JSDoc 3 umożliwia dodawanie adnotacji do funkcji za pomocą @access private(poprzednio @privatetagu), co jest również przydatne do rozpowszechniania swoich zamiarów wśród innych programistów - http://usejsdoc.org/tags-access.html

„Tylko konwencje? A może kryje się za tym prefiks?”

Oprócz konwencji dotyczących prywatności chciałem również pomóc uświadomić, że przedrostek podkreślenia jest również używany w przypadku argumentów zależnych od niezależnych argumentów, szczególnie w mapach kotwiczenia URI. Klucze zależne zawsze wskazują mapę.

Przykład (z https://github.com/mmikowski/urianchor ):

$.uriAnchor.setAnchor({
  page   : 'profile',
  _page  : {
    uname   : 'wendy',
    online  : 'today'
  }
});

Kotwica URI w polu wyszukiwania przeglądarki jest zmieniana na:

\#!page=profile:uname,wendy|online,today

Jest to konwencja używana do sterowania stanem aplikacji na podstawie zmian skrótu.

import/exportwykonuje teraz pracę z ES6. Nadal mam tendencję do prefiksu funkcji nieeksportowanych_ jeśli większość moich funkcji jest eksportowana.

Jeśli eksportujesz tylko klasę (jak w projektach kątowych), nie jest ona wcale potrzebna.

export class MyOpenClass{

    open(){
         doStuff()
         this._privateStuff()
         return close();
    }

    _privateStuff() { /* _ only as a convention */} 

}

function close(){ /*... this is really private... */ }