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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
---
title: Liste de contrôle de l'évaluateur
slug: Mozilla/Developer_guide/Reviewer_Checklist
tags:
- Correction
- Evaluation
- Guide
translation_of: Mozilla/Developer_guide/Reviewer_Checklist
---
<div class="summary">
<p>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.<span class="seoSummary">.</span></p>
</div>
<h2 id="Bonne_citoyenneté_sur_le_web">Bonne citoyenneté sur le web</h2>
<ul>
<li>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.</li>
<li>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).</li>
</ul>
<h2 id="Correction">Correction</h2>
<ul>
<li>Le bogue qui est en train d’être corrigé est un bogue valide et a besoin d’être corrigé.</li>
<li>Le correctif (patch) apporté règle le problème.</li>
<li>Le correctif n’est pas inutilement compliqué.</li>
<li>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".</li>
<li>Si la qualité du correctif doit être vérifiée, vous devrez fournir les étapes pour le reproduire (STR – Steps To Reproduce).</li>
</ul>
<h2 id="Qualité">Qualité</h2>
<ul>
<li>Si vous pouvez le tester par unité, vous devriez le faire.</li>
<li>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.</li>
<li>Assurez-vous que le correctif ne crée pas de code inutilisé (par exemple : supprimez les chaînes quand une fonctionnalité est supprimée)</li>
<li>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" <em>(journaux)</em>. [Astuce : Vérifier les niveaux de log est couteux sauf si vous utilisez Logger.]</li>
</ul>
<h2 id="Style">Style</h2>
<ul>
<li>Suivez <a href="/fr/docs/Developer_Guide/Coding_Style">le guide de style</a> pour le langage et le module concerné.</li>
<li>Suivez le style local pour le code environnant, même si le style local n’est pas documenté de façon formelle.</li>
<li>Les nouveaux fichiers ont des déclarations de licence et des modèles.</li>
<li>Les nouveaux fichiers JavaScript doivent utiliser un mode strict.</li>
<li>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 <a href="http://mercurial.selenic.com/wiki/CheckFilesExtension">l’extension CheckFiles</a>. Dans git, vous pouvez utiliser git rebase --whitespace=fix.</li>
</ul>
<h2 id="Problèmes_de_sécurité">Problèmes de sécurité</h2>
<ul>
<li>Il ne devrait pas y avoir d’écriture dans des fichiers arbitraires en dehors du dossier de profil.</li>
<li>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.</li>
<li>Une marque (tag) comme contrôle de sécurité n’est pas sûr.</li>
<li>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.</li>
</ul>
<h2 id="Problèmes_de_confidentialité">Problèmes de confidentialité</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Il ne devrait pas y avoir de journalisation d'URL ou de contenu dont les URL peuvent être déduites.</span></span></li>
<li>[Fennec : Android Services <span id="result_box" lang="fr"><span>a "Logger.pii ()" à cette fin (par exemple, journal de profil)].</span></span></li>
<li>Marquage pour l'évaluation de la confidentialité si nécessaire.</li>
</ul>
<h2 id="Fuite_de_ressources">Fuite de ressources</h2>
<ul>
<li>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.</li>
<li>En C++, utiliser cycle-collect selon les besoins. Si JavaScript peut voir votre objet, il a probablement besoin d'une collecte cyclique.</li>
<li>[Fennec : <span id="result_box" lang="fr"><span>Si votre vue personnalisée fait des animations, il est préférable de nettoyer les exécutables dans</span></span> onDetachFromWindow().]</li>
<li><span id="result_box" lang="fr"><span>Assurez-vous que toutes les poignées de fichiers et autres ressources disponibles sont fermées de manière appropriée.</span></span></li>
<li>[Fennec : <span id="result_box" lang="fr"><span>Lorsque vous écrivez des tests qui utilisent PaintedSurface, assurez-vous que PaintedSurface est fermé lorsque vous avez terminé.</span></span> ]</li>
</ul>
<h2 id="Impact_sur_les_performances">Impact sur les performances</h2>
<ul>
<li>Contrôlez votre fil principal IO <em>(entrée-sortie)</em> [Fennec : Android <span class="short_text" id="result_box" lang="fr"><span>peut avertir à propos de cela avec "strictmode"</span></span> ].</li>
<li><span id="result_box" lang="fr"><span>Supprimez le journal de débogage qui n'est pas nécessaire dans la production.</span></span></li>
</ul>
<h2 id="Problèmes_de_fil">Problèmes de fil</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Enorme : utilisation correcte du verrouillage et de la volatilité;</span> "<span>livelock" <em>(ouverture)</em> et "deadlock" <em>(blocage)</em>;</span> "ownership" <em>(possession</em>)<span>.</span></span></li>
<li>[Fennec: <span id="result_box" lang="fr"><span>Toutes les méthodes de visualisation ne doivent être touchées que par un fil de l'interface utilisateur</span></span> .]</li>
<li>[Fennec: <span id="result_box" lang="fr"><span>Sensibilisation au cycle de vie de l'activité (fonctionne avec "ne jamais garder les activités").</span> <span>Testez également avec oom-fennec</span></span> (<a href="https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/%29">https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/)</a>].</li>
</ul>
<h2 id="Compatibilité">Compatibilité</h2>
<ul>
<li>Fichiers de version, bases de données, messages.</li>
<li><span id="result_box" lang="fr"><span>Étiqueter les messages avec des identifiants pour des appelants sans ambiguité.</span></span></li>
<li>IDL UUIDs <span id="result_box" lang="fr"><span>sont mis à jour en même temps que l'interface</span></span> .</li>
<li>Les permissions Android <span id="result_box" lang="fr"><span>devraient être "gouped" <em>(regroupées)</em> dans une version commune pour éviter de casser les mises à jour automatiques</span></span> .</li>
<li>Les API Android ajoutées à partir de Froyo devraient être surveillées par un contrôle de version.</li>
</ul>
<h2 id="Préférences">Préférences</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Si la fonctionnalité utilisée est couverte par les préférences, assurez-vous du branchement.</span></span></li>
<li><span id="result_box" lang="fr"><span>Si vous travaillez sur une nouvelle fonctionnalité, envisagez d'ajouter des préférences pour contrôler le comportement</span></span> .</li>
<li><span id="result_box" lang="fr"><span>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.</span></span></li>
<li>[Fennec: <span id="result_box" lang="fr"><span>"Prefs" peuvent être les préférences Gecko prefs, les valeurs de "SharedPreferences" ou "build-time flags".</span> <span>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.</span></span>]</li>
</ul>
<h2 id="Chaînes_de_caractères">Chaînes de caractères</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Il ne devrait pas y avoir de changements de chaîne dans les correctifs (y compris les extractions de chaînes)</span></span>.</li>
<li><span id="result_box" lang="fr"><span>Nom des entités Rev pour les changements de chaîne.</span></span></li>
<li><span id="result_box" lang="fr"><span>Lorsque vous modifiez l'interface utilisateur, soyez conscient du fait que les chaînes auront différentes longueurs dans différentes régions.</span></span></li>
</ul>
<h2 id="Documentation">Documentation</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Le message de présentation doit décrire ce que le patch change (ne pas être une copie du résumé des bogues).</span> <span>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.</span></span></li>
<li><span id="result_box" lang="fr"><span>Des morceaux potentiellement confus de code sont suffisamment documentés.</span></span></li>
<li><span id="result_box" lang="fr"><span>Signaler un bug avec "dev-doc-needed" si des ajouts (addon) ou des API Web sont affectés.</span></span></li>
<li><span id="result_box" lang="fr"><span>Utilisez Javadocs de manière exhaustive, en particulier sur toutes les nouvelles méthodes non privées.</span></span></li>
<li><span id="result_box" lang="fr"><span>Lorsque vous déplacez des fichiers, assurez-vous que la responsabilité / l'annotation est préservée.</span></span></li>
</ul>
<h2 id="Accessibilité">Accessibilité</h2>
<ul>
<li><span id="result_box" lang="fr"><span>Pour les pages HTML, les images devraient avoir l'attribut "alt" défini le cas échéant.</span> <span>De même, un bouton qui n'est pas un bouton HTML natif devrait avoir un rôle = "button" <em>(bouton)</em> et l'ensemble d'attributs d'étiquette aria.</span></span></li>
<li>[Fennec: <span id="result_box" lang="fr"><span>Assurez-vous que la </span></span> contentDescription <em>(description du contenu)</em><span lang="fr"><span> est définie pour les parties de l'interface utilisateur qui devraient être accessibles</span></span>].</li>
</ul>
|
