En Javascript, que signifie ce trait de soulignement ?

Question

var Gallery = Backbone.Controller.extend({
    _index: null,
    _photos: null,
    _album :null,
    _subalbums:null,
    _subphotos:null,
    _data:null,
    _photosview:null,
    _currentsub:null,
    routes: {
        "": "index",
        "subalbum/:id": "subindex",
        "subalbum/:id/" : "directphoto",
        "subalbum/:id/:num" : "hashphoto"
    },
    initialize: function(options) {
        var ws = this;
        if (this._index === null){
            $.ajax({
                url: 'data/album1.json',
                dataType: 'json',
                data: {},
                success: function(data) {
                    ws._data = data;
                    ws._photos =
                    new PhotoCollection(data);
                    ws._index =
                    new IndexView({model: ws._photos});
                    Backbone.history.loadUrl();
                }
            });
            return this;
        }
        return this;
    },
    //Handle rendering the initial view for the
    //application
    index: function() {
        this._index.render();
    },

Je suis en train de lire un tutoriel sur backbone.js ici : http://addyosmani.com/blog/building-spas-jquerys-best-friends/

Que sont les underscores ? (_index, _photos, _album) Pourquoi les utiliser ?

Answer 1

Il s'agit d'un léger addendum. Comme déjà répondu, il s'agit de pseudo variables privées. Mais il est alors possible d'écrire des pseudo-fonctions publiques qui accèdent à ces variables privées.

J'ai été troublé par le code d'un collègue qui a effectivement cela (mais enfoui très profondément dans une bibliothèque séparée) :

class x { 
  constructor(id) {this._id = id} 
  get id() {return this._id}
}
let y = new x(3)

Maintenant vous avez les deux y.id y y._id qui fonctionnent et renvoient la même valeur. Mais si vous faites console.log(y) il n'affiche que le _id clé.

Answer 2

Comme nous l'avons mentionné, il s'agit d'une pratique courante chez de nombreux développeurs, une mauvaise pratique d'ailleurs. Si vous devez recourir à de telles conventions dans vos méthodes de programmation, vous devriez apprendre le langage, les méthodes et les modèles avant d'essayer d'utiliser le langage. Si quelqu'un ne peut pas distinguer les méthodes publiques/privées dans votre code sans l'utilisation du "underscore", alors vos compétences en matière de documentation sont extrêmement faibles. De nombreux projets publics sur le Web sont très mal documentés, ce qui explique probablement pourquoi les conventions "underscore" ont été "acceptées" par la plupart des développeurs peu instruits, tandis que d'autres ont décidé de suivre le courant plutôt que de conserver les modèles et méthodes de conception formels. Il y a une raison pour laquelle "underscore" n'a pas été intégré dans les versions ES6/7.

Dans un blog, je suis récemment tombé sur un responsable d'un ingénieur logiciel qui a déclaré : " La convention de dénomination par soulignement permet de déterminer facilement, au premier coup d'œil, si une fonction variable est destinée à être publique ou privée. ". Ma réponse est la suivante : " Les commentaires sont comme les images, dans ce cas ils valent mille soulignés ".

Il existe un outil de documentation gratuit appelé Doxygen. Bien qu'il ne prenne pas spécifiquement en charge JavaScript, il peut générer une documentation professionnelle pour vos applications JavaScript lorsque vous utilisez les préfixes Doxygen dans vos commentaires. Il est vraiment simple de créer des applications JavaScript avec de la documentation, tant pour les développeurs que pour les utilisateurs, lorsque vous faites un petit effort dans vos commentaires de code.

N'oubliez pas qu'il existe des outils qui permettent de supprimer les commentaires et les instructions de la console pour les "versions de production". Ceci étant dit, l'utilisation de cartes de sources est également une perte de temps et de ressources. Ne réduisez pas le code avant d'être prêt à publier, c'est-à-dire Dev Build (pas de réduction, conservez les commentaires et les instructions de la console), Release Build (supprimez les commentaires et les instructions de la console et réduisez le code Dev Build. Il n'est pas nécessaire de recompiler le Dev Build lorsque le code est de qualité release, il suffit de le préparer pour la release et de le déployer).