JavaScript'teki özellik ve yöntem adları için alt çizgi öneki

JavaScript'teki alt çizgi öneki yalnızca Python özel sınıf yöntemlerinde olduğu gibi bir kural mıdır?

2.7 Python belgelerinden:

Bir nesnenin içinden erişilemeyen “özel” örnek değişkenleri Python'da mevcut değildir. Bununla birlikte, çoğu Python kodunun izlediği bir kural vardır: alt çizgi (örn. _Spam) önekine sahip bir ad, API'nın herkese açık olmayan bir parçası olarak ele alınmalıdır (bir işlev, yöntem veya veri üyesi olsun) .

Bu JavaScript için de geçerli mi?

Örneğin şu JavaScript kodunu ele alalım:

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

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

Ayrıca, alt çizgi önek değişkenleri kullanılır.

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

Sadece sözleşmeler mi? Veya alt çizgi önekinin arkasında daha fazlası var mı?

Sorumun bu soruya oldukça benzediğini itiraf ediyorum , ancak JavaScript'teki alt çizgi önekinin önemi hakkında daha akıllı bir şey yapmadı.

2019'a Hoşgeldiniz!

Ön ekli değişkenin özel olmasına izin vermek için sınıf sözdizimini genişletme önerisi# kabul edildi. 74 Chrome gemileri bu destekle.

_ ön ekli değişken adları kural gereği özel kabul edilir, ancak yine de herkese açıktır.

Bu sözdizimi, diğer programlama dillerinden oldukça farklı olmasına rağmen, hem kısa hem de sezgisel olmaya çalışır.

Tüm Unicode kod noktaları arasında neden sigil # seçildi?

• @ ilk favoriydi, ancak dekoratörler tarafından alındı. TC39, dekoratörleri ve özel durum imzalarını değiştirmeyi düşündü, ancak komite, transpiler kullanıcılarının mevcut kullanımını ertelemeye karar verdi.
• _, bir tanımlayıcı veya (genel) özellik adının başlangıcında uzun süre kullanılmasına izin veren mevcut JavaScript koduyla uyumluluk sorunlarına neden olur.

Bu teklif Temmuz 2017'de Aşama 3'e ulaştı. O zamandan beri çeşitli alternatifler hakkında kapsamlı düşünce ve uzun tartışmalar yapıldı. Sonuçta, bu düşünce süreci ve toplumun sürekli katılımı bu depodaki teklif üzerinde uzlaşmaya varılmasını sağlamıştır. Bu fikir birliğine dayanarak, uygulamalar bu öneri üzerinde ilerlemektedir.

Bkz. Https://caniuse.com/#feat=mdn-javascript_classes_private_class_fields

Bu sadece bir kongre. Javascript dili, alt çizgi karakterleriyle başlayan tanımlayıcılara özel bir anlam vermez.

Bununla birlikte, kutunun dışında kapsüllenmeyi desteklemeyen bir dil için oldukça kullanışlı bir kural . Birinin sınıflarınızın uygulamalarını kötüye kullanmasını engellemenin bir yolu olmasa da, en azından niyetinizi açıklığa kavuşturur ve ilk etapta yanlış gibi davranışı belgeler .

JavaScript aslında üyelerin kapanışta gizlenmesini içeren bir yöntemle (Crockford) kapsüllemeyi destekler . Bununla birlikte, bazen hantal ve alt çizgi konvansiyonu, bir tür özel olan şeyler için kullanmak için oldukça iyi bir kongre, ancak aslında saklamanız gerekmediğini söyledi.

JSDoc 3, niyetinizi diğer geliştiricilere yayınlamak için de yararlı olan @access private(önceden @privateetiketi) ile işlevlerinize açıklama eklemenizi sağlar - http://usejsdoc.org/tags-access.html

"Sadece sözleşmeler mi? Yoksa alt çizgi önekinin arkasında daha fazlası var mı?"

Gizlilik sözleşmelerinin yanı sıra, alt çizgi önekinin bağımsız olarak bağımsız değişkenlere bağımlı argümanlar için, özellikle de URI bağlantı haritalarında da kullanıldığı konusunda farkındalık getirmek istedim. Bağımlı tuşlar her zaman bir haritayı gösterir.

Örnek ( https://github.com/mmikowski/urianchor adresinden ):

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

Tarayıcı arama alanındaki URI bağlantısı şu şekilde değiştirilir:

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

Bu, karma değişikliklere dayalı bir uygulama durumunu sürmek için kullanılan bir kuraldır.

import/exportşimdi ES6 ile işi yapıyor. İşlevlerimin _çoğu dışa aktarılırsa, hala dışa aktarılmayan işlevlerin önekini kullanmaya eğilimliyim .

Yalnızca bir sınıfı (açısal projelerde olduğu gibi) dışa aktarırsanız, buna hiç gerek yoktur.

export class MyOpenClass{

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

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

}

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