2008-09-21 16 views
7

¿Cuál es la mejor práctica para nombrar controles de IU (cuadros de texto, menús desplegables, etc.) en formularios e informes para referencia en las páginas de código subyacente?¿Práctica recomendada para nombrar convenciones de controles de interfaz de usuario para hacer referencia en código subyacente?

Desarrollo una gran cantidad de informes y formularios en mi oficina. Tengo varias aplicaciones web que proporcionan más de 80 informes "en vivo" generados a partir de fuentes de datos múltiples y múltiples (Access, SQL, Oracle). Estos informes se consideran "en vivo" porque aceptan parámetros del conjunto de usuarios de un formulario, luego consultan la base de datos para generar un informe basado en la información actual disponible.

Por lo tanto, el proceso comienza con la obtención de los valores establecidos por el usuario, pasándolos a la consulta de la base de datos, recibiendo el conjunto de datos y finalmente asignando el conjunto de datos al informe. En algunos casos, los campos adicionales que se muestran en el informe deben calcularse a partir del conjunto de datos antes de que se pueda generar el informe. Esto requiere hacer referencia a los controles de salida en el informe para asignar el valor calculado.

Aunque realmente no me importa usar prefijos en mi código para variables o campos de miembros, los uso para identificar los controles de la interfaz de usuario. Por ejemplo, txtFirstName para hacer referencia al control de informe para asignar los datos del campo Nombre en el conjunto de datos al control de visualización en el informe. ¿Existe una mejor práctica para nombrar/referenciar controles de IU en formularios e informes?

Respuesta

7

El producto principal en el que trabajo en el trabajo utiliza los prefijos txt_ pnl_ etc. Esto funciona, aunque a veces es un poco molesto cuando se cambia algo que simplemente oculta/muestra controles de, digamos, un tr a un panel porque hay que cambiarle el nombre.

Lo que he comenzado a hacer en nuevos proyectos, es nombrar mis controles de interfaz de usuario con un prefijo ui; por ejemplo, uiName. Como me opongo firmemente al anti-hungarian notation, y me esfuerzo por self-documenting code, esta convención funciona bien.De hecho, en todo caso, es notación húngara real (siendo ui el prefijo que significa control de interfaz de usuario).

+0

Me gusta el uso de "ui" para anteponer el control, por ejemplo, está estandarizado y no es específico de la implementación. Normalmente, solo se produce una única encarnación del campo de datos en un formulario o informe (por ejemplo, un cuadro de texto que contiene el valor de un Nombre en la sección de detalles del informe es probable que ocurra una vez). –

3

Sus respuestas aquí serán muy subjetivas. Diferentes gustos y fondos de programación le darán diferentes preferencias.

Quizás lo que será más importante para usted en el largo plazo es la coherencia entre todos sus proyectos, de modo que independientemente de quién haya desarrollado el código, podrá comprenderlo al leer.

Externalizamos mucho, así que asegúrese de comunicar nuestras convenciones de nombres a todos nuestros gerentes de proyecto.

Éstos son algunos enlaces a las convenciones de nombres:

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

1

hago similar al suyo. Cuando tienes toneladas de controles, todo se vuelve complicado, así que prefijo cada nombre con las mayúsculas de la clase de control.

Por ejemplo:

TextBox -> tbName

DataGrid -> dgName

panel -> pName

Esto deja claro cómo manejar nuevos controles (es decir, cómo derivar la prefijo)

+0

¿Qué pasa cuando se tiene un Pictu re object - "pName" también? Una sola letra seguramente no puede capturar todo. Es por eso que prefiero un mínimo de 3 para diferenciar fácilmente. – Tor

+0

Me malinterpretas. Supongamos que hay un texbox para un correo electrónico, se llamaría "tbEmail", así que sí existe la posibilidad de superposiciones, pero es realmente mínimo. No se trata de utilizar la notación húngara, sino de diferenciar fácilmente entre say: tbEmail y lEmail (donde la segunda es una etiqueta asociada al cuadro de texto) – Sklivvz

0

Siempre he sentido que la única razón real para los prefijos era para poder tener cosas como txtFirstName y lblFirstName en el mismo formulario/página. Dado que, la gran mayoría de las veces, realmente solo estoy trabajando con el control de campo real, omito el prefijo para eso y solo uso los prefijos para los controles asociados. Por ejemplo, lblMonth & Month, omitiendo el prefijo cbo.

Se ahorra tipeo, y generalmente será obvio qué tipo de control está usando en dichos formularios. Los controles más complejos obtendrán el tratamiento de prefijo completo.

6

Todavía utilizo la notación húngara para los controles, pero ya no para las 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 
+0

Tenga en cuenta que esto es "sistema húngaro" (o "anti-húngaro"), no la verdadera notación húngara. El húngaro usa el tipo * funcional *, no el tipo * language *. Google para ambos términos y encontrarás la historia de por qué hay dos interpretaciones. – gregmac

7

Para los controles de la GUI, I sufijo del nombre de la variable con el nombre de control:

  • firstNameTextBox
  • lastNameTextBox
  • submitButton

Esto hace que la relación obvia entre, por ejemplo, _firstName y firstNameTextBox.Text, y nadie tiene que recordar lo que el húngaro no tación equivalente es. Siempre elegiría la claridad sobre la brevedad en el nombramiento de variables.

prefijos
0

2-char para los componentes de interfaz de usuario de iOS que prefieren:

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

Cuestiones relacionadas