Méthodes de dénomination enregistrées dans les événements

Supposons que j’ai une classe qui expose l’événement suivant:

public event EventHandler Closing

Comment les méthodes enregistrées pour cet événement doivent-elles être nommées? Préférez-vous suivre la convention utilisée par Visual Studio lorsqu’il atsortingbue des noms aux méthodes générées (aka. + =, Tab, Tab)? Par exemple:

 private void TheClass_Closing( object sender, EventArgs e )

Ou utilisez-vous votre propre style pour nommer ces méthodes?

J’ai essayé différentes manières de nommer ces méthodes (comme TheClassClosing , HandleClosing , etc.). Mais je n’ai pas trouvé de bon style pour indiquer que le but d’une méthode est de gérer un événement enregistré. Personnellement, je n’aime pas le style (trait de soulignement) utilisé par Visual Studio pour générer des noms de méthodes.

Je sais que les méthodes de gestion d’événements enregistrées sont toujours privées et qu’il n’existe pas de convention de dénomination similaire à celle utilisée pour les méthodes qui OnClosing événements (par exemple, OnClosing ).

Les deux options courantes pour nommer sont soit ce que la méthode fait:

 theObject.Closing += SaveResults;

Ou bien après ce que la méthode gère:

 theObject.Closing += ClosingHandler;

Ce qui est préférable dépend vraiment du contexte.

Dans le premier cas, ce que le gestionnaire va faire est immédiatement clair, ce qui rend le code qui enregistre le gestionnaire plus lisible … mais en regardant le gestionnaire SaveResults isolément, il ne sera pas nécessairement évident de le voir quand il le sera. appelé, sauf si les arguments d’événement ont un nom évident ( ClosingEventArgs ou autre).

Dans le second cas, l’enregistrement est plus opaque (d’accord, que va-t-il se passer lorsque la Closing aura lieu?), Mais d’un autre côté, si vous regardez l’implémentation du gestionnaire, vous verrez clairement ce qui se passe.

Je suppose que celui à choisir dépend de laquelle des deux vous voulez être plus évident; le site de l’enregistrement, ou l’implémentation du gestionnaire.

Ou bien, vous pouvez opter pour la combinaison impie des deux méthodes:

 theObject.Closing += ClosingHandlerSaveResults;

Maintenant, le site d’enregistrement et la mise en œuvre sont tout aussi évidents, et aucun ne semble particulièrement élégant (en plus, cela viole probablement le principe de DRY).

Pour l’information, je préfère le premier schéma de nommage lorsque l’ theObject est contenu dans une scope différente de celle de l’implémentation de SaveResults , et le second schéma lorsque je connecte des gestionnaires à des événements qui sont tous contenus dans la même classe.

Nommez-le après ce que fait le gestionnaire.

 // event += event handler saveButton.Click += SaveData(); startButton.Click += StartTheTimer();

Je nomme mes gestionnaires d’événements de la même manière que ceux créés par Visual Studio (le +, =, onglet, onglet mentionné). J’essaie de garder la cohérence de mon nom dans mon code et je sais que je créerai des gestionnaires avec le créateur automatique de VS au moins de temps en temps.

Les soulignés ne me dérangent pas.

peut-être: OnObjectNameEventName, tel que

 private void OnTheClassClosing(object sender, EventArgs e)

Cela correspond aux méthodes d’événement internes, et avec l’ajout du nom de l’object, cela devrait aider à différencier. En outre, la méthode pour déclencher des événements est essentiellement un gestionnaire d’événement interne.

L’utilisateur clique sur le formulaire, appelle le formulaire OnClicked, fait son travail, puis déclenche l’événement Clicked, cela ne serait naturel que de mon sharepoint vue.