Une question relativement mineure, mais je n'ai pas pu trouver de documentation officielle ni même d'opinion de blog / discussions à ce sujet.
En termes simples: quand j'ai un objet privé dont le seul but est de servir à des fins privées lock
, comment dois-je nommer cet objet?
class MyClass
{
private object LockingObject = new object();
void DoSomething()
{
lock(LockingObject)
{
//do something
}
}
}
Que devons-nous nommer LockingObject
ici? Tenez également compte non seulement du nom de la variable, mais aussi de son aspect dans le code lors du verrouillage.
J'ai vu divers exemples, mais apparemment aucun bon conseil:
Beaucoup d'utilisations de
SyncRoot
(et de variantes telles que_syncRoot
).- Exemple de code:
lock(SyncRoot)
,lock(_syncRoot)
- Cela semble être influencé par la
SyncLock
déclaration équivalente de VB , laSyncRoot
propriété qui existe sur certaines des classes ICollection et une partie d'une sorte de modèle de conception SyncRoot (ce qui est sans doute une mauvaise idée) - Étant dans un contexte C #, je ne sais pas si je voudrais avoir un nom VBish. Pire encore, en VB, nommer la variable de la même manière que le mot-clé. Je ne sais pas si cela serait une source de confusion ou non.
- Exemple de code:
thisLock
etlockThis
des articles MSDN: C # verrou Déclaration , VB SyncLock Déclaration- Exemple de code:
lock(thisLock)
,lock(lockThis)
- Je ne sais pas si ceux-ci ont été nommés de manière minimale uniquement pour l'exemple ou non
- Un peu bizarre si nous utilisons cela dans une
static
classe / méthode. - EDIT: l'article Wikipedia sur les serrures utilise également cette dénomination pour son exemple
- Exemple de code:
Plusieurs utilisations de
PadLock
(de boîtier variable)- Exemple de code:
lock(PadLock)
,lock(padlock)
- Pas mal, mais mon seul bœuf est qu'il invoque sans surprise l'image d'un "cadenas" physique que j'ai tendance à ne pas associer au concept de filetage abstrait .
- Exemple de code:
Nommer le verrou en fonction de ce qu'il a l'intention de verrouiller
- Exemple de code:
lock(messagesLock)
,lock(DictionaryLock)
,lock(commandQueueLock)
- Dans l'exemple de page VB SyncRoot MSDN, il contient un
simpleMessageList
exemple avec unmessagesLock
objet privé - Je ne pense pas que ce soit une bonne idée de nommer le verrou par rapport au type que vous verrouillez ("DictionaryLock") car c'est un détail d'implémentation qui peut changer. Je préfère nommer le concept / objet que vous verrouillez ("messagesLock" ou "commandQueueLock")
- Fait intéressant, je vois très rarement cette convention de dénomination pour verrouiller des objets dans des exemples de code en ligne ou sur StackOverflow.
- Exemple de code:
(EDIT) La spécification C # dans la section "8.12 The Lock Statement" a un exemple de ce modèle et le nomme
synchronizationObject
- Exemple de code:
lock(SynchronizationObject)
,lock(synchronizationObject)
- Exemple de code:
Question: Que pensez-vous généralement de la dénomination des objets de verrouillage privés ?
Récemment, j'ai commencé à les nommer ThreadLock
(donc un peu comme l'option 3), mais je me retrouve à remettre en question ce nom.
J'utilise fréquemment ce modèle de verrouillage (dans l'exemple de code fourni ci-dessus) dans mes applications, j'ai donc pensé qu'il pourrait être judicieux d'obtenir une opinion / discussion plus professionnelle sur une convention de dénomination solide pour eux. Merci!
SynchronizationContext
c'est quelque chose de très différent.