Convention de nommage des contrôles dans une WinForm
8 réponses
ShadowFil
Bonjour,
Microsoft recommande de commencer par une minuscule tous les champs privés.
Mais si on a un champs privé "numeroTel" contenant la donné, et un control
TextBox "numeroTel2" permettant de récupérer le numéro de téléphone, comment
distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser pour
le contrôle ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
> Microsoft recommande de commencer par une minuscule tous les champs privés. Mais si on a un champs privé "numeroTel" contenant la donné, et un control TextBox "numeroTel2" permettant de récupérer le numéro de téléphone, comment distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser pour le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel. par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé. mais la, franchement...
> Microsoft recommande de commencer par une minuscule tous les champs
privés.
Mais si on a un champs privé "numeroTel" contenant la donné, et un control
TextBox "numeroTel2" permettant de récupérer le numéro de téléphone,
comment
distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser
pour
le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel.
par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé.
mais la, franchement...
> Microsoft recommande de commencer par une minuscule tous les champs privés. Mais si on a un champs privé "numeroTel" contenant la donné, et un control TextBox "numeroTel2" permettant de récupérer le numéro de téléphone, comment distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser pour le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel. par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé. mais la, franchement...
ShadowFil
Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir le mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
"Ambassadeur Kosh" a écrit :
> Microsoft recommande de commencer par une minuscule tous les champs > privés. > Mais si on a un champs privé "numeroTel" contenant la donné, et un control > TextBox "numeroTel2" permettant de récupérer le numéro de téléphone, > comment > distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser > pour > le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel. par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé. mais la, franchement...
Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir le
mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
"Ambassadeur Kosh" a écrit :
> Microsoft recommande de commencer par une minuscule tous les champs
> privés.
> Mais si on a un champs privé "numeroTel" contenant la donné, et un control
> TextBox "numeroTel2" permettant de récupérer le numéro de téléphone,
> comment
> distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser
> pour
> le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel.
par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé.
mais la, franchement...
Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir le mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
"Ambassadeur Kosh" a écrit :
> Microsoft recommande de commencer par une minuscule tous les champs > privés. > Mais si on a un champs privé "numeroTel" contenant la donné, et un control > TextBox "numeroTel2" permettant de récupérer le numéro de téléphone, > comment > distinguer les 2 sans utiliser la notation hongroise ? Quel nom utiliser > pour > le contrôle ?
ta TextBox devrait s'appeller textBoxNumeroTel. par défaut, quand tu poses une TextBox, quel nom a t'elle ? textBoxN...
la notation hongroise, elle est bien utile dans un langage non ou mal typé. mais la, franchement...
Ambassadeur Kosh
> Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir le mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
pige pas la... tu poses une TextBox qui s'appelle textBox1, tu vas la voir avec l'IS. tu la changes de nom en textBoxNumeroTel, tu verras textBoxNumeroTel dans IS. qu'est ce que tu veux dire ?
> Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir
le
mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
pige pas la... tu poses une TextBox qui s'appelle textBox1, tu vas la voir
avec l'IS. tu la changes de nom en textBoxNumeroTel, tu verras
textBoxNumeroTel dans IS.
qu'est ce que tu veux dire ?
> Par défaut, un textbox s'apelle "textBox1". Mais, on ne devrait pas voir le mot "textbox" dans le nom du champs, qui nous est donné par intellisense ?
pige pas la... tu poses une TextBox qui s'appelle textBox1, tu vas la voir avec l'IS. tu la changes de nom en textBoxNumeroTel, tu verras textBoxNumeroTel dans IS. qu'est ce que tu veux dire ?
Merlin
personnellement j'appelle les champs internes du même nom que les propriétés mais avec un underscore devant. Propriété Toto, champ _Toto. Comme ça la nuance est visible à l'oeil sans erreur, alors que la casse... Et pour les contrôles je les préfixe en bas de casse d'un truc très court car je ne vois pas l'intérêt d'une notation hongroise complexe et lourdingue. Par exemple une textbox pour le Nom, devient tbNom.
Pour tous les contrôles courants j'utilise des préfixes de 1 ou deux caractères maxi. tb pour les textbox, l pour label, etc. C'est très largement suffisant.
Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme tu l'expliques un champ Téléphone et un textbox Téléphone vu que la donnée est déjà dans le textbox.. Si jamais il y a des vérifs à faire, je préfère créer une méthode getTéléphone qui renverra le contenu du textbox après vérification / reformatage par exemple. Mais la donnée n'est pas stockée deux fois.
Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot (LeNomDeLaVariable) - Soit Camel, avec premier mot minuscule et le reste à la Pascal (leNomDeLaVariable, sqlConnection, ...)
Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y tenir sans mélanger les deux.
personnellement j'appelle les champs internes du même nom que les
propriétés mais avec un underscore devant. Propriété Toto, champ _Toto.
Comme ça la nuance est visible à l'oeil sans erreur, alors que la
casse...
Et pour les contrôles je les préfixe en bas de casse d'un truc très
court car je ne vois pas l'intérêt d'une notation hongroise complexe et
lourdingue.
Par exemple une textbox pour le Nom, devient tbNom.
Pour tous les contrôles courants j'utilise des préfixes de 1 ou deux
caractères maxi. tb pour les textbox, l pour label, etc. C'est très
largement suffisant.
Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme
tu l'expliques un champ Téléphone et un textbox Téléphone vu que la
donnée est déjà dans le textbox..
Si jamais il y a des vérifs à faire, je préfère créer une méthode
getTéléphone qui renverra le contenu du textbox après vérification /
reformatage par exemple. Mais la donnée n'est pas stockée deux fois.
Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot
(LeNomDeLaVariable)
- Soit Camel, avec premier mot minuscule et le reste à la Pascal
(leNomDeLaVariable, sqlConnection, ...)
Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y
tenir sans mélanger les deux.
personnellement j'appelle les champs internes du même nom que les propriétés mais avec un underscore devant. Propriété Toto, champ _Toto. Comme ça la nuance est visible à l'oeil sans erreur, alors que la casse... Et pour les contrôles je les préfixe en bas de casse d'un truc très court car je ne vois pas l'intérêt d'une notation hongroise complexe et lourdingue. Par exemple une textbox pour le Nom, devient tbNom.
Pour tous les contrôles courants j'utilise des préfixes de 1 ou deux caractères maxi. tb pour les textbox, l pour label, etc. C'est très largement suffisant.
Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme tu l'expliques un champ Téléphone et un textbox Téléphone vu que la donnée est déjà dans le textbox.. Si jamais il y a des vérifs à faire, je préfère créer une méthode getTéléphone qui renverra le contenu du textbox après vérification / reformatage par exemple. Mais la donnée n'est pas stockée deux fois.
Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot (LeNomDeLaVariable) - Soit Camel, avec premier mot minuscule et le reste à la Pascal (leNomDeLaVariable, sqlConnection, ...)
Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y tenir sans mélanger les deux.
> Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme tu l'expliques un champ Téléphone et un textbox Téléphone vu que la donnée est déjà dans le textbox..
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va savoir...
Si jamais il y a des vérifs à faire, je préfère créer une méthode getTéléphone qui renverra le contenu du textbox après vérification / reformatage par exemple. Mais la donnée n'est pas stockée deux fois. Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot (LeNomDeLaVariable) - Soit Camel, avec premier mot minuscule et le reste à la Pascal (leNomDeLaVariable, sqlConnection, ...) Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y tenir sans mélanger les deux.
euuh ben non, justement pas LeNomDeLaVariable. LeNomDeLaProprieté/Classe/Methode en revanche oui. lance fxcop, tu verras...
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris celui d'etre compris, parceque de plus en plus de gens utilisent cette convention, qui, qui plus, est pensée pour le langage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis ensemble, des classes utilisées, y'en a un paquet... bonjour la productivité.
> Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme tu
l'expliques un champ Téléphone et un textbox Téléphone vu que la donnée
est déjà dans le textbox..
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va
savoir...
Si jamais il y a des vérifs à faire, je préfère créer une méthode
getTéléphone qui renverra le contenu du textbox après vérification /
reformatage par exemple. Mais la donnée n'est pas stockée deux fois.
Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot
(LeNomDeLaVariable)
- Soit Camel, avec premier mot minuscule et le reste à la Pascal
(leNomDeLaVariable, sqlConnection, ...)
Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y
tenir sans mélanger les deux.
euuh ben non, justement pas LeNomDeLaVariable.
LeNomDeLaProprieté/Classe/Methode en revanche oui.
lance fxcop, tu verras...
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code
avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris
celui d'etre compris, parceque de plus en plus de gens utilisent cette
convention, qui, qui plus, est pensée pour le langage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir
qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel
nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis
ensemble, des classes utilisées, y'en a un paquet... bonjour la
productivité.
> Sur un autre plan je ne vois pas en revanche la nécessité d'avoir comme tu l'expliques un champ Téléphone et un textbox Téléphone vu que la donnée est déjà dans le textbox..
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va savoir...
Si jamais il y a des vérifs à faire, je préfère créer une méthode getTéléphone qui renverra le contenu du textbox après vérification / reformatage par exemple. Mais la donnée n'est pas stockée deux fois. Enfin rappelons que les conventions de nomage proposée par MS sont :
- Soit Pascal, avec des majuscules à chaque début de mot (LeNomDeLaVariable) - Soit Camel, avec premier mot minuscule et le reste à la Pascal (leNomDeLaVariable, sqlConnection, ...) Il est préférable d'opter pour l'un ou l'autre dans son code et de s'y tenir sans mélanger les deux.
euuh ben non, justement pas LeNomDeLaVariable. LeNomDeLaProprieté/Classe/Methode en revanche oui. lance fxcop, tu verras...
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris celui d'etre compris, parceque de plus en plus de gens utilisent cette convention, qui, qui plus, est pensée pour le langage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis ensemble, des classes utilisées, y'en a un paquet... bonjour la productivité.
Merlin
Ambassadeur Kosh a écrit :
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va savoir...
Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un truc de ce genre, donc sans conflit possible. Le double stockage d'une valeur est généralement toujours une mauvaise idée.
euuh ben non, justement pas LeNomDeLaVariable. LeNomDeLaProprieté/Classe/Methode en revanche oui. lance fxcop, tu verras...
Je suis pour les règles simples et génériques. Plus c'est simple plus on est sur de les appliquer correctement. Traiter les variables différemment me semble ne rien ajouter de vraiment utile. mais c'est mon avis perso. Peu importe en réalité, l'essentiel c'est de choisir une convention et de la respecter dans toute l'application. C'est surtout ça qui est essentiel.
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris celui d'etre compris, parceque de plus en plus de gens utilisent cette convention, qui, qui plus, est pensée pour le langage.
C'est un choix. Il a l'avantage d'assurer la cohérence dans tout ton code c'est donc bien. Maintenant les conventions, par essence, ne sont qu'arbritraires. On peut faire ce qu'on veut du moment qu'on tient la distance et qu'on ne change pas de règle à chaque méthode ou assemblage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis ensemble, des classes utilisées, y'en a un paquet... bonjour la productivité.
Y'a pas de dico, c'est très simple et cela ne concerne que les contrôles visuels. Je ne préfixe pas les classes, tu m'a mal compris.
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va
savoir...
Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un
truc de ce genre, donc sans conflit possible.
Le double stockage d'une valeur est généralement toujours une mauvaise
idée.
euuh ben non, justement pas LeNomDeLaVariable.
LeNomDeLaProprieté/Classe/Methode en revanche oui.
lance fxcop, tu verras...
Je suis pour les règles simples et génériques. Plus c'est simple plus
on est sur de les appliquer correctement. Traiter les variables
différemment me semble ne rien ajouter de vraiment utile. mais c'est
mon avis perso.
Peu importe en réalité, l'essentiel c'est de choisir une convention et
de la respecter dans toute l'application. C'est surtout ça qui est
essentiel.
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code
avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris
celui d'etre compris, parceque de plus en plus de gens utilisent cette
convention, qui, qui plus, est pensée pour le langage.
C'est un choix. Il a l'avantage d'assurer la cohérence dans tout ton
code c'est donc bien. Maintenant les conventions, par essence, ne sont
qu'arbritraires. On peut faire ce qu'on veut du moment qu'on tient la
distance et qu'on ne change pas de règle à chaque méthode ou
assemblage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir
qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel
nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis
ensemble, des classes utilisées, y'en a un paquet... bonjour la productivité.
Y'a pas de dico, c'est très simple et cela ne concerne que les
contrôles visuels. Je ne préfixe pas les classes, tu m'a mal compris.
il peut y en avoir une. la valeur precedente pour comparaison, ou autre, va savoir...
Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un truc de ce genre, donc sans conflit possible. Le double stockage d'une valeur est généralement toujours une mauvaise idée.
euuh ben non, justement pas LeNomDeLaVariable. LeNomDeLaProprieté/Classe/Methode en revanche oui. lance fxcop, tu verras...
Je suis pour les règles simples et génériques. Plus c'est simple plus on est sur de les appliquer correctement. Traiter les variables différemment me semble ne rien ajouter de vraiment utile. mais c'est mon avis perso. Peu importe en réalité, l'essentiel c'est de choisir une convention et de la respecter dans toute l'application. C'est surtout ça qui est essentiel.
bon maintenant, la cosmetique et les _, ce que j'en dis, je valide mon code avec fxcop depuis le commencement, et y'a enormement d'avantages, y compris celui d'etre compris, parceque de plus en plus de gens utilisent cette convention, qui, qui plus, est pensée pour le langage.
C'est un choix. Il a l'avantage d'assurer la cohérence dans tout ton code c'est donc bien. Maintenant les conventions, par essence, ne sont qu'arbritraires. On peut faire ce qu'on veut du moment qu'on tient la distance et qu'on ne change pas de règle à chaque méthode ou assemblage.
tu penses, en équipe, à ce que ça va donner tes abreviations ? il va falloir qu'à chaque fois qu'un gars tappe une variable, il cherche dans le dico quel nom lui donner, et le dico, il va pas etre petit, parceque tout le monde mis ensemble, des classes utilisées, y'en a un paquet... bonjour la productivité.
Y'a pas de dico, c'est très simple et cela ne concerne que les contrôles visuels. Je ne préfixe pas les classes, tu m'a mal compris.
> Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un truc de ce genre, donc sans conflit possible. Le double stockage d'une valeur est généralement toujours une mauvaise idée.
oui, j'ai pensé au old.
par contre, la tu fais de la regle sur du vent. qui te dit qu'il s'agit de stocker la meme chose ? on ne peut pas presumer du rôle de sa variable rien qu'avec son type et sa bonne tête. un commentaire serait judicieux...
Je suis pour les règles simples et génériques. Plus c'est simple plus on est sur de les appliquer correctement. Traiter les variables différemment me semble ne rien ajouter de vraiment utile. mais c'est mon avis perso. Peu importe en réalité, l'essentiel c'est de choisir une convention et de la respecter dans toute l'application. C'est surtout ça qui est essentiel.
bon,on va definir une convention ou on commence tous les identifiants par__ et ou on ecrit un _ une lettre sur deux :o) et ce qui se passe en général, c'est que tu n'as pas le choix. et que les choix qui ont été faits te demandent des efforts pour satisfaire l'ego d'un trouducul au detriment souvent de la qualité du code :o)
Maintenant les conventions, par essence, ne sont qu'arbritraires. On peut faire ce qu'on veut du moment qu'on tient la distance et qu'on ne change pas de règle à chaque méthode ou assemblage.
parole de sagesse.
Y'a pas de dico, c'est très simple et cela ne concerne que les contrôles visuels. Je ne préfixe pas les classes, tu m'a mal compris.
ok.
> Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un
truc de ce genre, donc sans conflit possible.
Le double stockage d'une valeur est généralement toujours une mauvaise
idée.
oui, j'ai pensé au old.
par contre, la tu fais de la regle sur du vent. qui te dit qu'il s'agit de
stocker la meme chose ? on ne peut pas presumer du rôle de sa variable rien
qu'avec son type et sa bonne tête. un commentaire serait judicieux...
Je suis pour les règles simples et génériques. Plus c'est simple plus on
est sur de les appliquer correctement. Traiter les variables différemment
me semble ne rien ajouter de vraiment utile. mais c'est mon avis perso.
Peu importe en réalité, l'essentiel c'est de choisir une convention et de
la respecter dans toute l'application. C'est surtout ça qui est essentiel.
bon,on va definir une convention ou on commence tous les identifiants par__
et ou on ecrit un _ une lettre sur deux :o)
et ce qui se passe en général, c'est que tu n'as pas le choix. et que les
choix qui ont été faits te demandent des efforts pour satisfaire l'ego d'un
trouducul au detriment souvent de la qualité du code :o)
Maintenant les conventions, par essence, ne sont qu'arbritraires. On peut
faire ce qu'on veut du moment qu'on tient la distance et qu'on ne change
pas de règle à chaque méthode ou assemblage.
parole de sagesse.
Y'a pas de dico, c'est très simple et cela ne concerne que les contrôles
visuels. Je ne préfixe pas les classes, tu m'a mal compris.
> Dans ce cas le nom est mauvais, il devrait être oldValueTéléphone ou un truc de ce genre, donc sans conflit possible. Le double stockage d'une valeur est généralement toujours une mauvaise idée.
oui, j'ai pensé au old.
par contre, la tu fais de la regle sur du vent. qui te dit qu'il s'agit de stocker la meme chose ? on ne peut pas presumer du rôle de sa variable rien qu'avec son type et sa bonne tête. un commentaire serait judicieux...
Je suis pour les règles simples et génériques. Plus c'est simple plus on est sur de les appliquer correctement. Traiter les variables différemment me semble ne rien ajouter de vraiment utile. mais c'est mon avis perso. Peu importe en réalité, l'essentiel c'est de choisir une convention et de la respecter dans toute l'application. C'est surtout ça qui est essentiel.
bon,on va definir une convention ou on commence tous les identifiants par__ et ou on ecrit un _ une lettre sur deux :o) et ce qui se passe en général, c'est que tu n'as pas le choix. et que les choix qui ont été faits te demandent des efforts pour satisfaire l'ego d'un trouducul au detriment souvent de la qualité du code :o)
Maintenant les conventions, par essence, ne sont qu'arbritraires. On peut faire ce qu'on veut du moment qu'on tient la distance et qu'on ne change pas de règle à chaque méthode ou assemblage.
parole de sagesse.
Y'a pas de dico, c'est très simple et cela ne concerne que les contrôles visuels. Je ne préfixe pas les classes, tu m'a mal compris.
ok.
Merlin
Ambassadeur Kosh a écrit :
oui, j'ai pensé au old.
ça ou autre chose, mais en fait il faut que le nom reflète la sémantique.. c'est la règle principale, avant les conventions de nomage.
qui te dit qu'il s'agit de stocker la meme chose ?
c'est une supposition vu que le nom est le même... comme quoi le nomage doit suivre la sémantique. C'est un bon exemple. Finalement si je devais maintenir son code, même nom, même utilité, voila ce que je me dirais en premier.
on ne peut pas presumer du rôle de sa variable rien qu'avec son type et sa bonne tête.
non mais avec son nom si...
un commentaire serait judicieux...
Un nom suivant la sémantique est toujours préférable à un commentaire qui ne peut pas apparaître à chaque ligne où l'identifiant est utilisé.
bon,on va definir une convention ou on commence tous les identifiants par__ et ou on ecrit un _ une lettre sur deux :o)
:-) Je ne sais pas si ça serait lisible, mais si c'est appliqué de façon cohérente ça serait déjà ça. Il y a tellement de softs où le code ne suit aucune règle...
ça ou autre chose, mais en fait il faut que le nom reflète la
sémantique.. c'est la règle principale, avant les conventions de
nomage.
qui te dit qu'il s'agit de
stocker la meme chose ?
c'est une supposition vu que le nom est le même... comme quoi le nomage
doit suivre la sémantique.
C'est un bon exemple. Finalement si je devais maintenir son code, même
nom, même utilité, voila ce que je me dirais en premier.
on ne peut pas presumer du rôle de sa variable rien
qu'avec son type et sa bonne tête.
non mais avec son nom si...
un commentaire serait judicieux...
Un nom suivant la sémantique est toujours préférable à un commentaire
qui ne peut pas apparaître à chaque ligne où l'identifiant est utilisé.
bon,on va definir une convention ou on commence tous les identifiants par__
et ou on ecrit un _ une lettre sur deux :o)
:-)
Je ne sais pas si ça serait lisible, mais si c'est appliqué de façon
cohérente ça serait déjà ça. Il y a tellement de softs où le code ne
suit aucune règle...
ça ou autre chose, mais en fait il faut que le nom reflète la sémantique.. c'est la règle principale, avant les conventions de nomage.
qui te dit qu'il s'agit de stocker la meme chose ?
c'est une supposition vu que le nom est le même... comme quoi le nomage doit suivre la sémantique. C'est un bon exemple. Finalement si je devais maintenir son code, même nom, même utilité, voila ce que je me dirais en premier.
on ne peut pas presumer du rôle de sa variable rien qu'avec son type et sa bonne tête.
non mais avec son nom si...
un commentaire serait judicieux...
Un nom suivant la sémantique est toujours préférable à un commentaire qui ne peut pas apparaître à chaque ligne où l'identifiant est utilisé.
bon,on va definir une convention ou on commence tous les identifiants par__ et ou on ecrit un _ une lettre sur deux :o)
:-) Je ne sais pas si ça serait lisible, mais si c'est appliqué de façon cohérente ça serait déjà ça. Il y a tellement de softs où le code ne suit aucune règle...
