Commentaires sur le DevCast Palmpre-France #4

Marc Aurélien de Palm Pré France continue sa série d’article sur le développement sur HP WebOS…

Je viens de voir les articles 3 et 4 et j’ai quelques commentaires à faire sur son code… Le code, c’est un art, il y a toujours une meilleur façon de faire, et il y a autant de façons de faire que de développeurs ;-). Le code de Marc Aurélien n’est pas mauvais, c’est juste que j’ai envie de donner mon avis 😉

Les variables :

Mon premier conseil est qu’il ne faut jamais utiliser des variables globales… Des variables globales ? Quezako ? Et bien, il faut un petit cour sur les variables et surtout sur leur visibilité… En fonction de l’endroit où l’on crée une variable et de la façon dont on la déclare, sa visibilité peut varier… Il y a 2 types de variables : les variables locales et les variables globales

Une variable locale se déclare avec le mot clef var… Sa visibilité est limitée au sein de la fonction courante et de toutes les sous fonctions qui peuvent avoir été crées dans la fonction courante (on appelle cela une closure)…
Par contre, une variable globale n’a pas besoin d’être déclarée avec un mot clef. Sa visibilité n’est pas restreinte. Tout code dans l’application peut utiliser cette variable, même en dehors de la fonction qui l’a déclarée.


Mais pourquoi ne faut-il pas les utiliser ?
Premièrement, car c’est souvent une source de bugs… On utilise une variable dans une fonction, mais on à oublié que cette variable est aussi utilisée dans une autre… On se retrouve avec un jolie bug… Même si l’on a une mémoire infaillible, il faut toujours se dire qu’un jour, quelqu’un d’autre sera peut être amené à travailler sur votre code, et lui, il sera peut être faillible 😉
Deuxièmement, dans un environnement objet comme le javascript, utiliser des variables globales veut dire que l’on ne pourra pas avoir plusieurs instances du même objet… L’objet dont je parle, dans le cas qui nous intéresse, c’est l’assistant de la carte actuelle (fenêtre / écran dans WebOS). Si l’on veut pouvoir avoir plusieurs cartes simultanément, on se retrouvera avec plusieurs assistant qui tenteront tous d’utiliser les mêmes variables… Aie, on se retrouve encore avec un bug 😉

Donc, moralité : il ne faut jamais utiliser des variables globales… Point. Comment faire ? C’est simple, il faut toujours déclarer ses variables avec le mot clef var !

Mais comment faire pour avoir des variables qui doivent être partagées entre les différentes fonctions de l’assistant, mais qui ne doivent pas partagées entre les différentes instances de l’assistant ? Et bien c’est simple, on n’utilise pas de variable 😉 On utilise les propriétés que l’on ajoute à l’assistant courant… En javascript, on peut accéder aux propriétés d’un objet de deux façon : en nommant l’objet, suivi d’un point (.) et du nom de la propriété, ou en nommant l’objet, puis en ajoutant une chaine de caractères entre crochets ( [ et ] )…

Mais comment accéder à l’objet courant ? Grâce à la variable spéciale thisthis est une variable locale qui dépend de la façon dont la fonction est appelée… Ce qu’il faut retenir, c’est qu’en générale, elle pointe sur l’objet courant…

Donc, voici comment définir des propriétés dans un objet :


Dans l’application de Marc Aurélien, les variables globales que j’ai recensées sont au nombre de 4 (vent, nuage, meteo et meteophrase)…
Les deux dernières sont strictement locales à la fonction meteo… Par contre, les deux premières sont des candidates idéales pour être des propriétés de l’assistant.

Simplification du code

Marc Aurélien utilise un événement propertyChanged sur chaque sélecteur pour la logique de son application. Chaque sélecteur commence par convertir la valeur, enregistre le résultat dans la variable globale, puis lance la fonction métier, qui va se charger d’afficher le résultat du calcul.

1 – la conversion de valeur :
Pourquoi ne pas mettre directement la bonne valeur dans les champs value des listes de choix des sélecteurs… Mettre directement l’entier correspondant à la valeur plutôt qu’une chaine de caractères intermédiaire… Par contre, en faisant mes essais, je me suis rendu compte que Mojo retournait une chaine de caractères plutôt que la valeur qui était définie dans les attributs de l’objet… Je pense que je vais me fendre d’un petit rapport de bug sur le sujet 😉 Qu’a cela ne tienne, il suffit d’appliquer un petit parseFloat pour obtenir une valeur numérique…

2 – l’enregistrement de la valeur :
Les widgets de Mojo se chargent tout seul d’enregistrer la valeur comme une propriété de l’objet qui est passée en troisième argument de la fonction setupWidget… Le nom de la propriété est par défaut ‘value’, mais il peut être changé grâce au paramètre modelProperty… Plusieurs widgets peuvent ainsi se partager le même modèle en utilisant des propriétés différentes…

Ces deux points permettent de factoriser le code et de ne garder qu’un seul gestionnaire d’événement commun aux deux sélecteurs… Ce gestionnaire d’événement se contentera juste de lancer la fonction meteo qui s’occupe du traitement des données.

Voici maintenant à quoi va ressembler le code tel que je l’aurais écrit :

Et voilà… Il y a surement plein de chose à redire sur ce code, mais voilà ma vision des choses 😉

Laisser un commentaire

Votre adresse ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.