Souligner le préfixe des noms de propriété et de méthode en JavaScript

Le préfixe de soulignement en JavaScript n'est-il qu'une convention, comme par exemple dans les méthodes de classe privée Python?

De la documentation 2.7 Python:

Les variables d'instance «privées» auxquelles on ne peut accéder que depuis l'intérieur d'un objet n'existent pas en Python. Cependant, il existe une convention qui est suivie par la plupart du code Python: un nom préfixé avec un trait de soulignement (par exemple _spam) doit être traité comme une partie non publique de l'API (qu'il s'agisse d'une fonction, d'une méthode ou d'un membre de données) .

Est-ce que cela s'applique également à JavaScript?

Prenons par exemple ce code JavaScript:

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

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

En outre, des variables préfixées de soulignement sont utilisées.

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

Seules les conventions? Ou y a-t-il plus derrière le préfixe de soulignement?

J'admets que ma question est assez similaire à cette question , mais cela n'a pas rendu plus intelligent la signification du préfixe de soulignement dans JavaScript.

Bienvenue en 2019!

Il semble qu'une proposition visant à étendre la syntaxe des classes afin de permettre aux #variables préfixées d'être privées a été acceptée. Chrome 74 est livré avec ce support.

_ Les noms de variable préfixés sont considérés comme privés par convention mais restent publics.

Cette syntaxe essaie d'être à la fois concise et intuitive, bien qu'elle soit plutôt différente des autres langages de programmation.

Pourquoi le sigil # a-t-il été choisi, parmi tous les points de code Unicode?

• @ était le favori initial, mais il a été pris par les décorateurs. TC39 a envisagé d'échanger des décorateurs et des sceaux d'État privés, mais le comité a décidé de s'en remettre à l'utilisation actuelle des utilisateurs de transpilateurs.
• _ causerait des problèmes de compatibilité avec le code JavaScript existant, ce qui a permis _ au début d'un identifiant ou d'un nom de propriété (public) pendant longtemps.

Cette proposition est parvenue à l'étape 3 en juillet 2017. Depuis lors, il y a eu une réflexion approfondie et de longues discussions sur les différentes alternatives. En fin de compte, ce processus de réflexion et l'engagement continu de la communauté ont conduit à un consensus renouvelé sur la proposition dans ce référentiel. Sur la base de ce consensus, les mises en œuvre progressent sur cette proposition.

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

Ce n'est qu'une convention. Le langage Javascript ne donne aucune signification particulière aux identifiants commençant par des caractères de soulignement.

Cela dit, c'est une convention assez utile pour un langage qui ne prend pas en charge l' encapsulation hors de la boîte. Bien qu'il n'y ait aucun moyen d'empêcher quelqu'un d'abuser des implémentations de vos classes, au moins cela clarifie votre intention et documente un tel comportement comme étant mauvais en premier lieu.

JavaScript prend en charge l'encapsulation, grâce à une méthode qui implique de masquer les membres dans les fermetures (Crockford). Cela dit, c'est parfois lourd, et la convention de soulignement est une assez bonne convention à utiliser pour des choses qui sont en quelque sorte privées, mais que vous n'avez pas vraiment besoin de cacher.

JSDoc 3 vous permet d'annoter vos fonctions avec le @access private(précédemment le @privatetag) qui est également utile pour diffuser votre intention à d'autres développeurs - http://usejsdoc.org/tags-access.html

"Seulement des conventions? Ou y a-t-il plus derrière le préfixe de soulignement?"

Outre les conventions de confidentialité, je voulais également aider à faire prendre conscience que le préfixe de soulignement est également utilisé pour les arguments qui dépendent d'arguments indépendants, en particulier dans les cartes d'ancrage URI. Les clés dépendantes pointent toujours vers une carte.

Exemple (sur https://github.com/mmikowski/urianchor ):

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

L'ancre URI du champ de recherche du navigateur est remplacée par:

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

Il s'agit d'une convention utilisée pour piloter un état d'application basé sur des modifications de hachage.

import/exportfait maintenant le travail avec ES6. J'ai toujours tendance à préfixer les fonctions non exportées avec _si la plupart de mes fonctions sont exportées.

Si vous exportez uniquement une classe (comme dans les projets angulaires), ce n'est pas du tout nécessaire.

export class MyOpenClass{

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

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

}

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