J'ai écrit ceci environ 6 mois avant de commencer à travailler sur Base2. J'ai décidé de ne pas le poster à l'époque de peur de paraître pompeux. Après de plus amples réflections, ces règles ne sont pas mauvaise et j'ai globalement réussi à les suivre.
Voici ce que je me suis écrit en octobre dernier:
1. Sois non-obtrusif Mon HTML ne veut pas être au courant de l'existence de ton javascript
2. [modifier] Object.prototype est interdit! C'est si important que ça mérite sa propre règle. Object est la brique de base de toutes les fonctionalités du javascript, il ne faut jamais y toucher.
3. Ne pas sur-étendre Moins on étend les objets natif du Javascript (Array, String, Regexp, ...) mieux on se porte. Comprenons nous bien, les objets JS natifs manquent un peu de méthodes utiles. Vous serez obligé d'en ajouter quelques unes [ndt: ou d'utiliser des fonctions externes à la place], mais "une ou deux" n'est pas assez pour un auteur (de bibliothèque) créatif. Arrêtez vous là! N'ajoutez que ce dont vous avez réellement besoin: moins vous modifierez les objets javascript natifs moins vous risquerez de conflits avec d'autres bibliothèques (e.g. prototype, YUI, ...)
4. Suivez les standards En tant qu'auteur de bibliothèque, vous définissez des patterns de code Javascript. Les patterns sont des signes de faiblesse des langages. Souvenez vous que les spécifications Javascript et DOM sont en évolution constante. Si vous voulez "corriger" quelque-chose, commencez par vérifier que quelqu'un ne l'a pas corrigé pour vous. Songez aux solutions existantes. Si vous suivez les standards, suivez les soigneusement et à la lettre (par exemple ne sautez pas certains paramètres sur forEach)
5. Follow the leader (suivez le chef) Mozilla est le chef de file en javascript. Le créateur du langage, Brendan Eich, continue à travailler dessus et à l'améliorer. Les nouvelles fonctionalités sont disponibles dans les navigateurs Mozilla avant tout autre. Si vous voulez ajouter une fonctionalité au javascript, commencez par consulter les standards Mozilla [ndt: pour vérifier s'il n'ont pas déjà spécifié cette extension]. Par exemple si vous voulez étendre `Array` avec une méthode d'énumération, appelez là `forEach` et non `each`. Si vous implémentez une fonctionalité manquante mais spécifiée, suivez à la lettre les standards (voir règle 4)
6. Soyez flexible Et si je veux modifier un comportement sans changer le code de votre bibliothèque? À quel point est-ce facile? Pas suffisant. Rendez le encore plus facile [ndt: il faut essayer de fournir des points d'entrée permettant à l'utilisateur de la bibliothèque de se brancher dedans et de customiser certaines fonctionalités].
8. Banissez la détection de navigateur Les créateurs/fournisseurs de navigateurs n'arrêteront jamais d'ajouter des fonctionalités. En tant qu'auteur de bibliothèque vous devez rester à la pointe du progrès. Lire Ajaxian de temps en temps est insuffisant. Lisez tout blog sur le sujet que vous pouvez trouver afin de découvrir la prochaine technique. La détection de navigateurs [ndt: est une drogue dure et dangereuse et] provoque une dépendance [ndt: et un lourd risque futur pour votre bibliothèque, ainsi qu'un cauchemard en terme de maintenance à moyen et long terme]
9. Ce qui est petit est joli Les bibliothèques javascript arrivent à maturation. Certaines d'entre elles motorisent de gros sites. Mais tout le monde n'a pas une ligne ADSL [16 megas; ndt: Dean Edwards parle de lignes 2megas, il faut bien penser que la france urbaine fait partie des privilégiés en termes de débits]. Alors gardez votre bibliothèque légère. Mieux, fournissez une page de build permettant de générer une bibliothèque efficace ne contenant que ce dont j'ai besoin.
10. La 10e règle Bonne vieille 10e règle. On peut toujours compter sur la 10e règle. La 10e règle est SOYEZ PRÉVISIBLE. Je devrais être capable de deviner exactement ce qu'une méthode fait rien qu'en lisant son nom. Et je devrais également être capable de deviner le nom d'une méthode si je sais ce que je veux qu'elle fasse.
11. Règles bonus a- La documentation. Lourd, mais indispensable. b- Plus vous utiliserez les namespaces et moins j'aurais de chances de me souvenir de votre numéro de téléphone [ndt: pas bien compris, voir à la fin pour mon interprétation de cette règle] c- Souvenez vous que votre code pourra potentiellement être utilisé par des millions de personnes.
Et pour information, base2 ne modifie aucun objet Javascript natif.
Mon interprétation de 11.b: Les namespaces sont extrèmement utiles pour éviter des collisions de noms (entre différentes libs par exemple), je présume que Dean veut dire par là qu'une bonne utilisation des namespaces réduira les risques de conflits entre votre lib et son code / d'autres libs, donc réduira les chances qu'un utilisateur ait besoin de faire appel à vous (pour réduire ces conflits) ou envie de vous tuer (à cause de ces conflits). De plus l'utilisation de namespaces fournit également une mnémonique permettant de relier directement une fonctionalité à sa lib d'origine.
Voila, si vous trouvez des fautes n'hésitez pas à me les rapporter
Message édité par masklinn le 23-03-2007 à 19:01:15
--------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Marsh Posté le 23-03-2007 à 18:06:59
Traduit de Rules for JavaScript library authors par Dean Edwards
J'ai écrit ceci environ 6 mois avant de commencer à travailler sur Base2. J'ai décidé de ne pas le poster à l'époque de peur de paraître pompeux. Après de plus amples réflections, ces règles ne sont pas mauvaise et j'ai globalement réussi à les suivre.
Voici ce que je me suis écrit en octobre dernier:
1. Sois non-obtrusif
Mon HTML ne veut pas être au courant de l'existence de ton javascript
2. [modifier] Object.prototype est interdit!
C'est si important que ça mérite sa propre règle. Object est la brique de base de toutes les fonctionalités du javascript, il ne faut jamais y toucher.
3. Ne pas sur-étendre
Moins on étend les objets natif du Javascript (Array, String, Regexp, ...) mieux on se porte. Comprenons nous bien, les objets JS natifs manquent un peu de méthodes utiles. Vous serez obligé d'en ajouter quelques unes [ndt: ou d'utiliser des fonctions externes à la place], mais "une ou deux" n'est pas assez pour un auteur (de bibliothèque) créatif. Arrêtez vous là! N'ajoutez que ce dont vous avez réellement besoin: moins vous modifierez les objets javascript natifs moins vous risquerez de conflits avec d'autres bibliothèques (e.g. prototype, YUI, ...)
4. Suivez les standards
En tant qu'auteur de bibliothèque, vous définissez des patterns de code Javascript. Les patterns sont des signes de faiblesse des langages. Souvenez vous que les spécifications Javascript et DOM sont en évolution constante. Si vous voulez "corriger" quelque-chose, commencez par vérifier que quelqu'un ne l'a pas corrigé pour vous. Songez aux solutions existantes. Si vous suivez les standards, suivez les soigneusement et à la lettre (par exemple ne sautez pas certains paramètres sur forEach)
5. Follow the leader (suivez le chef)
Mozilla est le chef de file en javascript. Le créateur du langage, Brendan Eich, continue à travailler dessus et à l'améliorer. Les nouvelles fonctionalités sont disponibles dans les navigateurs Mozilla avant tout autre. Si vous voulez ajouter une fonctionalité au javascript, commencez par consulter les standards Mozilla [ndt: pour vérifier s'il n'ont pas déjà spécifié cette extension]. Par exemple si vous voulez étendre `Array` avec une méthode d'énumération, appelez là `forEach` et non `each`. Si vous implémentez une fonctionalité manquante mais spécifiée, suivez à la lettre les standards (voir règle 4)
6. Soyez flexible
Et si je veux modifier un comportement sans changer le code de votre bibliothèque? À quel point est-ce facile? Pas suffisant. Rendez le encore plus facile [ndt: il faut essayer de fournir des points d'entrée permettant à l'utilisateur de la bibliothèque de se brancher dedans et de customiser certaines fonctionalités].
7. Attention à la mémoire!
Les programmeurs font attention aux fuites de mémoire. Faites votre boulot [ndt: correctement].
8. Banissez la détection de navigateur
Les créateurs/fournisseurs de navigateurs n'arrêteront jamais d'ajouter des fonctionalités. En tant qu'auteur de bibliothèque vous devez rester à la pointe du progrès. Lire Ajaxian de temps en temps est insuffisant. Lisez tout blog sur le sujet que vous pouvez trouver afin de découvrir la prochaine technique. La détection de navigateurs [ndt: est une drogue dure et dangereuse et] provoque une dépendance [ndt: et un lourd risque futur pour votre bibliothèque, ainsi qu'un cauchemard en terme de maintenance à moyen et long terme]
9. Ce qui est petit est joli
Les bibliothèques javascript arrivent à maturation. Certaines d'entre elles motorisent de gros sites. Mais tout le monde n'a pas une ligne ADSL [16 megas; ndt: Dean Edwards parle de lignes 2megas, il faut bien penser que la france urbaine fait partie des privilégiés en termes de débits]. Alors gardez votre bibliothèque légère. Mieux, fournissez une page de build permettant de générer une bibliothèque efficace ne contenant que ce dont j'ai besoin.
10. La 10e règle
Bonne vieille 10e règle. On peut toujours compter sur la 10e règle. La 10e règle est SOYEZ PRÉVISIBLE. Je devrais être capable de deviner exactement ce qu'une méthode fait rien qu'en lisant son nom. Et je devrais également être capable de deviner le nom d'une méthode si je sais ce que je veux qu'elle fasse.
11. Règles bonus
a- La documentation. Lourd, mais indispensable.
b- Plus vous utiliserez les namespaces et moins j'aurais de chances de me souvenir de votre numéro de téléphone [ndt: pas bien compris, voir à la fin pour mon interprétation de cette règle]
c- Souvenez vous que votre code pourra potentiellement être utilisé par des millions de personnes.
Et pour information, base2 ne modifie aucun objet Javascript natif.
Mon interprétation de 11.b: Les namespaces sont extrèmement utiles pour éviter des collisions de noms (entre différentes libs par exemple), je présume que Dean veut dire par là qu'une bonne utilisation des namespaces réduira les risques de conflits entre votre lib et son code / d'autres libs, donc réduira les chances qu'un utilisateur ait besoin de faire appel à vous (pour réduire ces conflits) ou envie de vous tuer (à cause de ces conflits). De plus l'utilisation de namespaces fournit également une mnémonique permettant de relier directement une fonctionalité à sa lib d'origine.
Voila, si vous trouvez des fautes n'hésitez pas à me les rapporter
Message édité par masklinn le 23-03-2007 à 19:01:15
---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody