Liste de contrôle de l'évaluateur

Soumettre des correctifs pour le code source de Mozilla n’a pas besoin d’être complexe. Cet article fournit une liste des meilleures pratiques, à suivre pour votre mise-à-jour, que les évaluateurs vérifient ou exigent. Suivre ces recommandations mène à un processus d'évaluation et d’acception plus doux et plus rapide..

Bonne citoyenneté sur le web

  • Assurez-vous que les nouvelles API développées pour le Web ont un sens et que les normes sont suivies ou pré-testées par défaut.
  • En C++, utilisez le wrapper-cache si besoin. Si votre projet peut être récupéré ailleurs, sans création dans le processus, il doit être mis en cache (wrapper-cache).

Correction

  • Le bogue qui est en train d’être corrigé est un bogue valide et a besoin d’être corrigé
  • Le correctif (patch) apporté règle le problème
  • Le correctif n’est pas inutilement compliqué
  • Le correctif n'ajoute pas de duplications du code existant (les doublons pourraient signifier qu'il est nécessaire de refactoriser). Généralement, cela dépend d'une "partie 0" d'un bug, qui est "une chose ordonnée pour rendre le correctif plus facile à écrire et à réviser".
  • Si la qualité du correctif doit être vérifiée, vous devrez fournir les étapes pour le reproduire (STR – Steps To Reproduce)

Qualité

  • Si vous pouvez le tester par unité, vous devriez le faire.
  • Si c’est du JavaScript, essayez de concevoir et de construire de telle sorte que xpcshell puisse exercer la plupart des fonctionnalités. C’est plus rapide.
  • Assurez-vous que le correctif ne crée pas de code inutilisé (par exemple : .supprimez les chaînes quand une fonctionnalité est supprimée)
  • Toutes les exceptions capturées doivent être enregistrées au bon niveau, avec les informations appropriées et identifiables. Aussi considérez le coût du traitement et de l’enregistrement des "logs" (journaux). [Astuce : Vérifier les niveaux de log est couteux sauf si vous utilisez Logger.]

Style

  • Suivez le guide de style pour le langage et le module concerné.
  • Suivez le style local pour le code environnant, même si le style local n’est pas documenté de façon formelle.
  • Les nouveaux fichiers ont des déclarations de licence et des modèles.
  • Les nouveaux fichiers JavaScript doivent utiliser un mode strict
  • Espace blanc en queue (git diff et splinter view surlignent ces espaces, il en est de même pour hg avec l’extension de couleur activé). Les espaces blancs peuvent être facilement corrigés en Mercurial en utilisant l’extension CheckFiles. Dans git, vous pouvez utiliser git rebase --whitespace=fix.

Problèmes de sécurité

  • Il ne devrait pas y avoir d’écriture dans des fichiers arbitraires en dehors du dossier de profil.
  • Soyez prudent quand vous lisez des entrées clavier d’utilisateur, des données réseaux ou fichiers provenant du disque. Partez du postulat que les entrées sont trop volumineuses, trop courtes, vides, malformées ou malicieuses.
  • Une marque (tag) comme contrôle de sécurité n’est pas sûr.
  • Si vous écrivez du code qui utilise JSAPI, il y a de grandes chances que vous soyez sur la mauvaise voie. Essayez d’éviter ça.

Problèmes de confidentialité

  • Il ne devrait pas y avoir de journalisation d'URL ou de contenu dont les URL peuvent être déduites.
  • [Fennec : Android Services a "Logger.pii ()" à cette fin (par exemple, journal de profil)].
  • Marquage pour l'évaluation de la confidentialité si nécessaire.

Fuite de ressources

  • En Java, les fuites de mémoire sont en grande partie dues aux exploitations singulières des caches et des collections, ou aux observateurs collés autour, ou aux exécutables assis sur une file d'attente.
  • En C++, utiliser cycle-collect selon les besoins. Si JavaScript peut voir votre objet, il a probablement besoin d'une collecte cyclique.
  • [Fennec : Si votre vue personnalisée fait des animations, il est préférable de nettoyer les exécutables dans onDetachFromWindow().]
  • Assurez-vous que toutes les poignées de fichiers et autres ressources disponibles sont fermées de manière appropriée.
  • [Fennec : Lorsque vous écrivez des tests qui utilisent PaintedSurface, assurez-vous que PaintedSurface est fermé lorsque vous avez terminé. ]

Impact sur les performances

  • Contrôlez votre fil principal IO (entrée-sortie) [Fennec : Android peut avertir à propos de cela avec  "strictmode" ].
  • Supprimez le journal de débogage qui n'est pas nécessaire dans la production.

Problèmes de fil

  • Enorme : utilisation correcte du verrouillage et de la volatilité; "livelock" (ouverture) et "deadlock" (blocage); "ownership" (possession).
  • [Fennec: Toutes les méthodes de visualisation ne doivent être touchées que par un fil de l'interface utilisateur .]
  • [Fennec: Sensibilisation au cycle de vie de l'activité (fonctionne avec "ne jamais garder les activités"). Testez également avec oom-fennec (https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/)].

Compatibilité

  • fichiers de version, bases de données, messages
  • Étiqueter les messages avec des identifiants pour des appelants sans ambiguité.
  • IDL UUIDs sont mis à jour en même temps que l'interface .
  • Les permissions Android devraient être "gouped" (regroupées) dans une version commune pour éviter de casser les mises à jour automatiques .
  • Les API Android ajoutées à partir de Froyo devraient être surveillées par un contrôle de version.

Préférences

  • Si la fonctionnalité utilisée est couverte par les préférences, assurez-vous du branchement.
  • Si vous travaillez sur une nouvelle fonctionnalité, envisagez d'ajouter des préférences pour contrôler le comportement .
  • Envisagez d'ajouter des preférences pour désactiver complètement la fonctionnalité dans le cas où des bogues se retrouvent plus tard dans le cycle de libération.
  • [Fennec: "Prefs" peuvent être les préférences Gecko prefs, les valeurs de "SharedPreferences" ou "build-time flags". Celui que vous devez choisir dépend de la façon dont la fonctionnalité est implémentée : un service Java pur ne peut pas facilement vérifier Gecko prefs, par exemple. ]

Chaînes de caractères

  • Il ne devrait pas y avoir de changements de chaîne dans les correctifs (y compris les extractions de chaînes) .
  • Nom des entités Rev pour les changements de chaîne.
  • Lorsque vous modifiez l'interface utilisateur, soyez conscient du fait que les chaînes auront différentes longueurs dans différentes régions.

Documentation

  • Le message de présentation doit décrire ce que le patch change (ne pas être une copie du résumé des bogues). La première ligne devrait être une description courte (puisque seule la première ligne est affichée dans le journal), et une description supplémentaire, si nécessaire, devrait être présente, correctement développée, dans des lignes ultérieures.
  • Des morceaux potentiellement confus de code sont suffisamment documentés.
  • Signaler un bug avec "dev-doc-needed" si des ajouts (addon) ou des API Web sont affectés.
  • Utilisez Javadocs de manière exhaustive, en particulier sur toutes les nouvelles méthodes non privées.
  • Lorsque vous déplacez des fichiers, assurez-vous que la responsabilité / l'annotation est préservée.

Accessibilité

  • Pour les pages HTML, les images devraient avoir l'attribut "alt" défini le cas échéant. De même, un bouton qui n'est pas un bouton HTML natif devrait avoir un rôle = "button" (bouton) et l'ensemble d'attributs d'étiquette aria
  • [Fennec: Assurez-vous que la contentDescription (description du contenu) est définie pour les parties de l'interface utilisateur qui devraient être accessibles ]

Étiquettes et contributeurs liés au document

Étiquettes : 
Contributeurs à cette page : chrisdavidmills, loella16, CarlosAvim
Dernière mise à jour par : chrisdavidmills,