Refactoring : La bonne longueur pour une méthode

Un objectif important du refactoring est d’obtenir des méthodes courtes. Pourquoi ? Parce qu’un code court est plus simple à lire et à maintenir, provoquera moins d’erreurs et sera plus modulaire. D’accord, ça c’est facile à comprendre.

Mais qu’appelle-t-on une méthode courte ? Quand sait-on qu’une méthode est assez courte ? Quelle unité de longueur doit-on utiliser ? La réponse à cette question est moins évidente qu’il n’y parait.

Refactoring: un exemple simple en Ruby

Bonjour,

Récemment, on m’a demandé « A quoi ça sert, le refactoring ? ». À cette question, ma réponse est toujours la même :

Une ligne de code, je l’écrit une fois, mais je la lit des dizaines de fois. Et peut-être que d’autres personnes la liront à leur tour des dizaines de fois. La logique veut donc qu’on juge la qualité d’un code à sa lecture.

Cet article est le premier d’une série consacrée au refactoring. Je prendrais des exemples concrets, tirés (ou adaptés) d’applications réelles et je montrerais comment en améliorer la lisibilité. La série ne sera pas centrée uniquement sur le langage Ruby. Il pourra y avoir de temps à autre des exemples en Java, Python, Php, etc.

L’exemple d’aujourd’hui est une classe très simple, qui explore la ligne de commande pour trouver quelle commande l’utilisateur souhaite lancer. Il est tiré de yabu, un utilitaire de sauvegarde pour linux.
Voici la classe CommandParser telle qu’elle existait: