# Wednesday, March 18, 2009

Je HAIS les regions

Les regions sont incontestablement la fonctionnalité que je déteste et qui m’insupporte le plus dans Visual Studio. En voir dans du code, me fait enrager, grogner, avoir des boutons dans 98% des cas où je les rencontre.

Les regions permettent de définir différentes zones dans du code, zones qui peuvent être nommées et qui peuvent être rétractables. Le principal reproche que je trouve aux régions réside tout simplement dans le rôle même de cette fonction : MASQUER LE CODE.

Car après tout, les régions ont été créés dans un seul et unique but : masquer du code que le développeur ne doit pas voir ou modifier :

Cela avait donc une utilité avant que les classes partielles existent afin de masquer du code qui est généré et qui donc par définition ne doit pas être modifié (sous peine de voir les modifications supprimées lors de la prochaine génération de code) en le plaçant dans un autre fichier.

Vous l’avez compris, je ne comprends pas quel est l’intérêt de masquer du code. Lorsque je consulte des fichiers sources je souhaite avoir la meilleure lisibilité possible afin de comprendre le fonctionnement du code que je suis en train de lire. Le voir masqué m’oblige à utiliser mes dons de contorsionniste des doigts afin de déplier ces fameuses régions qui, pour certains développeurs, servent à “ranger” ou “classer” du code source de “manière plus propre”.  Dans la très majorité des cas, si vous avez besoin de “ranger” votre code source présent dans une classe en plus zone, c’est que votre classe fait beaucoup trop de choses que ce qu’elle devrait faire. Repenser la séparation des responsabilités permet de résoudre le problème. Si vous regroupez plusieurs méthodes et/ou propriétés dans une région particulière, il y a une forte probabilité que cet ensemble devrait se trouver dans une autre classe. Et si vous groupez des lignes de code d’une même méthode en plusieurs régions, cela signifie que votre méthode à trop de responsabilité et qu’il serait bon de la splitter en différentes méthodes distinctes.

Le seul avantage que je vois donc aux régions, et qu’il permet de voir du premier coup d’œil quel est le code qu’il est urgent de factoriser.

Wednesday, March 18, 2009 11:04:33 PM (GMT Standard Time, UTC+00:00)
Ctrl M L !
Wednesday, March 18, 2009 11:10:32 PM (GMT Standard Time, UTC+00:00)
Par "contorsionniste des doigts" s'entends "utilisation de raccourci clavier" ;)
Thursday, March 19, 2009 2:00:10 AM (GMT Standard Time, UTC+00:00)
Je suis pas d'accord avec toi. Bien utilisées, les régions ont tout leurs sens. Notamment celui que tu leurs donnes, l'organisation. Pour ma part je ne les utilises que pour séparer champs, constructeurs, propriétés puis méthodes. Celà permet de trouver rapidement un élément. Et celà n'empêche en rien de correctement "splitter" les responsabilités. Celà organise, "homogéneise" et rend la maintenance du code (par autrui) plus simple.

A+

Seb.
Sébastien MONTEIL
Thursday, March 19, 2009 7:22:07 AM (GMT Standard Time, UTC+00:00)
OK pour le classement par visibilité ou par type d'éléments (Propriétés, méthodes, champs), mais bizarrement je constate que les régions sont le plus souvent utilisés pour classer du code par responsabilités. Voir des régions nommées "Création connexion http", "Acces database", "appel wcf", ou ce genre de nom est à mon avis un non-sens.
Thursday, March 19, 2009 9:31:35 AM (GMT Standard Time, UTC+00:00)
Moi j'aime les régions !

J'utilise souvent pour Constructor,Properties,Fields ...

Je pense que tu ne vas pas aimer le fait de pouvoir cacher un if (ou autre) dans VS 2010 ! ;)
Thursday, March 19, 2009 12:07:18 PM (GMT Standard Time, UTC+00:00)
On est tout à fait d'accord. Je hais les régions aussi. Elles sont le plus souvent utilisées pour masquer de la complexité, ou pour séparer des comportements. Et même quand elles sont utilisées pour séparer «logiquement» les différents membres d'un type, elles empêchent d'avoir une vision globale du type.