Ce document est un exemple de rapport d’audit produit automatiquement à partir des résultats de l’analyse de l’application sur la plateforme Kalistick. Il n’intègre pas de commentaires spécifiques sur les résultats obtenus. Son objectif est de servir de modèle pour constituer des rapports personnalisés, il illustre la capacité de la plateforme à restituer une vision claire et compréhensible de la qualité d’une application. Ce document est confidentiel, il est la propriété de Kalistick, Il ne doit pas être diffusé ni modifié sans autorisation. Kalistick 13 av Albert Einstein F-69100 Villeurbanne +33(0) 486 68 89 42 [email protected]www.kalistick.com DEMO Application SHARPDEVELOP Rapport d’audit 01/01/2011
61
Embed
Analyse de code: accélérez la validation de vos applications C#
Accélérez la mise en production de vos logiciels C# en réalisant des tests plus efficaces, basés sur les risques, et une validation plus rapide.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Ce document est un exemple de rapport d’audit produit automatiquement
à partir des résultats de l’analyse de l’application sur la plateforme Kalistick.
Il n’intègre pas de commentaires spécifiques sur les résultats obtenus.
Son objectif est de servir de modèle pour constituer des rapports personnalisés,
il illustre la capacité de la plateforme à restituer une vision claire et compréhensible
de la qualité d’une application.
Ce document est confidentiel, il est la propriété de Kalistick,
Il ne doit pas être diffusé ni modifié sans autorisation.
Kalistick 13 av Albert Einstein F-69100 Villeurbanne +33(0) 486 68 89 42
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 2/61
1 Executive Summary Le Cockpit Qualité utilise des techniques d’analyse statique : il n’exécute pas l’application mais analyse les
éléments qui la constituent (code, résultats des tests, architecture, …). Les résultats sont corrélés, agrégés et
comparés avec les enjeux du projet pour identifier les risques liés à la qualité. Ce rapport présente les
résultats obtenus.
Synthèse - Ecart par rapport à l’objectif
Ce graphique compare la situation actuelle du projet par rapport aux objectifs fixés sur chacun des axes de qualité. L’objectif, configuré à l’initialisation de l’audit, représente l’importance de chaque axe de qualité. Il est destiné à déterminer les règles à respecter dans les développements et la tolérance acceptée.
Taux de non-conformité global
Cette jauge indique le niveau de qualité global de l’application par rapport à son objectif qualité. Elle présente le pourcentage de l’application (code) considéré comme non-conforme. Selon la configuration réalisée, un taux supérieur à 15% indique la nécessité d’approfondir l’analyse des résultats.
Origine des violations
Ce graphique identifie l’origine technique des non-conformités détectées, et les principaux domaines d’amélioration. Selon les éléments soumis lors de l’analyse, certains domaines peuvent ne pas avoir été évalués.
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 3/61
Organisation du rapport Ce rapport présente les concepts du Cockpit Qualité, l’objectif fixé et les exigences techniques associées,
avant de poursuivre par les résultats synthétiques puis détaillés par domaine technique.
3.1 Le profil qualité ..................................................................................................................................... 7
3.2 Les exigences techniques ..................................................................................................................... 7
4 Synthèse des résultats ................................................................................................................................ 10
4.1 Situation du projet.............................................................................................................................. 10
5.4 Test ..................................................................................................................................................... 35
6 Plan d’action ............................................................................................................................................... 47
8.1 La complexité cyclomatique ............................................................................................................... 51
8.2 Le couplage ......................................................................................................................................... 53
8.3 Le TRI et TEI ........................................................................................................................................ 54
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 5/61
2.2.1 Les axes de qualité
Les axes de qualité standardisent un ensemble de qualités auxquelles doit prétendre l’application selon la
norme ISO 912623 :
Maintenabilité. Capacité d’un logiciel à pouvoir être dépanné facilement, en fonction de l’effort
exigé pour localiser, identifier et corriger les erreurs.
Fiabilité. Aptitude d’un logiciel à fonctionner correctement en rendant le service attendu dans les
conditions normales de fonctionnement.
Evolutivité. Aptitude d’un logiciel à pouvoir évoluer, en fonction de l’effort requis pour ajouter,
supprimer, modifier des fonctions d’un logiciel déjà opérationnel.
Sécurité. Aptitude du logiciel à fonctionner en respectant les contraintes d’intégrité, de
confidentialité et de traçabilité requises.
Transférabilité. Capacité à faire réaliser la maintenance et les évolutions d’un logiciel par une
nouvelle équipe distincte de celle ayant développé le logiciel initial.
Efficacité. Relation entre le niveau de performance du logiciel et la quantité de ressources
nécessaires pour le faire fonctionner dans des conditions nominales.
2.2.2 Les domaines de qualité
Les domaines de qualité déterminent la nature des problèmes selon leur origine technique. Ils sont au
nombre de six :
Implémentation. Les problèmes inhérents au codage : mauvaise utilisation du langage, bugs
potentiels, code difficilement compréhensible, … Ces problèmes peuvent nuire à un ou plusieurs des
six axes de qualités.
Structure. Les problèmes liés à l’organisation du code : méthodes trop longues, trop complexes, avec
trop de dépendances, … Ces problèmes impactent généralement la maintenabilité et l’évolutivité de
l’application.
2 ISO/IEC 9126-1:2001 Software engineering — Product quality — Part 1: Quality model :
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749 3 L’analyse porte sur un sous-ensemble de la norme ISO 9126 afin de se focaliser sur les dimensions contrôlables de
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 8/61
Voici le détail de ces exigences techniques :
Domaine Règle Explication, objectif et seuils éventuels Im
plé
me
nta
tio
n - Selon votre profil, entre 150 et 200 règles ont été sélectionnées. Elles sont
présentées exhaustivement en annexe du rapport (8.4.1 Règles d’implémentation). Objectif : éviter les mauvaises pratiques et appliquer les bonnes pratiques liées aux technologies utilisées.
Stru
ctu
re
Taille des méthodes Nombre de ligne d'instructions. Cette mesure est différente du nombre de ligne de code : elle n'inclut pas les lignes de commentaire ni les lignes blanches mais seulement les lignes comportant au moins une instruction. Objectif : éviter les blocs de traitements difficilement compréhensibles. Le seuil retenu pour le projet est :
nombre de lignes : 100
Complexité des méthodes
Complexité cyclomatique d'une méthode. Elle mesure la complexité algorithmique d'une méthode en comptant le nombre de chemins indépendants couvrant tous les cas possibles. Plus ce nombre est élevé, plus le code est difficile à maintenir et à tester. Objectif : éviter les blocs de traitements difficilement compréhensibles, non testables et qui tendent à avoir un taux de dysfonctionnement important. Le seuil retenu pour le projet est :
complexité cyclomatique : 20
Complexité et couplage des méthodes
Identifie les méthodes difficiles à comprendre, à tester et à maintenir en raison d'une complexité moyenne (complexité cyclomatique) et à de nombreuses références à des types tiers (couplage efférent) Objectif : éviter les blocs de traitements difficilement compréhensibles et non testables. Les seuils retenus pour le projet sont :
complexité cyclomatique : 15
couplage efférent : 20
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 9/61
Test
Couverture de test des méthodes
Taux de couverture de code d'une méthode. Cette métrique est standardisée par notre plateforme à partir des mesures brutes de couverture de code quand elles sont fournies au sein de l'archive du projet. Cette exigence associe un seuil minimal de test (couverture de code) à chaque méthode de l'application selon le TRI (TestRelevancyIndex) ; le TRI évalue pour chaque méthode le risque qu'elle contienne des bugs. Son calcul tient compte des risques métiers définis pour l'application. Objectif : orienter sa stratégie et les efforts de test sur les points sensibles de l’application et la vérifier. Ces points sensibles sont évalués selon leur propension à contenir des bugs et les risques métiers/fonctionnels de l’application. Le détail des seuils est fourni en annexe du rapport (8.4.2 Seuils de couverture de code).
Arc
hit
ect
ure
Règles définies spécifiquement pour le modèle d’architecture de l’application.
Voir le modèle d’architecture éventuellement défini pour découvrir les contraintes d’architecture en cours. Objectif : s’assurer que les développements respectent le modèle d’architecture prévu et n’introduisent pas des incohérences synonymes de failles de sécurité, de difficultés de maintenance ou d’évolution. NB : les violations d’architecture ne sont pas prises en compte dans le calcul de la non-conformité.
Do
cum
en
tati
on
Entête de documentation des méthodes
Identifie les méthodes de complexité moyenne qui ne disposent pas d'entête de documentation. Les méthodes prises en compte sont celles dont la complexité cyclomatique et le nombre d'instructions excèdent des seuils définis spécifiquement pour le projet. Objectif : s’assurer que la documentation est présente sur les blocs de traitements clés en vue de faciliter les éventuels changements d’équipe (transférabilité). Les seuils retenus pour le projet sont :
complexité cyclomatique : 10
nombre de lignes : 50
Du
plic
atio
n Détection des
duplications
Les duplications sont invalidées au-delà de 20 instructions Objectif : détecter l’implémentation de traitements identiques à plusieurs endroits différents dans l’application, très souvent source d’incohérences lorsque l’on effectue des modifications, et facteur d’augmentation des coûts de tests et d’évolution.
Domaine Règle Explication, objectif et seuils éventuels
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 10/61
4 Synthèse des résultats Ce chapitre synthétise la situation du projet à l’aide d’indicateurs globaux. Ceux-ci mesurent la qualité
intrinsèque du projet, mais comparent également sa situation à celle des autres projets de la base de
référence du « Cockpit Qualité ».
4.1 Situation du projet Les indicateurs suivants concernent la situation intrinsèque du projet.
4.1.1 Taux de non-conformité global
Le taux de non-conformité mesure la proportion du code de l’application considéré comme non-conforme.
Voir sur le Cockpit Qualité
Plus précisément, ce chiffre résulte du rapport entre le nombre total d’instructions, et le
nombre d’instructions des classes non-conformes. Une classe est considérée comme non
conforme si au moins un des cas suivants est rencontré :
- Une non-conformité de sévérité interdite est détectée dans la classe
- Un ensemble de non-conformités fortement déconseillées, déconseillées, ou à éviter sont
détectées dans la classe et dépassent un certain seuil. Ce calcul dépend de la sévérité de chaque
non-conformité ainsi que du profil qualité qui ajuste le seuil de tolérance.
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 48/61
5. Suppression des duplications
Cette opération est plus ou moins compliquée suivant les cas : il faut au préalable déterminer si la
duplication doit réellement être factorisée (deux composants peuvent partager une même base de
code mais être indépendants). Ensuite l’opération peut être automatisée selon les IDE et selon le
type de duplication (difficile si la duplication est à cheval sur plusieurs méthodes).
6. Modularisation des traitements complexes
Cette opération est proche de l’éclatement des méthodes trop longues, mais est souvent plus
délicate à réaliser en raison de la complexité du code.
Le plan d’action peut être affiné sur le Cockpit Qualité en utilisant le mécanisme des
« tags ». Les tags permettent d’étiqueter les résultats d’analyse pour faciliter des opérations
telles que la priorisation des corrections, leur affectation à des développeurs ou leur lotissement
selon les versions.
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 49/61
7 Glossaire
Axe de qualité
Les résultats d'analyses sont ventilés sur 6 axes de qualités selon les besoins de l'application en termes de
qualité :
Efficacité : l'application assure-t-elle les performances d'exécution attendues ? Evolutivité : les évolutions du code nécessitent-t-elles un coût de développement croissant ? Fiabilité : l'application présente-t-elle des bugs qui nuisent à son comportement attendu ? Maintenabilité : les mises à jour de maintenance nécessitent-t-elles un coût de développement
constant ? Sécurité : l'application présente-t-elle des failles de sécurité ? Transférabilité : la reprise de l'application par de nouveaux intervenants est-elle problématique ?
Couverture par blocs
La couverture par blocs mesure le taux de blocs exécutés lors des tests par rapport au nombre total de blocs.
Un bloc de code est un chemin de code avec un point d'entrée unique, un point de sortie unique et un jeu
d'instructions exécutées en séquence. Il se termine lorsqu'il atteint une instruction conditionnelle, un appel
de fonction, une levée d'exception, ou un try/catch.
Couverture par branches
La couverture par branches mesure le taux de branches exécutées lors des tests par rapport au nombre total
de branches.
if (value)
{
//
}
Ce code sera couvert par branches à 100% si la condition du if a été testée dans le cas vrai et faux.
Couverture par lignes
La couverture par lignes (ou instructions) mesure le taux de lignes exécutées lors des tests par rapport au
nombre total de lignes. Cette mesure est insensible aux instructions conditionnelles, la couverture par lignes
peut être de 100% sans que l'ensemble des conditions soit exécuté.
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 50/61
Domaine de qualité
Les résultats d'analyses sont ventilés sur 4 domaines selon la nature des violations :
Implémentation : concerne des problèmes liés à l'utilisation du langage ou à l'algorithmie Structure : concerne des problèmes liés au découpage de l'application : taille des méthodes,
complexité cyclomatique, ... Test : concerne les problèmes liés aux tests unitaires du code et à sa couverture Architecture: concerne les problèmes liés l’architecture logicielle Documentation : concerne les problèmes liés à la documentation du code : commentaires d'entête,
commentaires de code, ... Duplication : correspond aux copier-coller découverts dans le code
Instruction de code
Une instruction de code représente une unité de code primaire, proche de la ligne de code. Pour simplifier,
une instruction est délimitée par un point-virgule (;) ou pour par une accolade gauche ({). Exemples
d'instructions en Java :
int i = 0;
if (i == 0) {
} else {
public final class SomeClass
{
import com.project.SomeClass;
package com.project;
A la différence des lignes de code, les instructions ne comprennent pas les lignes blanches et les
commentaires. De plus, une ligne peut contenir plusieurs instructions.
Ligne de code
Une ligne physique d'un fichier de code. Peut concerner une ligne blanche, ou une ligne de commentaire.
Non-conformité
Un résultat d'analyse qui ne satisfait pas les exigences techniques fixées par le projet. Une non-conformité
concerne un axe de qualité et un domaine de qualité.
Synonyme(s) : violation
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 51/61
8 Annexes
8.1 La complexité cyclomatique La complexité cyclomatique est un indicateur du nombre de chemins possibles d’exécution.
Sa valeur élevée est signe qu’il sera difficile à comprendre, à tester, à valider, à maintenir et à faire évoluer.
8.1.1 Définition
On produit un graphe de contrôle qui représente le code dont on veut mesurer la complexité. Une fois ce
graphe de contrôle dessiné, on compte le nombre CC de faces de ce graphe. La complexité structurelle du
code (appelée aussi complexité cyclomatique) est mesurée par CC.
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 52/61
8.1.2 Exemple
On souhaite mesurer la complexité du code suivant :
Code analysé Graphe de contrôle équivalent
int x = 3;
if (x > 0) {
x++;
} else {
x--;
}
Le graphe contient 4 arcs, 4 nœuds et 2 faces (1
intérieure, 1 extérieure). Le nombre CC vaut donc 2.
8.1.3 Corollaire de la définition
CC = nb de décisions du code + 1
Une instruction if compte pour 1 décision
Une instruction for ou while compte pour 1 décision
Une instruction case compte n décisions.
8.1.4 Diagnostic à effectuer
Valeur de la Complexité Cyclomatique
Evaluation des risques selon le S.E.I.8
1-10 Programme simple, sans trop de risque
11-20 Complexité et risque modéré
21-50 Complexe, risque élevé
Supérieure à 50 Non testable, risque très élevé
.
8 : Le S.E.I. (Software Engineering Institute, http://www.sei.cmu.edu/) est l’institut à l’origine de la norme CMMI. Ses
recherches réputées sur la qualité de code en font un acteur majeur et fiable dans le domaine. CMMi : sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie (source : Wikipedia).
or()</code> ou la fonction équivalente Win32 <code>GetLastError()</code> après l'appel P/Invoke afin d'éviter de récupérer une mauvaise erreur.
Interdit
AlwaysDeclareNamespace Toujours organiser les types dans des namespaces. Interdit AvoidRedundantCasts Il faut éviter de réaliser plusieurs transtypages identiques sur un
même objet. Interdit
CallSuppressFinalizeInDisposeMethods
Il faut appeler la méthode <code>System.GC.SuppressFinalize()</code> dans l'implémentation de la méthode
<code>System.IDisposable.Dispose()</code> afin que le Garbage Collector n'appelle pas le finaliseur de l'objet.
Interdit
DeclareUsageForAttribute Un attribut personnalisé doit être marqué par l'attribut <code>System.AttributeUsage</code> afin d'indiquer au
développeur où il peut être appliqué (type, méthode, assembly...).
Interdit
DeclareVersionForAssembly_ La version de l'assembly doit être déclarée. Interdit DefineMarshalingForPInvokeStringArguments
Il faut spécifier la conversion des arguments de type chaines de
caractères lors d'appel à du code non managé. Interdit
DefineMessageForObsoleteAttribute Il faut utiliser l'argument <code>message</code> de l'attribut <code>System.ObseleteAttribute</code> afin d'indiquer à
l'utilisateur quel est l'élément à utiliser à la place.
Interdit
DontAccessAnyReferenceTypeInDestructor
L'accès à des champs référencés dans le finaliseur peut ne pas aboutir.
Interdit
DontAccessOrModifyObjectMoreThanOnceInAExpression
Il ne faut pas accéder ou modifier un objet plus d'une fois dans
une expression. Interdit
DontChangeVisibilityOfInheritedMember
Il ne faut pas réduire la visibilité d'une méthode que l'on surcharge (avec le mot clé <code>new</code>).
Interdit
DontCompareFloatWithEquals Les comparaisons entre nombres flottants (<code>float</code>,<code>double</code>,
<code>decimal</code>) ne doivent pas être réalisées avec les opérateurs <code>==</code> et <code>!=</code>.
Interdit
DontDeriveExceptionFromSystemException
Il ne faut pas créer une nouvelle exception héritant de <code>System.SystemException</code>, préférer l?utilisation de <code>System.Exception</code>.
Interdit
DontHardcodeLocaleSpecificStrings Il ne faut pas coder en dur des chemins de dossiers systèmes spécifiques à l'environnement d'exécution
Interdit
DontHideBaseClassMethod Une méthode dans un type de base est masquée dans un type dérivé par une méthode dont les paramètres sont des sous-types de la méthode de base.
Interdit
DontImplementEmptyFinalizers Il est inutile d'implémenter des finaliseurs vides. Interdit DontImplementWriteOnlyProperty Il est déroutant de déclarer des propriétés en écriture seulement. Interdit DontOverloadOperatorEqualsOnReferenceType
La surcharge de l'opérateur <code>==</code> est à utiliser avec parcimonie.
Interdit
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 57/61
DontRaiseExceptionInUnexpectedMethod_
Certaines méthodes ne doivent pas jeter d'exceptions car elles doivent effectuer des opérations simples et aboutir soit à une valeur de retour, soit à la fin d'une opération.
Interdit
DontThrowExceptionsInFinallyBlock Il ne faut pas lancer d'exception dans une clause <code>finally</code>.
Interdit
DontUseInadvisableTypes Depuis la version 2.0 du framework .NET, il est recommandé de ne plus dériver certains types.
Interdit
DontUseObjectTypeForIndexers Il faut utiliser des types entier ou string comme index pour les
indexeurs. L'utilisation d'un type Objet est à proscrire. Interdit
DontUseTooManyParametersOnGenerics_
Le nombre de paramètres génériques pour un type générique
visible de l'extérieur est limité à 2. Interdit
DontUseWin32ApiWhenManagedApiExist
Il est préférable d?utiliser la version managée d?une méthode à la
place de la version non managée lorsqu?elle est disponible. Interdit
FollowISerializableImplementationRule
L'implémentation de <code>System.Runtime.Serialization.ISerializable</code> doit
suivre un pattern de conception afin de respecter les standards. En effet, les champs d'instance d'un type sérialisable doivent être intégrés au processus de sérialisation.
Interdit
ISerializableTypesMustCallBaseClassMethods
Un type dérivant un type implémentant
<code>ISerializable</code> doit invoquer le traitement parent. Interdit
ImplementIDisposableForTypesWithDisposableFields
Un type qui déclare et implémente des champs de type
<code>System.IDisposable</code> doit implémenter <code>System.IDisposable</code> afin de supprimer ses ressources non managées.
Interdit
InstantiateExceptionsWithArguments Il est recommandé d'instancier les exceptions en fournissant les paramètres adéquates pour préciser le contexte de l'exception.
PInvokesMustNotBeVisible Une méthode marquée avec l'attribut <code>System.Runtime.InteropServices.DllImportAttribute</code
> ne doit pas être visible en dehors de l'assembly.
Interdit
PropertyNamesMustNotMatchGetMethods
Une méthode ne doit pas être nommée à partir du nom d'une propriété.
Interdit
TypeLinkDemandsRequireInheritanceDemands
Un type public non scellé ou une méthode virtuelle ayant une demande de liaison doivent avoir une demande d'héritage sur la même autorisation.
Interdit
TypeWithNativeResourcesMustBeDisposable
Un type possèdant des champs <code>IntPtr</code>,
<code>UIntPtr</code> et <code>HandleRef</code> doit implémenter <code>System.IDisposable</code>.
Interdit
UseConstInsteadOfReadOnlyWhenPossible_
Un champ déclaré en <code>static</code> et
<code>readonly</code> dont la valeur initiale peut être calculée à la compilation, doit utiliser <code>const</code> au lieu de <code>static readonly</code>.
Interdit
UseIsNanFunction Il ne faut pas comparer avec les valeurs <code>Double.NaN</code> ou <code>Single.NaN</Code>.
Interdit
UseIsNullOrEmptyToCheckEmptyStrings
Comparer une chaîne à la chaîne vide n'est pas optimal. Interdit
UseMarshalAsForBooleanPInvokeArguments_
Il faut utiliser l'attribut <code>System.Runtime.InteropServices.MarshalAsAttribute
</code> pour permettre la bonne conversion entre un booléen non managé et un booléen managé.
Interdit
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 58/61
UseParamsKeywordInsteadOfArglist Utiliser le mot clé <code>params</code> pour un nombre
variable de paramètres au lieu de la notation <code>__arglist</code> qui n'est pas conforme CLS.
Interdit
UseSTAThreadAttributeForWindowsFormsEntryPoints
Le point d'entrée d'une application Windows Forms doit être marqué avec l'attribut
<code>System.STAThreadAttribute</code>.
Interdit
DeclareFinalizerForDisposableTypes Il faut implémenter le finaliseur car ce type
est<code>System.IDisposable</code> et contient des champs non managés.
Fortement déconseillé
DefineAttributeForISerializableTypes Un type héritant de <code>System.Runtime.Serialization.ISerializable</code> doit être marqué de l'attribut
<code>System.SerializableAttribute</code>.
Fortement déconseillé
DefineDeserializationMethodsForOptionalFields
Les champs de sérialisation optionnels doivent être gérés dans les
méthodes marquées <code>System.Runtime.Serialization.OnDeserialized</code> et <code>System.Runtime.Serialization.OnDeserializing</code>.
Fortement déconseillé
DontIgnoreMethodsReturnValue La valeur de retour d'une méthode ou d'un constructeur n'est ni
utilisée, ni assignée à une variable alors qu'un nouvel objet est retourné.
Fortement déconseillé
DontMakePointersVisible Un type pointeur doit être privé ou doit être en lecture seule. Fortement déconseillé
DontNestGenericInMemberSignatures_
Il faut éviter les types génériques imbriqués comme paramètres
de méthode. Fortement déconseillé
DontTouchForLoopVariable Attention à ne pas modifier la variable d'itération d'une boucle <code>for</code> à l'intérieur de celle-ci.
Fortement déconseillé
DontUseMultidimensionalIndexers Il est conseillé de ne pas déclarer plusieurs dimensions à un indexeur.
Fortement déconseillé
DontUseNonConstantStaticVisibleFields
Les champs statiques <code>public</code> ou
<code>protected</code> doivent être en lecture seule ou constants.
Fortement déconseillé
EnumeratorMustBeStronglyTyped Un type implémentant l'interface <code>System.Collections.IEnumerator</code> doit fournir une
propriété <code>Current</code> fortement typée afin que l'utilisateur n'ait pas à transtyper le type retourné par la propriété fournie par l'interface.
Fortement déconseillé
ImplementGenericInterfaceForCollections
Un type implémentant <code>System.Collections.IEnumerable</code> doit également
ListMustBeStronglyTyped Un type implémentant <code>System.Collections.IList</code>
doit fournir des méthodes fortement typées. Fortement déconseillé
NeverMakeCtorCallOverridableMethod
Le constructeur d'un type non scellé ne devrait jamais appeler une méthode virtuelle.
Fortement déconseillé
OverrideGetHashCodeWhenOverridingEquals
Un type qui surcharge la méthode <code>System.Object.Equals(Object)</code> doit aussi surcharger la méthode <code>System.Object.GetHashCode()</code>.
Fortement déconseillé
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 59/61
OverrideMethodsInIComparableImplementations
Un type implémentant l'interface
<code>System.IComparable</code> doit surcharger la méthode <code>System.Object.Equals(Object)</code> et les opérateurs <code>==</code>, <code>!=</code>, <code><</code>, <code>></code>.
Fortement déconseillé
ReviewParametersAttributeStringLiteral_
Il faut revoir les valeurs des attributs. Les valeurs des paramètres « version », « guid », « uri », « urn », ou « url » doivent correspondre à des valeurs correctes attendues.
Fortement déconseillé
AttributeArgumentShouldBeLinkedToAccessor
Chaque membre d'un attribut personnalisé doit être lié à une accesseur afin d'indiquer à l'utilisateur le caractère optionnel ou non de celui-ci.
Déconseillé
DefineAttributeForNonSerializableFields
Il faut marquer les champs qui ne doivent pas être sérialisés de
Un type qui ne contient que des méthodes et propriétés statiques ne devrait pas définir de constructeur d'instance public.
Déconseillé
DefineZeroValueForEnum La valeur par défaut d'une énumération est 0. Déconseillé DontCatchTooGeneralExceptions Il n'est pas recommandé d'attraper des exceptions avec un type
trop général. Déconseillé
DontDeclareRefAndOutParameters Ne pas déclarer des paramètres avec <code>out</code> ou
<code>ref</code>. Déconseillé
DontThrowBasicException Certaines exceptions ne doivent pas être utilisées car ne fournissent pas assez d'informations sur l'erreur levée.
Déconseillé
DontThrowRuntimeException Certaines exceptions ne doivent pas être utilisées car elles sont réservées à la CLR.
Déconseillé
DontUseCaseToDifferPublicIdentifiers
Il est déconseillé de différencier les identifiants seulement par leur casse de caractère.
Déconseillé
DontUseReservedKeywordsForIdentifiers
Les identifiants de namespaces et de types ne doivent pas
correspondre à des mots réservés des langages du CLR (casse de caractère non comprise).
Déconseillé
FollowSerializationMethodsImplementationRule
Une méthode gérant un événement de sérialisation n'a pas la
signature, le type de retour ou la visibilité appropriée. Déconseillé
FollowSuffixStandardForIdentifiers Nommer le type à l'aide du suffixe attendu pour le type de base. Déconseillé OverrideLinkDemandMustBeIdenticalToBase
Lorsque l'on surcharge ou implémente une méthode, les demandes de liaison doivent correspondre.
Déconseillé
OverrideOperatorEquals Il faut surcharger l'opérateur <code>==</code> dans les cas suivants : Lorsque la méthode
<code>System.Object.Equals(Object)</code> est surchargée dans un type valeur ou lorsque les opérateurs <code>+</code> et <code>-</code> sont surchargés dans un type référence.
Déconseillé
PreserveStackTraceWhenThrowingNewException
Une exception lancée à partir d'une autre exception devrait
toujours stocker la pile d'erreur originale. Déconseillé
ProvideTypeParameterForGenericMethods
Le type générique déclaré pour une méthode générique doit être au moins utilisé dans un type d'un paramètre.
Déconseillé
StaticTypesShouldBeSealed Un type ne contenant que des membres statiques doit être scellé. Déconseillé UseGenericEventHandler_ Il faut utiliser le délégué générique
<code>System.EventHandler<TEventArgs>(Object
sender,TEventArgs e)</code>.
Déconseillé
UseInt32ForEnumStorage Il est inutile de modifier le type pour le stockage des énumérations, ceci n'apporte aucun gain de performance
Déconseillé
UseInterfaceRatherThanClasses_ Dans un souci de généricité, il est bien plus flexible d'utiliser les
interfaces plutôt que les classes les implémentant. Déconseillé
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 60/61
UseStaticWhenPossible Une méthode qui n'accède pas aux données d'instance peut être
déclarée comme statique. Déconseillé
ConsiderUsingProperty Utiliser les propriétés lorsque cela est possible afin de respecter les standards .NET.
A éviter
DontCompareBooleanWithTrueOrFalse
Il est inutile de comparer explicitement un booléen avec
<code>true</code> ou <code>false</code> dans une expression conditionnelle.
A éviter
DontDefinePublicGenericLists Il est préférable d'utiliser un type dérivé de
<code>System.Collections.Generic.List<T></code>. A éviter
DontDirectlyReturnArray Une propriété ne devrait par retourner de tableau. En effet, les
tableaux retournés par les propriétés sont passés par référence, ils ne sont donc pas protégés en écriture, même si la propriété est en lecture seule.
A éviter
DontImplementConstructorForStaticTypes
Il est inutile d'implémenter un constructeur public pour un type qui ne déclare que des membres statiques.
A éviter
DontMakeRedundantInitialization_ Il est inutile d'initialiser un champ avec sa valeur par défaut. A éviter DontMakeTypeFieldsPublic Un champ ne doit pas être déclaré avec une visibilité publique,
sauf s'il est statique, constant ou déclaré dans un type imbriqué privé ou interne.
A éviter
DontPrefixEnumValuesWithEnumName
Il n'est pas nécessaire de préfixer les champs d'une énumération
avec le mot <code>Enum</code> pour indiquer que ce sont des champs d'énumération.
A éviter
DontUseReservedKeywordForEnum Il faut rajouter un nouveau champ à la fin d'une énumération si
l'on souhaite la modifier de façon non impactante, et non pas utiliser le mot-clé <code>reserved</code>.
A éviter
DontUseTypeNamesForNamespaces Le nom d'un type ne doit pas correspondre au nom d'un
namespace défini dans votre projet ou dans le framework .NET. A éviter
FlagsEnumsMustHavePluralNames Une énumération marquée par <code>System.FlagsAttribute</code> doit posséder un nom conjugué au pluriel.
A éviter
IdentifiersMustNotContainTypeNames
Les identificateurs des paramètres d'un membre doivent
véhiculer leur signification et non décrire leur type, qui devrait être fourni par les outils de développement.
A éviter
ImplementNamedMethodsWhenOverloadingOperators
Lorsque l?on surcharge un opérateur, il faut prévoir
d?implémenter une méthode alternative correspondante, par exemple fournir la méthode <code>Add</code> lorsque l?on surcharge l?opérateur <code>+</code>.
A éviter
InitializeStaticFieldsInline Il est préférable d?initialiser les variables statiques là où elles sont déclarées (inline) et éviter d?utiliser des constructeurs statiques.
A éviter
OnlyFlagsEnumsMustHavePluralNames
Une énumération ne possédant pas l?attribut
<code>System.FlagsAttribute</code> ne peut avoir qu?une seule valeur à la fois, son identificateur doit donc être conjugué au singulier.
A éviter
PassBaseTypeAsParameters Les types des paramètres doivent être les plus génériques possibles.
A éviter
RemoveUnusedInternalClasses Un type interne jamais utilisé dans l'assembly doit être supprimé. A éviter RemoveUnusedParameters Un paramètre de méthode qui n'est pas utilisé doit être
supprimé. A éviter
RemoveUnusedPrivateFields Un champ privé qui n'est pas utilisé dans le type doit être supprimée.
A éviter
Audit de code de l’application SharpDevelop 01/01/2011
Confidentiel - Ce document est la propriété de Kalistick 61/61
RemoveUnusedPrivateMethods Une méthode privée qui n'est pas utilisée dans le type doit être
supprimée. De même, une méthode interne non utilisée dans l'assembly doit être supprimée.
A éviter
ReviewUnusedLocals Une variable locale qui n'est pas utilisée doit être supprimée.
A éviter
SealAttributesDeclarations Il est conseillé de sceller l'implémentation d'un nouvel attribut. A éviter DisposeDisposableFields_ Tous les champs <em>disposables</em> (héritant de
<code>System.IDisposable</code>) doivent être disposés dans la méthode <code>System.IDisposable.Dispose()</code> de ce type.
[Aucune]
8.4.2 Seuils de couverture de code
Le tableau suivant présente les seuils de couverture de code attendus selon la priorité de test des méthodes
(TRI). Cette priorité de test est échelonnée selon cinq niveaux, en fonction d’intervalles de TRI :
Priorité de test [ TRI Min. TRI Max.[ Seuil Sévérité