Nous avons mis en place de nouvelles normes de codage, qui demandent à nos membres privés d'avoir un soulignement de premier plan. Comme:
private System.Windows.Forms.Label _label1;
7 Réponses :
Cette réponse peut être insatisfaisante, mais c'est le mieux que je puisse offrir.
Je ne pense pas que vous puissiez obtenir le concepteur Visual Studio pour ajouter automatiquement le soulignement. Cependant, ce que vous pouvez faire est de faire le processus d'ajout du soulignement moins douloureux. Il suffit de créer vos objets sans le soulignement en premier; Ensuite, utilisez la fonction de refacteur pour les renommer. Il suffit de placer votre curseur sur le nom du champ ( Incidemment, j'utilise également F2 pour renommer la plupart des noms de gestionnaire d'événements générés automatiquement. Par exemple, je déteste voir des noms de méthodes tels que Label1 , dans votre cas) et appuyez sur F2 (ou cliquez avec le bouton droit de la souris ⇒ refacteur ⇒ Renommer). Cela fonctionne, peu importe où dans le code que vous êtes, tout ce dont vous avez besoin est une mention de Label1 . Comme vous écrirez probablement un code qui utilise vos contrôles, vous ferez probablement référence aux champs de toute façon. Vous pouvez également appuyer sur F12 pour obtenir directement les déclarations où vous obtenez efficacement une liste complète de tous vos contrôles; Vous pouvez facilement utiliser F2 pour renommer beaucoup d'entre eux là-bas en une fois.
btnzoomin_click () . Je préfère appeler la méthode zoomin () parce que c'est ce qu'il fait. Au lieu de Mainform_KeyPress () Je pourrais appeler IT ProcessKeyPress () .
Merci pour la réponse, Timwi, je suis au courant des capacités de refactorisation de vs. Changer le nom au moment de la conception est beaucoup plus rapide que de le faire à partir du code, je soupçonne qu'il est optimisé. Le faire à partir du code compile toutes vos assemblées, même pour des privés pour une raison quelconque. Je cherche quelque chose que je peux définir et oublier et ne nécessiterait pas de maintenance constante / travail humain.
Vous pouvez définir le générateur à faux.
Cela ne résout pas votre problème, mais évitez de nommer mal, lorsque vous ne travaillerez pas avec le contrôle manuellement.
Resharper peut appliquer des conventions de dénomination. Ensuite, il s'agit simplement d'ouvrir le fichier .Designer et de frapper Alt + Entrée, entrez quelques fois.
Personnellement, je pense que le code généré automatique doit être exclu à des directives de codage et ainsi de suite. Il est prudent de les ignorer dans la plupart des scénarios, à moins que le générateur ait un bug.
S'il vous plaît débattre avec quiconque a écrit que les directives de codage et lui posent-lui une option d'exclure le code généré.
Je suis d'accord. Si vous essayez d'apprivoiser un code généré automatiquement, vous n'obtiendrez jamais rien de productif. C'est peut-être "juste" le code de concepteur Winforms aujourd'hui, mais demain, vous devrez peut-être gérer les clients de WCF, la cartographie de l'entité de l'entité et peut-être même des monstres comme ce que génère l'AntLR. Lex a raison, le code généré automatiquement doit être exclu de ce type d'exigences.
Comme l'a dit Blueraja, vous pouvez utiliser Restomer. Vous pouvez ensuite utiliser son nettoyage de code (CTRL-E, C), mais cela ne fonctionne pas sur les fichiers générés, vous devrez donc le renommer temporairement. Je ne suis pas au travail, je ne peux donc pas vérifier s'il y a une option pour activer l'option pour les fichiers générés quelque part.
Notez que vous devrez régler cela à chaque fois que le fichier est régénéré.
Au-delà de la création de votre propre add-in vs montres pour le code généré et de la ré-nomme automatiquement, il n'y a aucun moyen d'accomplir ce que vous voulez.
Je sais que c'est une vieille question mais je travaille avec des concepteurs personnalisés ces derniers temps et j'ai une solution pour ce que vous voulez. Ajoutez cette classe à votre classe:
using System;
namespace WindowsFormsApplication1
{
public partial class Form1 : BaseForm
{
public Form1()
{
InitializeComponent();
}
}
}
Vous allez sûrement changer le nom de la valeur par défaut de toute façon ...
Ouais mais la façon dont nous l'avons, c'est censé être _labelcontactname, nous devons donc ajouter à la fin du nom. Aller au début pour ajouter le soulignement, sans une énorme affaire, semble être un gaspillage. De plus, les gens ne le font pas de manière cohérente et que je pense que cela améliorerait si la valeur par défaut avait un soulignement.
L'étiquette sera accès à partir du code. Je suppose qu'à ce stade, je défends la question sur des terrains de cohérence améliorés uniquement :).
L'outil pour faire respecter les coventions de codage est FXCOP et non le concepteur à mon avis. Vous pouvez également traiter l'avertissement comme des erreurs de faire avertir FXCOP d'échouer à la construction des développeurs de cas ne suivant pas les conventions.
Est-ce seulement pour les étiquettes ou pour tous les contrôles? Si seulement pour les étiquettes, je dirais que je ne finais souvent pas à leur accéder de mon code et autrement, si pour tous les contrôles, je pourrais très bien avoir un DateTimePicker pour le début de quelque chose, cela finirait-il d'être appelé _DateTimePickerstart? Si oui, semble un peu extrême avec seulement 25% du nom étant le nom réel.
D'accord, les normes ont été mises en œuvre contre mon meilleur jugement, je veux juste m'assurer que nous ne nageons pas contre le courant. Oui, cela concerne tous les contrôles, DateTimePickers inclus.
D'accord avec ikaso. Utilisez FXCop et Styecopopop ou convaincre votre entreprise de sortir de l'argent pour Resharper.
La joie des normes idiotes ... Je suis alors d'accord avec Ikaso que vous voudrez peut-être examiner les règles FXCOP.
Cela vous dérange-t-il d'avoir à ajouter un composant au formulaire pour activer les modifications de nom?
+1 pour de bonnes questions.Il pourrait être une bonne entrée d'amélioration pour VS