On tourne en rond, quelqu'un a déjà donné ce lien.
La réponse reste la même: ce genre d'infos devrait être encodé dans le type de la variable, pas dans son nom. Pour reprendre l'exemple du blog, il faudrait une classe UnsafeString, et les chaînes non sûres devraient être stockées dans des variables de ce type.
Après, on peut, au choix, mettre un operator= (ou un opérateur de cast, ou...) qui va faire la conversion de façon transparente (mais il faut bien réfléchir), ou ajouter la méthode .Encode() pour que ce soit explicite.
Et du coup, ce n'est plus au développeur de vérifier ce genre de choses: le compilateur va faire le job tout seul. Le mauvais code fonctionnera quand même dans le premier cas (on va juste perdre en performance avec des conversions inutiles de partout), et ne compilera même pas dans le second.
Par contre, et c'est ce dont on débat ici, il n'est pas question d'avoir un type différent pour une variable locale et un membre d'une classe. Donc, dans ce cas, avoir un préfixe peut faire sense (encore que, utiliser systématiquement this-> n'est pas forcément une mauvaise idée, quoi qu'un peu verbeuse).
[^] # Re: Pourquoi un tiret bas?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C✙✙ Le tiret bas (underscore) au début des variables membres ?. Évalué à 6. Dernière modification le 20 août 2018 à 16:36.
On tourne en rond, quelqu'un a déjà donné ce lien.
La réponse reste la même: ce genre d'infos devrait être encodé dans le type de la variable, pas dans son nom. Pour reprendre l'exemple du blog, il faudrait une classe UnsafeString, et les chaînes non sûres devraient être stockées dans des variables de ce type.
Après, on peut, au choix, mettre un operator= (ou un opérateur de cast, ou...) qui va faire la conversion de façon transparente (mais il faut bien réfléchir), ou ajouter la méthode .Encode() pour que ce soit explicite.
Et du coup, ce n'est plus au développeur de vérifier ce genre de choses: le compilateur va faire le job tout seul. Le mauvais code fonctionnera quand même dans le premier cas (on va juste perdre en performance avec des conversions inutiles de partout), et ne compilera même pas dans le second.
Par contre, et c'est ce dont on débat ici, il n'est pas question d'avoir un type différent pour une variable locale et un membre d'une classe. Donc, dans ce cas, avoir un préfixe peut faire sense (encore que, utiliser systématiquement this-> n'est pas forcément une mauvaise idée, quoi qu'un peu verbeuse).