System.x ou x ?

Bonjour,

Je suis en train de "nettoyer" un code auto-généré en remplaçant tous les System.x en x . Exemple, System.Int32 en Int32 !

Et tout en faisant ça, je me demande si j'ai raison.
Ca change quelque chose au niveau compilation ? niveau perf ? autre ?

Votre avis éclairé svp :)

Papy !

magnifique...perte de temps :)

niveau compilation, ca change rien
niveau perf, ca change rien
niveau autre, ca change rien.

Citation:

---

Envoyé par Louis-Guillaume Morand

niveau autre, ca change rien.

---

Si, ça peut éventuellement lever une ambiguité...

Exemple (purement théorique et sans intérêt) :

Code:

---

1 2 3 4 5 6 7

using System.Windows.Forms; // Windows Forms using System.Windows.Controls; // WPF using System.Web.UI.WebControls; // ASP.NET   ...   ListView lv = new ListView(); // Erreur de compilation car ListView existe dans les 3 namespaces cités plus haut

---

Mais bon, ça reste un cas marginal...

oui je suis d'accord pour cela, mais là on parle du cas, où il supprime un namespace superflu, donc sans ambiguité (puisqu'il ne l'oterait pas si ca compilait pas).
de plus, sur les types de bases, c'est rare d'avoir une autre classe se nommant Int32.

@Papy214 => tu peux investir dans resharper 4.5. alt+e pui alt+c et il te nettoie toute ta solution en enlevant sans risque ces namespaces superflus, mais ce n'est que pour améliorer la lisibilité du code, rien d'autre

Mais la lisibilité du code est quand même un élément important.. enfin à mon avis.. quand je reprend le code de quelqu'un j'aime bien voir des codes pas trop toufu, claires et concis, bien commentés..
Il y a surement des moyens de faire plus rapidement que chercher à la main, mais je ne pense pas qu'il s'agisse d'une "perte de temps" que d'éclaircir son code.

Cordialement :)

Citation:

---

Envoyé par Lyche

Mais la lisibilité du code est quand même un élément important.. enfin à mon avis.. quand je reprend le code de quelqu'un j'aime bien voir des codes pas trop toufu, claires et concis, bien commentés..

---

Heu... la lisibilité d'un code autogénéré, on s'en fout, parce que par définition un code autogénéré ne doit pas être modifié à la main.

ca dépend. le generateur de code peut simplement partir d'un modèle de base de données et générer DAL et BLL pour gagner du temps au démarrage. Ces couches évoluant par la suite avec les principes plus complexes

Donc, en gros, ça ne sert à rien ! :)

En fait, je me posais cette question par rapport à une autre question posée ici. Il s'agissait de savoir s'il était bon de qualifier des noms de champs par leurs noms de table dans une requète SQL. Cette idée saugrenue d'un parallèle avec les namespaces m'est venue en pensant à ça.

Merci pour vos remarques !

pour tes requetes, je pratique (et vois souvent), cette forme là

Table T_ USERS
USR_NAME
USR_FIRSTNAME
USR_ROLE_ID
etc.

Table T_ROLE
ROL_ID
ROL_NAME

ca permet de ne pas avoir de nom de champ en double et d'éviter à avoir à préciser le nom de la table devant le champ, même si, je ne pense pas que ca change les performances de la requête en soit même