Meilleure pratique pour la convention de nommage des contrôles d'interface utilisateur pour le référencement dans code-behind?

Question

Quelle est la meilleure pratique pour nommer les contrôles d'interface utilisateur (zones de texte, menus déroulants, etc.) sur les formulaires et les états afin qu'ils soient référencés dans les pages code-behind?

Je développe beaucoup de rapports et de formulaires dans mon bureau. J'ai plusieurs applications Web fournissant environ 80+ "live". rapports générés à partir de sources de données diverses et multiples (Access, SQL, Oracle). Ces rapports sont considérés comme "live". car ils acceptent les paramètres définis par l'utilisateur à partir d'un formulaire, puis interrogez la base de données pour générer un rapport basé sur les informations disponibles actuellement.

Le processus commence donc par obtenir les valeurs définies par l'utilisateur, en les transmettant à la requête de la base de données, en recevant le jeu de données et enfin en affectant le jeu de données au rapport. Dans certains cas, des champs supplémentaires affichés dans le rapport doivent être calculés à partir du jeu de données avant que le rapport puisse être généré. Cela nécessite de référencer les contrôles de sortie du rapport pour affecter la valeur calculée.

Bien que je ne me soucie pas vraiment d'utiliser des préfixes dans mon code pour les variables ou les champs membres, je les utilise pour identifier les contrôles de l'interface utilisateur. Par exemple, txtFirstName pour référencer le contrôle de rapport afin d'affecter les données du champ Prénom du jeu de données au contrôle d'affichage du rapport. Existe-t-il une meilleure pratique pour nommer / référencer les contrôles d’UI sur les formulaires et les rapports?

Answer 1

Le produit principal sur lequel je travaille au travail utilise les préfixes txt_ pnl_ etc. Cela fonctionne, bien que cela soit un peu pénible parfois de changer quelque chose qui ne fait que masquer / afficher les contrôles, par exemple, de tr, à un panneau, car vous devez le renommer.

Ce que j'ai commencé à faire dans les nouveaux projets, c'est de nommer mes contrôles d'interface utilisateur avec un préfixe ui. par exemple, uiName. Depuis que je suis fermement opposé à la notation anti-hongroise , et viser le code auto-documenté , ce code la convention fonctionne bien. En fait, il s’agit plutôt d’une notation réelle en hongrois (ui étant le préfixe signifiant contrôle de l’interface utilisateur).

Answer 2

J'utilise toujours la notation hongroise pour les contrôles, mais plus pour les variables.

btn Button
cbo ComboBox
chk CheckBox
clb CheckedListBox
grp GroupBox
iml ImageList
lbl Label
lnk Hyperlink
mnu Menu
pbr ProgressBar
pic Picture
pnl Panel
rtb RichTextBox
tmr Timer
tvw TreeView
txt TextBox

Answer 3

Pour les contrôles de l'interface graphique, je suffixe le nom de la variable avec le nom du contrôle:

• firstNameTextBox
• lastNameTextBox
• submitButton

Cela rend la relation évidente entre, par exemple, _firstName et firstNameTextBox.Text, et personne ne doit se rappeler quel est l'équivalent de la notation hongroise. Je choisirais toujours la clarté plutôt que la concision dans la dénomination des variables.

Answer 4

Vos réponses ici seront très subjectives. Différents goûts et contextes de programmation vous donneront des préférences différentes.

Peut-être que ce qui sera le plus important pour vous à long terme est la cohérence de tous vos projets. Ainsi, quel que soit l'auteur du code, vous pourrez le comprendre en le lisant.

Nous externalisons beaucoup, alors assurez-vous de communiquer nos conventions de dénomination à tous nos chefs de projet.

Voici quelques liens vers les conventions de dénomination:

http://www.irritatedvowel.net/Programming/Standards.aspx

http://msdn.microsoft.com/ en-us / library / xzf533w0 (VS.71) .aspx

http://www.visualize.uk.com/resources /asp-net-standards.asp

Answer 5

Je fais la même chose que vous. Lorsque vous avez des tonnes de contrôles, tout devient brouillon, donc je préfixe chaque nom avec les majuscules de la classe de contrôle.

Par exemple:

TextBox - > tbName

DataGrid - > dgName

Panneau - > pName

Ceci explique clairement comment gérer les nouveaux contrôles (c'est-à-dire comment dériver le préfixe)

Answer 6

J'ai toujours pensé que la seule véritable raison de ces préfixes était que vous puissiez avoir des éléments comme txtFirstName et lblFirstName sur le même formulaire / page. Étant donné que, dans la grande majorité des cas, je travaille en réalité uniquement avec le contrôle de champ proprement dit, je saute le préfixe pour cela et n'utilise que les préfixes des contrôles associés. Par exemple, lblMonth & amp; Mois, en sautant le préfixe cbo.

Cela évite la dactylographie et le type de contrôle que vous utilisez dans de tels formulaires sera généralement évident. Les contrôles plus complexes obtiendront le traitement de préfixe complet.

Answer 7

Préfixes à 2 caractères pour les composants d'interface utilisateur iOS que je préfère:

bt _ : UIButton
lb _ : UILabel
tx _ : UITextField
tv _ : UITextView
vw _ : UIView
im _ : UIImageView
sc _ : UIScrollView
tb _ : UITableView
cl _ : UICollectionView
st _ : UIStackView
pk _ : UIPickerView
pr _ : UIProgressView
ai _ : UIActivityIndicatorView
wb _ : UIWebView / WKWebView
mp _ : MKMapView
gr _ : UIGestureRecognizer
sw _ : UISwitch
sl _ : UISlider
sp _ : UIStepper
sg _ : UISegmentedControl
pg _ : UIPageControl
dp _ : UIDatePicker