Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La coloration de code en fonction de la portée des variables.

Une alternative à la coloration syntaxique

Le 8 avril 2013 à 11:07, par Kaamo

19 commentaires

54PARTAGES

Voter pour

4

Voter contre

0

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

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

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

19 commentaires

Commenter Signaler un problème

Membre émérite

Le 09/04/2013 à 10:11

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 ?

Voter pour

3

Voter contre

0

Membre émérite

Le 09/04/2013 à 9:46

@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 ...

Voter pour

2

Voter contre

0

Membre émérite

Le 08/04/2013 à 12:43

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.

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 08/04/2013 à 13:46

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:

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 08/04/2013 à 14:29

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

)

Voter pour

1

Voter contre

0

Membre du Club

Le 08/04/2013 à 14:35

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.

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 09/04/2013 à 10:45

Citation

Envoyé par alex_vino

Voir le message

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.

Citation

Envoyé par alex_vino

Voir le message

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.

Voter pour

2

Voter contre

1

Membre émérite

Le 09/04/2013 à 14:12

Citation

Envoyé par SylvainPV

Voir le message

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.

Voter pour

1

Voter contre

0

Membre émérite

Le 30/04/2013 à 15:51

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

Voter pour

1

Voter contre

0

Membre émérite

Le 20/11/2013 à 15:53

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

Blog post
Github du projet

Voter pour

1

Voter contre

0

Commenter Signaler un problème