Archive for the 'Trucs et Astuces' Category

Précompilation des fichiers aspx

Julien on sept 12th 2008

Dans une application asp.net, de base, les fichiers aspx ne sont pas compilés. Cette étape est réalisée par IIS lors du déploiement. En conséquence, toute erreur de syntaxe dans l'un de ces fichiers passera inaperçue lors de la compilation de la solution par le serveur d'intégration continue. Comme les vues sont rarement testées, on peut donc facilement se retrouver à déployer des fichiers contenants des erreurs de syntaxe... Aïe!

Pour éviter ce problème, il est possible d'appeler l'outil aspnet_compiler.exe directement depuis le fichier de build nant. Les quelques lignes suivantes auront donc pour effet de provoquer la compilation de l'ensemble des fichiers aspx de la solution et donc de rapporter toute erreur, magique!

  1.  
  2. <property name="build.dir" value="${build.base}/${project::get-name()}-${project.config}/"/>
  3. <property name="aspxbuild.dir" value="${build.dir}\aspx" />
  4. <property name="aspxvirtual.dir" value="${build.dir}\iis" />
  5.  
  6. <mkdir dir="${aspxbuild.dir}" />
  7. <mkdir dir="${aspxvirtual.dir}" />
  8. <copy todir="${aspxbuild.dir}">
  9. <fileset basedir="${aspx.dir}">
  10. <include name="**" />
  11. </fileset>
  12. </copy>
  13.  
  14. <mkiisdir dirpath="${aspxvirtual.dir}" vdirname="aspprecompile" />
  15. <exec program="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe" useruntimeengine="true">
  16. <arg value="-p" />
  17. <arg value="${aspxbuild.dir}" />
  18. <arg value="-v" />
  19. <arg value="aspprecompile" />
  20. <arg value="${aspxvirtual.dir}" />
  21. </exec>
  22. <deliisdir vdirname="aspprecompile" />
  23. <delete dir="${aspxvirtual.dir}" />
  24.  

Remarque: il faut avoir installé iis et NantContrib sur le serveur de build !

Filed in Trucs et Astuces | 4 responses so far

Pourquoi j’utilise un préfixe pour mes membres privés

Julien on mai 21st 2008

J'utilise un préfixe (A savoir: "_") pour indiquer les membres privés de mes classes. Autrement dit, une de mes classes ressemblera à cela:

  1. public class Car
  2. {
  3. private string _model;
  4. private string _owner;
  5. [...]
  6. }

Différentes notations existent ici et là, notamment "m_". Mais de nombreuses personnes ont aussi choisi de ne simplement pas démarquer les membres privés des variables locales et autres paramètres. Je suis tout à fait conscient que c'est un sujet polémique, et que les avis sont très partagés. J'aimerai toutefois expliquer pourquoi je trouve personnellement qu'il est important d'avoir cette distinction.

En guise de référence, voici ce à quoi pourrait ressembler une classe sans préfixe:

  1. public class Transportation
  2. {
  3. private TransportStatus status;
  4.  
  5. public TransportStatus Status
  6. {
  7. get { return status; }
  8. }
  9.  
  10. public void ChangeTransportStatus(TransportStatus status)
  11. {
  12. this.status= status;
  13. DoSomeStuff();
  14. }
  15. }

Il y a plusieurs problèmes avec cette classe:

  • Utiliser un préfixe permet de se passer du mot clef "this", ce qui réduit le "bruit" dans les sources. En effet, écrire "this.model" revient en quelque sorte à utiliser un préfixe ("this."). Autant utiliser quelque chose de plus court du coup!
  • Qui plus est, l'utilisation de "this" est optionnelle en C#. On se retrouve rapidement avec un mélange des genres ou certains accès sont fait avec "this". et d'autres le sont sans aucun préfixe. Si on ne connait pas bien le code, on est obligé de constamment vérifier si telle variable est privée avec l'intellisense ou en naviguant dans la classe.
  • L'absence de préfixe provoque rapidement des confusions. Par exemple, dans la fonction ChangeTransportStatus, 2 variables ont le même nom: mon paramètre et mon membre privé. Le code étant ici très simple, il est difficile de se tromper. Dans une fonction de 50 lignes, il peut y avoir potentiellement beaucoup plus d'erreurs: il est courant d'utiliser le paramètre à la place du membre...
  • J'ai également une propriété "Status" qui ressemble énormément à mon membre privé "status" dans mon exemple. L'utilisation du mot clef "this" ne règle en rien la confusion potentielle. Sans préfixe il faut donc être très attentif à l'utilisation des majuscules. Sur certaines lettres la distinction est évidente, sur d'autres, elle l'est beaucoup moins! L'expérience montre que sans préfixe, le code d'une classe utilisera plus ou moins aléatoirement la propriété ou le membre privé en fonction de la rigueur et/ou de l'humeur des développeurs. Pour peu que la propriété encapsule un peu de logique, on se retrouve rapidement avec des effets de bord indésirable.
  • Enfin, et je vous accorde que c'est un argument très discutable mais les nouveaux outils de Microsoft génère le code avec des préfixes (voir Linq to Sql par exemple). Si eux le font, c'est peut être qu'il y a du bon ;-).

Alors, prêt à utiliser un préfixe? :-)

Filed in Qualité du code, Trucs et Astuces | One response so far

Comment vérifier qu’une chaine de caractère est vide de façon optimale?

Julien on avr 25th 2008

J'ai eu l'occasion de m'apercevoir qu'il y avait un certain besoin autour de trucs et astuces sur .NET. Je vais donc dorénavant essayer de poster ce qui me passera par la tête :). A noter que ces billets ont vocation à être court et couvrir des points très précis!

Comment vérifier qu'une chaine de caractère est vide de façon optimale?

Il existe plusieurs façon de faire la comparaison:
1) myString == ""
2) myString == String.Empty
3) myString.Length == 0
4) String.IsNullOrEmpty(myString)

La façon la plus performante est la solution 3, myString.Lengh == 0, à condition d'être sur que la chaine de caractère n'est pas nulle. Si la chaine de caractère peut potentiellement être nulle, String.IsNullOrEmpty(myString) est idéal. A noter d'ailleurs que String.IsNullOrEmpty(myString) utilise lui même string.Length == 0. En voici l'implémentation en guise de référence:

  1. public static bool IsNullOrEmpty(string value)
  2. {
  3. if (value != null)
  4. {
  5. return (value.Length == 0);
  6. }
  7. return true;
  8. }

Filed in .NET, Trucs et Astuces | No responses yet