Discussion :

[Kaamo]

Coloration en fonction de la portée des variables,
une alternative à la coloration syntaxique

On connait tous la coloration syntaxique liée à la syntaxe du langage afin d'améliorer la lisibilité de notre code pour mieux l'appréhender.
Mais parfois, ne serait-il pas mieux de surligner le code en fonction de la portée des variables plutôt que de mettre en valeur la syntaxe ?

C'est une idée proposée à la base par Douglas Crockford (JSON, JSLint) via un post sur Google+. C'est d'ores et déjà intégré à JSLint (plus de détails sur l'utilisation dans le post de D. Crockford) et Daniel Lamb (un ingénieur Front-End) propose une mise en application.

Voici un exemple avec quatre niveaux d'imbrications.

Coloration syntaxique :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
var monNameSpace = (function () {
  var maVar;
  maVar = "scope 1";
 
  var direBonjour = function() {
    console.log(maVar);
  };
 
  return {
    setMaVar: function(valeur){
      maVar = valeur;
    },
 
    getMaVar: function(){
      return maVar;
    },
 
    log: function() {
      var autreVar = "Hello";
      function direBonjourComment(methode) {
        console.log(methode);
      }
      direBonjourComment(autreVar);
      direBonjour();
    }
  };
 
})();
 
monNameSpace.log();

Coloration en fonction de la portée :


Si vous utilisez Vim, cela serait actuellement en cours d'intégration.

Sources :
Google+ de Paul Irish
Exemples sur GitHub

[danielhagnoul]

On trouve au même niveau, "Level 1", les méthodes de l'objet (setMaVar(), getMaVar(), log()) et le code privé de l'objet (maVar, direBonjour()). Suis-je le seul que cela choque ?

[Kaamo]

Au début, j'avais tendance à penser que c'était une erreur aussi ... mais je pense que c'est le bon comportement.

Cela donne une couleur différente pour chaque niveau d'imbrication de fonction. Pas pour chaque niveaux de profondeur d'objet ... (je sais pas si c'est clair ).
L'objet retourné (contenant setMaVar, getMaVar, log) est défini dans le niveau 1, au même titre que direBonjour et maVar, c'est donc normal que ses propriétés aient la même couleur.
Par contre, les propriétés étant des fonctions, leurs corps est d'une couleur différente car c'est un autre niveau d'imbrication.

Apparemment, comme le projet a deux jours il y a quelques bugs recensés qui sont en cours de correction.

[SylvainPV]

Je ne suis pas fan de l'idée, la coloration syntaxique est déjà utilisée pour identifier visuellement les variables, opérateurs et valeurs. De plus cette information ne nous donne que les éléments du même scope et non ceux des scopes supérieurs, pourtant accessibles.

Sur certains IDE il est proposé un panel indiquant tous les scopes accessibles depuis la position actuelle du curseur ; y compris les closures et le scope global. C'est déjà beaucoup plus pratique, surtout lorsque c'est couplé à l'auto-complétion de code.

Exemple avec le panel Structure de Webstorm:

[tomlev]

Pour ma part je trouve que c'est pas clair du tout comme présentation... (détail important : je suis daltonien )

[MikePombal]

Une idée bien intéressante mais le problème c'est qu'en utilisant simplement le code couleur ça devient inutile pour 8% des hommes et 0.5% des femmes ayant des difficultés à percevoir les couleurs (daltonisme) tout comme moi.

[rambc]

Je ne trouve pas cela très pertinent. Pourquoi ? En fait, j'ai l'habitude de scinder suffisamment mes codes pour ne pas être perdu quand je me ballade dans une fonction ou une méthode.

[alex_vino]

Je ne trouve pas cela très pertinent. Pourquoi ? En fait, j'ai l'habitude de scinder suffisamment mes codes pour ne pas être perdu quand je me ballade dans une fonction ou une méthode.

Exactement, si l'architecture est bien réalisée et le code découpée comme il le faut on n'a pas ce probleme.
JavaScript est souvent l'exemple, mais il ne faut pas oublier que tres peu de gens qui font du JavaScript savent réellement écrire du JavaScript.
Sur la plupart des CV figurent le JavaScript mais finalement tres peu maitrisent les notions un peu plus avancées et meme certaines bases (comme Prototype, tableaux, ...), mais savent plutot copier-coller un bout de code d'un plugin jQuery.

Pour beaucoup qui développent avec c'est surtout une usine a gaz rempliee de tas de fonctions non commentée par ci par la.
Moins la variable a de portée mieux c'est.
On peux donc se poser la question, est-ce que c'est un réel besoin pour un certain type d'application ou bien parce que le développeur est mauvais et non structuré?

[gwinyam]

Je suis d'accord, un code bien structuré se suffit à lui-même.

Ceci dit, pour les débutants qui viennent d'un autre langage, cette question de portée est souvent la plus dure à assimiler. La coloration par portée peut être très utile pour eux.

Après quand on a un doute sur la portée, JSLint.com détaille assez bien les différentes portées.

[Kaamo]

@gwinyam, @alex_vino, @rambc : je suis d'accord avec vous. Si le code est bien structuré, ce genre d'outil ne sert pas plus que ça.
C'est utile pour les débutants.

Mais il peut y avoir une autre utilité comme, par exemple, aider à la lecture d'un code qui ne t'appartient pas (et comme vous le soulignez, ça peut être la cata ). En cas de refacto / relecture, cet outil peut s'avérer utile donc. A voir ...

[Traroth2]

Augmenter la lisibilité est toujours une bonne chose. Maintenant, est-ce que ce principe augmente réellement la lisibilité, il faudrait voir à l'usage. Ca existe pour Eclipse ?

[SylvainPV]

Exactement, si l'architecture est bien réalisée et le code découpée comme il le faut on n'a pas ce probleme.

Ben non pas d'accord. Je dirais même que c'est plus facile de maîtriser la portée de ces variables avec un code non structuré. Quand je dis non structuré, rien à voir avec le fait de séparer le code en différents fichiers ou de bien indenter son code. Je parle uniquement de la gestion des portées des variables. Oui car quasiment tous les débutants ne s'embêtent pas avec la notion de scope et placent toutes leurs variables dans le scope global. On sait tous que c'est une mauvaise pratique, que ça pose énormément de soucis mais au moins on a pas de questions à se poser sur la portée des variables.

Tandis qu'un mec avec un niveau avancé en Javascript va écrire un code beaucoup plus complexe en termes de scopes : les namespaces, les fonctions anonymes, les closures, les appels asynchrones, les contextes d'exécution manipulés via fn.call ou fn.apply. Sans parler de la POO en JS où on peut jongler entre les prototypes, les clônages, les extend... Tout ça rend la lecture des scopes beaucoup plus compliquée. Surtout si l'on travaille à plusieurs.

Moins la variable a de portée mieux c'est.

Absolument pas. C'est le genre de vérités générales complètement bidon au même titre que "Moins y'a de code mieux c'est" ou "Plus c'est rapide mieux c'est". Pour chaque variable il faut s'arranger pour qu'elle soit accessible par les objets qui en ont besoin et inaccessible par les autres. Bref, il faut trouver la place qui lui convienne. Et en voulant à tout prix enterrer les variables au scope le plus profond, parfois on se pose des problèmes qui n'ont pas lieu d'être.

[alex_vino]

Absolument pas.

...
C'est bien ce que tu dis pourtant, on doit limiter la portée des variables au maximum. J'imagine que tu as mal compris ce que je voulais dire ou je me suis mal exprimé, autant pour moi.

C'est le genre de vérités générales complètement bidon au même titre que "Moins y'a de code mieux c'est" ou "Plus c'est rapide mieux c'est"

La rapidité d'exécution est tres souvent primordiale, donc c'est faux, un code bien écrit peux aussi etre rapide (et l'est souvent largement plus que du code brouillon). De plus si on peux réduire la quantité de code sans pour autant impacter les fonctionnalités/lisibilité alors il faut le faire. N'oublie pas les couts de maintenance dans un projet.

[SylvainPV]

Oui je crois qu'on est d'accord mais qu'on ne s'entend pas sur le discours. Il s'agit dans tous les cas d'un compromis. Quand tu dis "On doit limiter au maximum", je peux également dire "au minimum" selon le sens dans lequel on prend le problème au départ.

Plus une variable a une portée élevée, plus elle est facilement accessible, mais plus elle risque d'être surchargée par erreur. Il faut trouver sa meilleure place.

Au même titre qu'un code plus performant ou plus court qu'un autre n'est pas forcément meilleur. L'autre peut être plus clair/maintenable/générique

[Kaamo]

Ca existe pour Eclipse ?

A l'heure actuelle, et à ma connaissance, voici les IDE qui semblent supporter cette coloration par portée des variables :
- SublimeText (Source | Code)
- Vim, en cours de dév (Source : un commentaire de ce post, par Antony Scriven)

A savoir qu'un éditeur pour Java a implémenté le concept mais un peu différemment dans le sens où c'est l'arrière plan qui est coloré pour la portée des variables et le texte pour la syntaxe afin d'avoir les deux modes en un.
- BlueJ 3.0 (Source)

[Traroth2]

A l'heure actuelle, et à ma connaissance, voici les IDE qui semblent supporter cette coloration par portée des variables :
- SublimeText (Source | Code)
- Vim, en cours de dév (Source : un commentaire de ce post, par Antony Scriven)

A savoir qu'un éditeur pour Java a implémenté le concept mais un peu différemment dans le sens où c'est l'arrière plan qui est coloré pour la portée des variables et le texte pour la syntaxe afin d'avoir les deux modes en un.
- BlueJ 3.0 (Source)

Faudra que j'essaye avec Vim, un de ces jours. Mais la solution de BlueJ combinant les deux colorations me plait mieux...

[Pelote2012]

C'est sur que le json n'est pas très lisible. La coloration est une bonne mesure.
Mais là, c'est juste une coloration par niveau. Ce qu'une bonne structure du programme rendait déjà bien lisible.

bon saluons déjà la volonté de faire quelquechose

[Kaamo]

Pour information, ça bouge un peu.

Alexander Mazurov, un ingénieur du CERN, a implémenté un autre plugin pour SublimeText qui permet de colorer la syntaxe (couleur sur le texte) ET le contexte en fonction de la portée des variables (couleur en arrière plan du texte).
Cette fois il a laissé tomber JSLint et s'est tourné vers Escope (une librairie javascript qui analyse la portée des variables) basée sur Esprima (parseur JS écrit en JS).

Personnellement, je trouve que ça pique un peu les yeux et qu'on a un peu de mal à s'y retrouver.

- Page démo
- Source

[Kaamo]

Toujours dans sa lancée, Alexander Mazurov propose une nouvelle fois un outil d'aide à la programmation basé sur Esprima et Escope.

Celui là, comparé au précédent, est plus intéressant. Sympa je pense pour assimiler un nouveau code et apprécier la portée des variables.



Source

[Kaamo]

David Wilhelm propose un plugin pour Vim qui permet la coloration en fonction de la portée des variables.

Blog post
Github du projet