MDN wants to talk to developers like you: https://qsurvey.mozilla.com/s3/8d22564490d8

Reviewer Checklist

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Soumettre des corrections au code source de Mozilla n’a pas besoin d’être complexe. Cet article donne une liste des meilleurs techniques que votre mise-à-jour devrait contenir et que les correcteurs vérifient ou aiment bien voir. Suivre ces recommandations mène à un processus de correction et d’acception plus douce et rapide..

Bon habitant du web

  • Faites-en sorte que votre API web ait un sens et qu’il soit, soit standardisé soit préféré par défaut.
  • En C++, utilisation de wrapper-cache si besoin. If votre projet peut être réccupéré d’ailleurs dans être créé dans le processus, il a besoin d’une enveloppe (wrapper-cache).

Exactitude

  • Le bogue qui est en train d’être corrigé est un bogue valide et a besoin d’être corrigé
  • La correction apportée règle le problème
  • La correction n’est pas inutilement compliquée
  • La correction ne crée pas de duplication du code existant (refactorisez si nécessaire).
  • Si la qualité de correction doit être vérifiée, vous devrez fournir les étapes pour reproduire (STR – Steps To Reproduce)

Qualité

  • Si vous pouvez le tester avec des tests unitaires, vous devriez le tester avec des tests unitaires.
  • Si c’est du JavaScript, essayez de designer et de le construire de telle sorte que xpcshell puisse l’utiliser. C’est plus rapide.
  • Faites-en sorte que la correction ne crée pas de codes non utilisé.
  • Toutes les exceptions attrapées doivent être noté dans les logs au bon niveau, avec les informations appropriées et identifiables. Aussi considérez le coût du traitement et de l’enregistrement des logs. [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 autours, même si le style local n’est pas documenté de façon formel.
  • Les nouveaux fichiers ont des déclarations et des modalités de licence.
  • Les nouveaux fichiers JavaScript doivent utilisés le 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é 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, vide, malformées ou malicieuses.
  • Un tag pour sécurité n’est pas sûre.
  • Si vous écrivez du code qui utilise JSAPI, il y a de grandes chances que vous êtes sur la mauvaise voie. Essayez d’éviter ça.

Privacy issues

  • There should be no logging of URLs or content from which URLs may be inferred.
  • [Fennec: Android Services has Logger.pii() for this purpose (e.g., logging profile dir)].
  • Tag for privacy review if needed.

Resource leaks

  • In Java, memory leaks are largely due to singletons holding on to caches and collections, or observers sticking around, or runnables sitting in a queue.
  • In C++, cycle-collect as needed. If JavaScript can see your object, it probably needs to be cycle-collected.
  • [Fennec: If your custom view does animations, it's better to clean up runnables in onDetachFromWindow().]
  • Ensure all file handles and other closeable resources are closed appropriately.
  • [Fennec: When writing tests that use PaintedSurface, ensure the PaintedSurface is closed when you're done with it.]

Performance impact

  • Check for main-thread IO [Fennec: Android may warn about this with strictmode].
  • Remove debug logging that is not needed in production.

Threading issues

  • Enormous: correct use of locking and volatility; livelock and deadlock; ownership.
  • [Fennec: All view methods should be touched only on UI thread.]
  • [Fennec: Activity lifecycle awareness (works with "never keep activities"). Also test with oom-fennec (https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/)].

Compatibility

  • Version files, databases, messages
  • Tag messages with ids to disambiguate callers.
  • IDL UUIDs are updated when the interface is updated.
  • Android permissions should be 'grouped' into a common release to avoid breaking auto-updates.
  • Android APIs added since Froyo should be guarded by a version check.

Preffability

  • If the feature being worked on is covered by prefs, make sure they are hooked up.
  • If working on a new feature, consider adding prefs to control the behavior.
  • Consider adding prefs to disable the feature entirely in case bugs are found later in the release cycle.
  • [Fennec: "Prefs" can be Gecko prefs, SharedPreferences values, or build-time flags. Which one you choose depends on how the feature is implemented: a pure Java service can't easily check Gecko prefs, for example.]

Strings

  • There should be no string changes in patches that will be uplifted (including string removals).
  • Rev entity names for string changes.
  • When making UI changes, be aware of the fact that strings will be different lengths in different locales.

Documentation

  • The commit message should describe what the patch is changing (not be a copy of the bug summary). The first line should be a short description (since only the first line is shown in the log), and additional description, if needed, should be present, properly wrapped, in later lines.
  • Any potentially confusing pieces of code are adequately documented.
  • Flag a bug with dev-doc-needed if any addon or web APIs are affected.
  • Use Javadocs extensively, especially on any new non-private methods.
  • When moving files, ensure blame/annotate is preserved.

Accessibility

  • For HTML pages, images should have the alt attribute set when appropriate. Similarly, a button that is not a native HTML button should have role="button" and the aria-label attribute set.
  • [Fennec: Make sure contentDescription is set for parts of the UI that should be accessible]

Étiquettes et contributeurs liés au document

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