Opinion sans originalité sur les exceptions

Cet article est en réalité un courriel répondant à une question sur les bonnes pratiques avec les exceptions. S’il peut être utile à quelqu’un, tant mieux!

Lisez cet article sur christianrondeau.net

Je speak C#

Une grande question, difficile à répondre; dans quelle langue doit-on déclarer ses variables, méthodes et classes? Dans quelle langue devrait-on écrire ses commentaires?La syntaxe

Premièrement, il faut noter que je suis un francophone aguerri, prêt à bondir pour défendre sa langue. Mais, car il y a un mais, un problème survient; lorsqu’on développe une application, on utilise un langage de programmation. Ce langage est en quelque sorte une langue à part, un sous-ensemble de l’anglais. Sa structure et ses mots correspondent à l’anglais. Quels sont les impacts? Une lecture naturelle.

Lisez cet article sur christianrondeau.net

Deux, c’est bien, mais un, c’est mieux!

Un petit article sur un détail important mais qui, je crois, n’a pas été beaucoup discuté; le nombre d’appels sur des objets dans une ligne de code.

Prenons par exemple la ligne de code suivante, ou employe est un paramètre de méthode:

int assignements = employe.GetHoraire().GetAssigments(this.jourEnCours).Length;

Elle peut paraître exagérée pour certains, mais elle représente plusieurs cas que j’ai vu et que j’ai fait. Beaucoup auront prévu le coup; en production l’erreur suivante est lancée:

Object reference not set to an instance of an object.

Lisez cet article sur christianrondeau.net

Un éditeur de code semi-graphique

Dans la veine de Le code; un simple format de spécifications?, voici une idée qui pourrait peut-être devenir une jointure possible entre les avantages des modèles graphiques et les éditeurs déjà très avancés disponibles aujourd’hui. Elle éveillera peut-être quelques gens ayant travaillé avec Macromedia Flash.

Vérifions certains requis pour une solution applicable:

• Le code doit rester flexible
• On doit pouvoir coder aussi rapidement qu’en mode textuel pur
• On doit pouvoir accéder à des vues différentes en navigant et en contexte
• Une application de collaboration et de développement devrait permettre de “voir” autant la documentation que le code d’une manière flexible et fortement typée

Imagineons maintenant une page de code dans Microsoft Visual Studio. Considéront maintenant chacun des éléments imbriquables dans l’exemple suivant:

1.public Person FindOwner( Car lostCar )
2.{
3.  ValidateCarOwnership( lostCar );
4.  Person owner = base.FindOwner( lostCar );
5.  if( owner != null )
6.    return owner;
7.  else
8.    return new UnknownOwner();
9.}

Si on considère base.FindOwner, on sait qu’un appel est fait à la super classe. Celle-ci contient un algorithme et un contexte d’exécution lui aussi encapsulé. Dans ce cas précis, nous pouvons imaginer les choses suivantes:

• Ne voir que la hiérarchie des appels à l’intérieur de la méthode, dans un format de liste
• Remplacer la ligne 4 par le code du parent (peut-être grisé)
• Garder l’opération et remplacer la méthode par sa documentation
• Remplacer la ligne 3 par l’opération et sa méthode imbriqués
• “Écraser” la classe et son parent ensemble de manière à ne voir que l’implémentation finale pour faciliter la lecture

Pour arriver à modeler la vue textuelle, il faudrait que chacun des éléments soit utilisable comme un objet visuel sur lequel un clic simple, par exemple, sélectionnerait l’élément (en plaçant bien sûr le curseur sous la souris dans le texte). Une double-clic ouvrirait l’élément dans son contexte (encore une fois, un code de couleur pourrait identifier les éléments liant les variables du corps de la méthode avec l’appellant). Un contrôle-clic quant à lui donnerait plein focus à l’élément sélectionné. Pour chaque élément sous la souris, de petits icônes pourraient être disponibles pour passer du code à la documentation, et de la documentation à une liste cliquable des relations.

D’un côté, une telle approche forcerait le développeur à mettre autant d’emphase à clarifier les relations entre les objets que les objets eux-même, ce qui en soi n’est pas une mauvaise chose. D’un autre, elle offrirait une manière plus “graphique” de travailler sur le code dans un environnement liant étroitement les documents d’analyse à l’implémentation. Finalement, cette approche permettrait de travailler sur un aspect du code en gardant une approche 100% orientée objet.

Un tel éditeur sera par contre un vrai défi à prototyper.