Depuis C# est fortement typé, avons-nous vraiment besoin de préfixer les variables de plus?
par exemple
iUserAge
iCounter
strUsername
J'ai utilisé le préfixe dans le passé, mais à l'avenir je ne vois pas l'avantage.
Depuis C# est fortement typé, avons-nous vraiment besoin de préfixer les variables de plus?
par exemple
iUserAge
iCounter
strUsername
J'ai utilisé le préfixe dans le passé, mais à l'avenir je ne vois pas l'avantage.
Sont variables préfixes ( hongrois ) vraiment plus nécessaire?
NON!
En fait, Microsoft propres lignes directrices de style (où la pratique est originaire) recommandent maintenant contre elle. En particulier, voir la section Générale des Conventions de Nommage, qui comprend le texte suivant (en gras, pas moins):
N'utilisez pas de la notation hongroise.
Le seul endroit où je vois apte à se plier aux normes et préfixe variables:
nom: txtWhatever
- et je vois que je ne suis pas le seul. La bonne chose est que vous pouvez venir avec des trucs comme lblName à côté de txtName, et vous n'avez pas besoin d'aller dans le NameLabel/NameTextBox direction.
membre de la classe des variables: _whatever
. J'ai essayé les deux m_ et pas de préfixe à tous et a terminé avec un simple trait de soulignement. m_ est plus difficile pour le type et l'absence de préfixe devient confus parfois (en particulier lors de l'entretien, je sais que vous le savez tous leur code par cœur, tandis que de l'écrire)
Je n'ai pas trouvé cohérente de la situation où la préfixation d'une variable avec son type permettrait de rendre le code plus lisible, si.
EDIT: j'ai lu les lignes directrices de Microsoft. Cependant je considère que le codage styles sont autorisés à évoluer et/ou être "plié", le cas échéant. Comme je l'ai mentionné ci-dessus, j'ai trouvé à l'aide de souligner préfixe utile par essai et erreur, et c'est certainement mieux que l'utilisation de ce.quelle que soit partout dans le code.
Soutenir "l'évolution" de la théorie - la de nouveau .NET 1.x lorsque Microsoft a publié des directives de codage, ils ont conseillé à l'aide de Chameau boîtier pour tout, même pour les constantes. Je vois maintenant qu'ils ont changé et conseiller à l'aide de Pascal cas pour constant ou public readonly champs.
En outre, même .NET Framework bibliothèque de classe est actuellement pleine de m_ et _ et s_ (essayez de naviguer à la mise en œuvre avec le Réflecteur). Alors, après tout, c'est le développeur, aussi longtemps que la cohérence est préservé à l'ensemble de votre projet.
Si hongrois signifie "préfixe avec un type abréviation" comme uCount ou pchzName, alors je dirais que cette pratique est mauvaise et, heureusement, semble s'estomper à partir de l'usage commun.
Cependant, je ne pense toujours que les préfixes sont très utiles pour la portée. À mon studio, nous utilisons la présente convention pour préfixer les variables :
i_ // input-only function parameter (most are these)
o_ // output-only function parameter (so a non-const & or * type)
io_ // bidirectional func param
_ // private member var (c#)
m_ // private member var (c++)
s_ // static member var (c++)
g_ // global (rare, typically a singleton accessor macro)
J'ai trouvé cela très utile. La touche func param préfixes, en particulier, sont utiles. Chemin vers le bas à l'intérieur d'une fonction, vous pouvez toujours dire où var est venu d'un coup d'œil. Et généralement, nous allons copier le var à un autre lorsque l'on veut modifier ou d'en changer le sens.
Donc en bref: les préfixes pour les types sont inutiles avec des outils modernes. L'IDE prend en charge l'identification et la vérification de ce genre de choses pour vous. Mais le champ d'application basée sur les préfixes sont très utiles pour des raisons de lisibilité et de clarté.
Il y a aussi le côté amusant des avantages comme avec Intellisense. Vous pouvez taper i_ ctrl-espace et d'obtenir tous les paramètres de la touche func pour choisir de. Ou g_ ctrl-espace pour obtenir tous les singletons de votre. C'est un gain de temps.
Nope. Nous n'avons jamais besoin?
La notation hongroise est laid. La seule exception est avec les interfaces, où la plupart des gens pensent que c'est acceptable.
Linus résume très bien: "Codant pour le type d'une fonction dans le nom de la (soi-disant notation hongroise) est le cerveau endommagé - le compilateur sait les types de toute façon et peut vérifier ceux-ci, et il ne confond le programmeur"
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.