Je travaillais récemment avec un DateTimeobjet et j'ai écrit quelque chose comme ceci:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

La documentation d'intellisense AddDays()indique qu'elle ajoute un jour à la date, ce qu'elle ne fait pas - elle retourne en fait une date avec un jour ajouté, vous devez donc l'écrire comme suit :

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

Celui-ci m'a mordu plusieurs fois auparavant, j'ai donc pensé qu'il serait utile de cataloguer les pires pièges en C #.

private int myVar;
public int MyVar
{
    get { return MyVar; }
}

Blammo. Votre application se bloque sans trace de pile. Arrive tout le temps.

(Remarquez les majuscules MyVarau lieu des minuscules myVardans le getter.)

Type.GetType

Celui que j'ai vu mordre beaucoup de gens est Type.GetType(string). Ils se demandent pourquoi cela fonctionne pour les types de leur propre assemblage, et certains types comme System.String, mais pas System.Windows.Forms.Form. La réponse est qu'il ne regarde que dans l'assemblage actuel et dans mscorlib.

Méthodes anonymes

C # 2.0 a introduit des méthodes anonymes, conduisant à des situations désagréables comme celle-ci:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            ThreadStart ts = delegate { Console.WriteLine(i); };
            new Thread(ts).Start();
        }
    }
}

Qu'est-ce que cela imprimera? Eh bien, cela dépend entièrement de la programmation. Il imprimera 10 chiffres, mais il n'imprimera probablement pas 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ce à quoi vous pourriez vous attendre. Le problème est que c'est la ivariable qui a été capturée, pas sa valeur au moment de la création du délégué. Cela peut être résolu facilement avec une variable locale supplémentaire de la bonne portée:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            int copy = i;
            ThreadStart ts = delegate { Console.WriteLine(copy); };
            new Thread(ts).Start();
        }
    }
}

Exécution différée des blocs d'itérateur

Ce «test unitaire du pauvre» ne passe pas - pourquoi pas?

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Test
{
    static IEnumerable<char> CapitalLetters(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(input);
        }
        foreach (char c in input)
        {
            yield return char.ToUpper(c);
        }
    }

    static void Main()
    {
        // Test that null input is handled correctly
        try
        {
            CapitalLetters(null);
            Console.WriteLine("An exception should have been thrown!");
        }
        catch (ArgumentNullException)
        {
            // Expected
        }
    }
}

La réponse est que le code dans la source du CapitalLetterscode n'est pas exécuté jusqu'à ce que la MoveNext()méthode de l'itérateur soit appelée pour la première fois.

J'ai d'autres bizarreries sur ma page casse - tête .

Re-lever des exceptions

Un piège qui reçoit de nombreux nouveaux développeurs est la sémantique d'exception de re-throw.

Beaucoup de temps, je vois du code comme celui-ci

catch(Exception e) 
{
   // Do stuff 
   throw e; 
}

Le problème est qu'il efface la trace de la pile et rend le diagnostic des problèmes beaucoup plus difficile, car vous ne pouvez pas suivre l'origine de l'exception.

Le code correct est soit l'instruction throw sans argument:

catch(Exception)
{
    throw;
}

Ou encapsuler l'exception dans une autre, et utiliser l'exception interne pour obtenir la trace de pile d'origine:

catch(Exception e) 
{
   // Do stuff 
   throw new MySpecialException(e); 
}

La fenêtre de surveillance de Heisenberg

Cela peut vous mordre gravement si vous effectuez des tâches de chargement à la demande, comme ceci:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

Supposons maintenant que vous ayez du code ailleurs en utilisant ceci:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

Vous voulez maintenant déboguer votre CreateMyObj()méthode. Vous avez donc mis un point d'arrêt sur la ligne 3 ci-dessus, avec l'intention d'entrer dans le code. Juste pour faire bonne mesure, vous mettez également un point d'arrêt sur la ligne ci-dessus qui dit _myObj = CreateMyObj();, et même un point d'arrêt à l'intérieur de CreateMyObj()lui-même.

Le code atteint votre point d'arrêt sur la ligne 3. Vous entrez dans le code. Vous vous attendez à entrer le code conditionnel, car _myObjest évidemment nul, non? Euh ... alors ... pourquoi at-il sauté la condition et est allé directement à return _myObj?! Vous passez votre souris sur _myObj ... et en effet, cela a une valeur! Comment est-ce arrivé?!

La réponse est que votre IDE lui a fait obtenir une valeur, car vous avez une fenêtre de "surveillance" ouverte - en particulier la fenêtre de surveillance "Autos", qui affiche les valeurs de toutes les variables / propriétés pertinentes pour la ligne d'exécution actuelle ou précédente. Lorsque vous avez atteint votre point d'arrêt sur la ligne 3, la fenêtre de surveillance a décidé que vous seriez intéressé de connaître la valeur de MyObj- donc dans les coulisses, en ignorant l'un de vos points d'arrêt , il est allé et a calculé la valeur de MyObjpour vous - y compris l'appel à CreateMyObj()ce définit la valeur de _myObj!

C'est pourquoi j'appelle cela la fenêtre de surveillance Heisenberg - vous ne pouvez pas observer la valeur sans l'affecter ... :)

JE T'AI EU!

Edit - Je pense que le commentaire de @ ChristianHayter mérite d'être inclus dans la réponse principale, car il ressemble à une solution de contournement efficace pour ce problème. Donc, chaque fois que vous avez une propriété paresseuse ...

Décorez votre propriété avec [DebuggerBrowsable (DebuggerBrowsableState.Never)] ou [DebuggerDisplay ("<chargé à la demande>")]. - Christian Hayter

Voici une autre fois qui me fait:

static void PrintHowLong(DateTime a, DateTime b)
{
    TimeSpan span = a - b;
    Console.WriteLine(span.Seconds);        // WRONG!
    Console.WriteLine(span.TotalSeconds);   // RIGHT!
}

TimeSpan.Seconds est la partie en secondes de l'intervalle de temps (2 minutes et 0 seconde a une valeur de secondes de 0).

TimeSpan.TotalSeconds est la durée totale mesurée en secondes (2 minutes ont une valeur totale de 120 secondes).

Fuite de mémoire car vous n'avez pas décroché les événements.

Cela a même surpris certains développeurs seniors que je connais.

Imaginez un formulaire WPF contenant beaucoup de choses, et quelque part là-dedans, vous vous abonnez à un événement. Si vous ne vous désabonnez pas, le formulaire entier est conservé en mémoire après avoir été fermé et dé-référencé.

Je crois que le problème que j'ai vu était la création d'un DispatchTimer dans le formulaire WPF et l'abonnement à l'événement Tick, si vous ne faites pas de - = sur le minuteur, votre formulaire perd de la mémoire!

Dans cet exemple, votre code de démontage devrait avoir

timer.Tick -= TimerTickEventHandler;

Celui-ci est particulièrement délicat puisque vous avez créé l'instance de DispatchTimer dans le formulaire WPF, vous pensez donc que ce serait une référence interne gérée par le processus de récupération de place ... malheureusement, DispatchTimer utilise une liste interne statique d'abonnements et de services demandes sur le thread d'interface utilisateur, de sorte que la référence est «détenue» par la classe statique.

Peut-être pas vraiment un problème parce que le comportement est écrit clairement dans MSDN, mais m'a cassé le cou une fois parce que je l'ai trouvé plutôt contre-intuitif:

Image image = System.Drawing.Image.FromFile("nice.pic");

Ce gars laisse le "nice.pic"fichier verrouillé jusqu'à ce que l'image soit supprimée. Au moment où je l'ai fait face, je pensais que ce serait bien de charger des icônes à la volée et je ne savais pas (au début) que je me retrouvais avec des dizaines de fichiers ouverts et verrouillés! L'image garde une trace de l'endroit où elle a chargé le fichier ...

Comment résoudre ça? Je pensais qu'un paquebot ferait l'affaire. Je m'attendais à un paramètre supplémentaire pour FromFile(), mais n'en avais aucun, alors j'ai écrit ceci ...

using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
    image = System.Drawing.Image.FromStream(fs);
}

Si vous comptez ASP.NET, je dirais que le cycle de vie des formulaires Web est un gros problème pour moi. J'ai passé d'innombrables heures à déboguer du code de formulaires Web mal écrit, simplement parce que beaucoup de développeurs ne comprennent pas vraiment quand utiliser quel gestionnaire d'événements (moi y compris, malheureusement).

opérateurs == surchargés et conteneurs non typés (listes, ensembles de données, etc.):

string my = "my ";
Debug.Assert(my+"string" == "my string"); //true

var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");

// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false

Solutions?

• toujours utiliser string.Equals(a, b) lorsque vous comparez des types de chaîne

• en utilisant des génériques comme List<string>pour garantir que les deux opérandes sont des chaînes.

[Serializable]
class Hello
{
    readonly object accountsLock = new object();
}

//Do stuff to deserialize Hello with BinaryFormatter
//and now... accountsLock == null ;)

Morale de l'histoire: les initialiseurs de champ ne sont pas exécutés lors de la désérialisation d'un objet

DateTime.ToString ("jj / MM / aaaa") ; Ce ne sera en fait pas vous donnera toujours le jj / mm / aaaa, mais il tiendra compte des paramètres régionaux et remplacera votre séparateur de date en fonction de l'endroit où vous vous trouvez. Donc, vous pourriez obtenir jj-MM-aaaa ou quelque chose de similaire.

La bonne façon de procéder consiste à utiliser DateTime.ToString ("dd '/' MM '/' yyyy");

DateTime.ToString ("r") est censé se convertir en RFC1123, qui utilise GMT. GMT est à une fraction de seconde de UTC, et pourtant le spécificateur de format "r" ne se convertit pas en UTC , même si le DateTime en question est spécifié comme Local.

Il en résulte le piège suivant (varie en fonction de la distance de votre heure locale par rapport à UTC):

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

Oups!

J'ai vu celui-ci posté l'autre jour, et je pense qu'il est assez obscur et douloureux pour ceux qui ne connaissent pas

int x = 0;
x = x++;
return x;

Comme cela renverra 0 et non 1 comme la plupart s'y attendraient

Je suis un peu en retard à cette fête, mais j'ai deux accrochages qui m'ont tous deux mordu récemment:

Résolution DateTime

La propriété Ticks mesure le temps en 10 millionièmes de seconde (blocs de 100 nanosecondes), mais la résolution n'est pas de 100 nanosecondes, elle est d'environ 15 ms.

Ce code:

long now = DateTime.Now.Ticks;
for (int i = 0; i < 10; i++)
{
    System.Threading.Thread.Sleep(1);
    Console.WriteLine(DateTime.Now.Ticks - now);
}

vous donnera une sortie de (par exemple):

0
0
0
0
0
0
0
156254
156254
156254

De même, si vous regardez DateTime.Now.Millisecond, vous obtiendrez des valeurs en segments arrondis de 15,625 ms: 15, 31, 46, etc.

Ce comportement particulier varie d'un système à l'autre , mais il existe d'autres problèmes liés à la résolution dans cette API de date / heure.

Path.Combine

Un excellent moyen de combiner les chemins d'accès aux fichiers, mais il ne se comporte pas toujours comme vous vous y attendez.

Si le deuxième paramètre commence par un \caractère, il ne vous donnera pas un chemin complet:

Ce code:

string prefix1 = "C:\\MyFolder\\MySubFolder";
string prefix2 = "C:\\MyFolder\\MySubFolder\\";
string suffix1 = "log\\";
string suffix2 = "\\log\\";

Console.WriteLine(Path.Combine(prefix1, suffix1));
Console.WriteLine(Path.Combine(prefix1, suffix2));
Console.WriteLine(Path.Combine(prefix2, suffix1));
Console.WriteLine(Path.Combine(prefix2, suffix2));

Vous donne cette sortie:

C:\MyFolder\MySubFolder\log\
\log\
C:\MyFolder\MySubFolder\log\
\log\

Lorsque vous démarrez un processus (à l'aide de System.Diagnostics) qui écrit sur la console, mais que vous ne lisez jamais le flux Console.Out, après une certaine quantité de sortie, votre application semble se bloquer.

Aucun raccourci opérateur dans Linq-To-Sql

Voyez ici .

En bref, à l'intérieur de la clause conditionnelle d'une requête Linq-To-Sql, vous ne pouvez pas utiliser de raccourcis conditionnels comme ||et &&pour éviter les exceptions de référence nulles; Linq-To-Sql évalue les deux côtés de l'opérateur OR ou AND même si la première condition évite d'avoir à évaluer la deuxième condition!

Utilisation de paramètres par défaut avec des méthodes virtuelles

abstract class Base
{
    public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}

class Derived : Base
{
    public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}

...

Base b = new Derived();
b.foo();

Sortie:
base dérivée

Objets de valeur dans des collections mutables

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

n'a aucun effet.

mypoints[i]renvoie une copie d'un Pointobjet valeur. C # vous permet avec bonheur de modifier un champ de la copie. Ne rien faire en silence.

Mise à jour: cela semble être corrigé dans C # 3.0:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

Peut-être pas le pire, mais certaines parties du framework .net utilisent des degrés tandis que d'autres utilisent des radians (et la documentation qui apparaît avec Intellisense ne vous dit jamais lequel, vous devez visiter MSDN pour le savoir)

Tout cela aurait pu être évité en ayant une Angleclasse à la place ...

Pour les programmeurs C / C ++, la transition vers C # est naturelle. Cependant, le plus gros problème que j'ai rencontré personnellement (et que j'ai vu avec d'autres faire la même transition) n'est pas de comprendre pleinement la différence entre les classes et les structures en C #.

En C ++, les classes et les structures sont identiques; ils ne diffèrent que par la visibilité par défaut, où les classes par défaut à la visibilité privée et les structures par défaut à la visibilité publique. En C ++, cette définition de classe

    class A
    {
    public:
        int i;
    };

est fonctionnellement équivalent à cette définition de structure.

    struct A
    {
        int i;
    };

En C #, cependant, les classes sont des types de référence tandis que les structures sont des types de valeur. Cela fait un GRAND différence dans (1) la décision de les utiliser les uns par rapport aux autres, (2) le test de l'égalité des objets, (3) les performances (par exemple, boxe / déballage), etc.

Il existe toutes sortes d'informations sur le Web liées aux différences entre les deux (par exemple, ici ). J'encourage fortement toute personne effectuant la transition vers C # à avoir au moins une connaissance pratique des différences et de leurs implications.

Collecte des ordures et disposer (). Bien que vous n'ayez rien à faire pour libérer de la mémoire , vous devez quand même libérer des ressources via Dispose (). C'est une chose extrêmement facile à oublier lorsque vous utilisez WinForms ou suivez des objets de quelque manière que ce soit.

Implémentation de tableaux IList

Mais ne l'implémentez pas. Lorsque vous appelez Ajouter, il vous indique que cela ne fonctionne pas. Alors pourquoi une classe implémente-t-elle une interface alors qu'elle ne peut pas la supporter?

Compile, mais ne fonctionne pas:

IList<int> myList = new int[] { 1, 2, 4 };
myList.Add(5);

Nous avons beaucoup ce problème, car le sérialiseur (WCF) transforme tous les ILists en tableaux et nous obtenons des erreurs d'exécution.

foreach boucle l'étendue des variables!

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

imprime cinq "amet", tandis que l'exemple suivant fonctionne très bien

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

MS SQL Server ne peut pas gérer les dates antérieures à 1753. Significativement, cela n'est pas synchronisé avec la DateTime.MinDateconstante .NET , qui est 1/1/1. Donc, si vous essayez de sauver un esprit, une date malformée (comme cela m'est arrivé récemment lors d'une importation de données) ou simplement la date de naissance de Guillaume le Conquérant, vous aurez des ennuis. Il n'existe aucune solution de contournement intégrée pour cela; si vous devez probablement travailler avec des dates antérieures à 1753, vous devez écrire votre propre solution de contournement.

The Nasty Linq Caching Gotcha

Voir ma question qui a conduit à cette découverte, et le blogueur qui a découvert le problème.

En bref, le DataContext conserve un cache de tous les objets Linq-to-Sql que vous avez déjà chargés. Si quelqu'un d'autre modifie un enregistrement que vous avez précédemment chargé, vous ne pourrez pas obtenir les dernières données, même si vous rechargez explicitement l'enregistrement!

Cela est dû à une propriété appelée ObjectTrackingEnabledsur le DataContext, qui par défaut est vraie. Si vous définissez cette propriété sur false, l'enregistrement sera à nouveau chargé à chaque fois ... MAIS ... vous ne pouvez pas conserver les modifications apportées à cet enregistrement avec SubmitChanges ().

JE T'AI EU!

Le contrat sur Stream.Read est quelque chose que j'ai vu beaucoup de gens:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

La raison pour laquelle c'est faux est que vous Stream.Readlirez au plus le nombre d'octets spécifié, mais qu'il est entièrement libre de lire seulement 1 octet, même si 7 autres octets sont disponibles avant la fin du flux.

Cela n'aide pas que cela ressemble à Stream.Writece qui est garanti d'avoir écrit tous les octets s'il retourne sans exception. Cela n'aide pas non plus que le code ci-dessus fonctionne presque tout le temps . Et bien sûr, cela n'aide pas qu'il n'y ait pas de méthode prête à l'emploi pour lire correctement N octets correctement.

Donc, pour boucher le trou et augmenter la prise de conscience de cela, voici un exemple d'une bonne façon de procéder:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

Événements

Je n'ai jamais compris pourquoi les événements sont une fonctionnalité linguistique. Ils sont compliqués à utiliser: vous devez vérifier la valeur null avant d'appeler, vous devez vous désinscrire (vous-même), vous ne pouvez pas savoir qui est inscrit (par exemple: je me suis inscrit?). Pourquoi un événement n'est-il pas simplement une classe dans la bibliothèque? Fondamentalement, un spécialiste List<delegate>?

Aujourd'hui, j'ai corrigé un bug qui échappait depuis longtemps. Le bogue se trouvait dans une classe générique utilisée dans un scénario multithread et un champ int statique a été utilisé pour fournir une synchronisation sans verrouillage à l'aide d'Interlocked. Le bogue était dû au fait que chaque instanciation de la classe générique pour un type a sa propre statique. Ainsi, chaque thread a son propre champ statique et il n'a pas été utilisé de verrou comme prévu.

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

Cela imprime 5 10 5

Les énumérables peuvent être évalués plusieurs fois

Cela vous mordra lorsque vous aurez un énumérable paresseusement énuméré et que vous le répéterez deux fois et obtiendrez des résultats différents. (ou vous obtenez les mêmes résultats mais il s'exécute deux fois inutilement)

Par exemple, lors de l'écriture d'un certain test, j'avais besoin de quelques fichiers temporaires pour tester la logique:

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

Imaginez ma surprise quand File.Delete(file)jette FileNotFound!!

Ce qui se passe ici, c'est que l' filesénumérable a été itéré deux fois (les résultats de la première itération ne sont tout simplement pas mémorisés) et à chaque nouvelle itération, vous serez appelé de nouveau Path.GetTempFilename()afin d'obtenir un ensemble différent de noms de fichiers temporaires.

La solution est, bien sûr, d'énumérer avec impatience la valeur en utilisant ToArray()ou ToList():

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

C'est encore plus effrayant lorsque vous faites quelque chose de multi-thread, comme:

foreach (var file in files)
    content = content + File.ReadAllText(file);

et vous découvrez content.Lengthest toujours 0 après toutes les écritures !! Vous commencez ensuite à vérifier rigoureusement que vous n'avez pas de condition de course quand .... après une heure perdue ... vous vous êtes rendu compte que c'est juste cette toute petite chose énumérable que vous avez oubliée ....

Je viens de trouver un étrange qui m'a coincé dans le débogage pendant un certain temps:

Vous pouvez incrémenter null pour un entier nullable sans lancer une excecption et la valeur reste nulle.

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

TextInfo textInfo = Thread.CurrentThread.CurrentCulture.TextInfo;

textInfo.ToTitleCase("hello world!"); //Returns "Hello World!"
textInfo.ToTitleCase("hElLo WoRld!"); //Returns "Hello World!"
textInfo.ToTitleCase("Hello World!"); //Returns "Hello World!"
textInfo.ToTitleCase("HELLO WORLD!"); //Returns "HELLO WORLD!"

Oui, ce comportement est documenté, mais cela ne le rend certainement pas correct.