practices - ¿Cuáles son las pautas de nombres para los controles ASP.NET?

framework design guidelines

Question

Estamos en proceso de descifrar las pautas de diseño que nos gustaría utilizar en nuestro equipo de desarrollo y comenzamos un debate hoy sobre cómo deben nombrarse los controles ASP.NET. Estoy hablando de nuestros buenos amigos Label, TextBox, Button, etc.

Se nos ocurrieron las tres posibilidades siguientes que votamos: (Ejemplo es un TextBox para ingresar / mostrar un Nombre)

1. Agregue el tipo de control como un postfijo a su ID de controles: [FirstName _ TextBox] o [FirstName _ tbx]
2. Agregue el tipo de control como un prefijo a su ID de controles [tbxFirstName]
3. Establezca la ID del control en FirstName y nombre los campos relacionados (como una etiqueta para el cuadro de texto o un validador) como en la opción 2 [lblTextBox].

Terminamos decidiendo usar la opción 2. No es tan detallada como la opción 1 y me gusta que especifique qué control es antes del nombre del control.

Mi pregunta es si Microsoft ha publicado alguna guía para estos prefijos y si tiene algún comentario sobre nuestra decisión.

Answer 1

Casi todos usan prefijos de estilo húngaro (opción 2). La denominación semántica es menos útil porque "Firstname" es realmente el valor texbox.Text, no el cuadro de texto en sí.

Answer 2

Creo que la mayoría de las veces me importa qué tipo de información es el control en lugar de qué tipo de control se está utilizando actualmente para capturar esos datos, por lo que prefiero el tipo de información antes del tipo de control, así que puedo encontrarlo en una lista ordenada en el IDE:

• AgeRangeDropDownList
• AgreedToTermsCheckBox
• FirstNameTextBox
• LastNameTextBox

VS:

• chkAgreedToTerms
• ddlAgeRange
• txtFirstName
• txtLastName

Answer 3

Dos razones por las que prefiero la opción 1:

1. FirstNameTextBox se acerca más a mi objeto de negocio.
2. Más usable con IntelliSense.

Habiendo dicho eso, estoy considerando cambiar a FirstNameCtrl por la razón que csgero señaló sobre el cambio de los tipos de control. Entonces, ¿por qué molestarse con cualquier postfijo o prefijo, para reducir / eliminar la posibilidad de conflictos con las propiedades de formulario asp / win?

Answer 4

He estado luchando con este problema también. Solía ​​usar el "prefijo de estilo húngaro".

Ahora que tomo un enfoque diferente, trato de ver los controles como campos privados de mi clase. No prefiero postfix mis campos privados con su tipo, entonces, ¿por qué debería hacer eso en un TextBox?

Entonces, ¿qué solía ser?

var newCustomer = new Customer();
newCustomer.Name = txtName.Value;
newCustomer.Address = txtAddress.Value;
newCustomer.City = txtCity.Value;
newCustomer.HasEnoughMoney = cbHasMoney.Selected;

Se convierte en:

var newCustomer = new Customer();
newCustomer.Name = name.Value;
newCustomer.Address = address.Value;
newCustomer.City = city.Value;
newCustomer.HasEnoughMoney = hasMoney.Selected;

Para ser honesto, no me importa si el control de "nombre" es un cuadro de texto o qué más, solo quiero que sea valioso.

Y si no es lo suficientemente claro si habla de su control o de otro campo / variable, creo que debería reconsiderar el nombre de ese campo / variable o la función de su clase (lo que significa que podría ser un poco demasiado grande). .

Answer 5

Microsoft proporciona algunas orientaciones aquí.

Cuando arrastra un control a un formulario web, obtiene algo como "TextBox1" automáticamente. Ese es el IDE que le dice que debe cambiar la parte "1" para sus necesidades específicas.

En ese caso, "TextBoxFirstName" parece ser el camino a seguir.

Answer 6

No creo que haya una respuesta correcta o incorrecta aquí, lo que sea que decidas, creo que el aspecto más importante es solo ser consistente cuando se trata de codificación.

Answer 7

No estoy muy seguro acerca de las pautas, sospecho que las hay, ¡pero siempre uso el número 2 también!

Answer 8

No estoy seguro de las pautas con respecto a ASP.NET, pero en el libro Framework Design Guidelines de Microsoft, hay varias pautas de mejores prácticas para nombrar a los miembros de la clase. Como los controles ASP.NET en la mayoría de los casos dan como resultado un campo protegido del tipo apropiado, considero que estas pautas de nombres también se aplican a los controles ASP.NET. De hecho, el Análisis de código no se diferencia en los campos de referencia de Control y otros campos.

Estas directrices recomiendan utilizar un esquema de nombres que implica el uso lógico en lugar de una variante descriptiva de tipo. Hay varias razones para esto. El prefijo implica un tipo para el desarrollador que podría no ser correcto debido a cambios posteriores. Agrega un paso adicional en el mantenimiento del código. Si cambia su control Button en un control LinkButton, el nombre también debe modificarse para corregir el prefijo.

Por esa razón, llamaría al control FirstNameEdit, etc ...

Answer 9

Si lo miras desde el punto de vista del mantenimiento del código, cuál sería la mejor notación que hayas visto después de que hicieras el código hace 2 años. Aunque intentamos asegurarnos de que los formularios no tengan demasiados campos, todos sabemos que esto sucede a veces. Si usamos la notación de tipo húngara anteponiendo el tipo de control, creo que sería más fácil ver de dónde viene ese valor en lugar de tener que averiguarlo en caso de que el nombre de la variable no lo haga obvio. Si está utilizando cualquier tipo de herramienta de Refactorización, cambiar el nombre del control cambiaría el código automáticamente, reduciendo así el argumento de control de cambio.

Answer 10

También usamos el número 2, sin embargo, no estoy totalmente convencido de que sea un buen enfoque. Es la notación húngara del tipo "malo", lo que significa que los prefijos señalan el tipo (sintaxis) y no el propósito (semántica). El problema con esto es que lo que comienza como un TextBox puede convertirse más adelante en DropDown y luego en RadioButtonGroup, y tendrá que cambiar el nombre del control cada vez.

Answer 11

Tiendo a usar el tipo de control como prefijo y el nombre del control después, pero siempre uso CamelCase, así que en tu ejemplo puedes tener diferentes tipos de controles.

• TxbFirstName
• DdFirstName
• ChbFirstName

Por razones de inteligencia, también siempre califico completamente el nombre del control, así que no haría ninguno de los siguientes ...

• TxbFName
• TxbClientNo
• TxbNoOfCpn

Pero en última instancia, a las preferencias personales

Answer 12

estos simplemente se basan en sus preferencias, pero sí, la opción 2 tal como se describe es menos detallada e indica el tipo de control incluso antes de que se muestre su nombre.

Answer 13

El motivo por el que Visual Studio agrega "TextBox1" cuando lo agrega a la página es porque Microsoft no tiene forma de saber cómo piensa utilizarlo. Nombrarlo como "Control1" sería demasiado confuso porque podría tratarse de cualquier cantidad de controles.

Microsoft proporciona una guía en general para las convenciones de nomenclatura OO, pero no específicamente para nombrar controles UI. Como los controles de UI son, en última instancia, variables utilizadas en el código, deben seguir la misma convención que cualquier otra variable, sin prefijo de notación húngaro.

• msdn.microsoft.com/en-us/library/xzf533w0(vs.71)
• msdn.microsoft.com/en-us/library/ms229002(VS.80)

Las principales razones son ...

• El tipo de control puede cambiar de un cuadro de texto a un cuadro de lista, luego todo el código asociado deberá ser reparado (se indicó anteriormente)
• Su código debería estar más relacionado con el contenido del control y menos con qué tipo de control es. Cuando le preocupa el tipo de control, comienza a depender de ciertas funcionalidades y rompe la encapsulación: debería poder intercambiar controles fácilmente sin cambiar mucho o ningún código. (Principio básico de POO)
• Es bastante fácil encontrar prefijos para los controles estándar, pero se están desarrollando controles nuevos todos los días. Puede hacer su propio WebUserControl, o puede comprar un conjunto de controles de terceros. ¿Cómo va a decidir qué prefijo usar para los controles personalizados? En lugar de enfocarse en el tipo de control, su código debería preocuparse por la información contenida en él.

Ejemplos

• txtFirstName => firstName o FirstName
• txtState => estado o estado
• cboState => estado o estado (ejemplo principal de cambio de tipos de control qué pasa con lstState o rdoState - todos deben tener el mismo nombre porque a su código no le preocupa el tipo de control, sino el estado que seleccionó el usuario)
• ctlBilling => billingAddress o BillingAddress (control personalizado - con notación húngara no es muy evidente lo que es el control, pero con un nombre significativo empiezo a entender la información contenida en él, es decir, billingAddress.Street, billingAddress.FullAddress, etc.)

Answer 14

Creo que es mejor usar la opción 1 porque es fácil encontrar el campo por su significado y su uso para comprender la codificación de programación en el futuro. Además, es más útil con IntelliSense encontrar el lugar donde usamos este campo en nuestro código de programación. Por lo tanto, puedo encontrar el control correcto por el nombre del campo significativo. No recordaré qué tipo de control utilizo para este campo, pero puedo encontrar este campo usando el nombre de campo significativo en lugar del tipo de control. Quiero encontrar el control "Ciudad", simplemente escribo "Ciudad", Intellisence me mostrará toda la información para este control, pero si no recuerdo qué tipo de control utilizo, no sé por dónde empezar ...

Answer 15

Uso uxCity para que sepas que es definitivamente el control de la interfaz de usuario y no otro objeto, pero no necesitas cambiarlo si pasas de un TextBox a un DropDownList.

Sin embargo, si tuviera una DropdownList y un Textbox, necesitaría usar dlCity y txtCity O usaría un combo cboCity.

La notación húngara era de rigor cuando se limitaba a nombres de 8 caracteres y sin subrayado intellisense o depuración. Era una disciplina y se podía ver que si el estilo de codificación era correcto, era probable que el código fuera correcto. También se usó en variables para que pudiera leer el código y entenderlo, ya que era una aplicación de tipo DIY.

Sin embargo, uso CityTextbox, CityTextboxLabel CityUx, CityUxLbl

Todo depende de quién establece los estándares en el proyecto.

Answer 16

Abbreviation || ASP.NET Control

CONTROLES ESTÁNDAR:

botón btn

cb CheckBox

cbl CheckBoxList

ddl DropDownList

fu FileUpload

hdn HiddenField

lnk Hipervínculo

img Imagen

ibtn (btn) ImageButton

Etiqueta lbl

lbtn (btn) LinkButton

lb ListBox

iluminado Literal

mv MultiView

Panel pnl

ph PlaceHolder

rb RadioButton

rbl RadioButtonList

Tabla tbl

txt TextBox

v Ver

CONTROLES DE DATOS

dtl DataList

dp DataPager

dtv DetailsView

ets EntityDataSource

fv FormView

gv GridView

lds LinqDataSource

lv - ListView

ods ObjectDataSource

qe QueryExtender

repetidor rpt

smd SiteMapDataSource

sds SqlDataSource

xds XmlDataSource

CONTROLES DE VALIDACIÓN

cpv CompareValidator

ctv CustomValidator

rv RangeValidator

rev RegularExpressionValidator

rfv RequiredFieldValidator

vs ValidaciónSummary

CONTROLES DE VALIDACIÓN:

cpv // CompareValidator

ctv CustomValidator

rv RangeValidator

rev RegularExpressionValidator

rfv RequiredFieldValidator

Answer 17

No estoy seguro acerca de los estándares oficiales de Microsoft, pero esto es lo que he hecho a lo largo de mi carrera de desarrollo.

Generalmente abreviaré el tipo de control frente al nombre de lo que hace el control. Guardo la abreviatura en minúsculas y el nombre del control CamelCase.

Por ejemplo, un texbox para nombre de usuario se convierte en tbUserName

Aquí hay una lista de abreviaciones estándar que uso:

Abbr - Control
btn - Button
cb - CheckBox
cbl - CheckBoxList
dd - DropDownList
gv - GridView
hl - Hyperlink
img - Image
ib - ImageButton
lbl - Label
lbtn - LinkButton
lb - ListBox
lit - Literal
pnl - Panel
ph - PlaceHolder
rb - RadioButton
rbl - RadioButtonList
txt - Textbox

Answer 18

Encontré que la única razón para usar la notación húngara era que el IDE no tenía intellisense y no era fácil averiguar qué era qué, así que iCounter era un número entero

Sin embargo, el tiempo de uso del brief para desarrollar ha desaparecido y el IDE te muestra la información en un segundo

Luego, hereda el código VB.NET y no distingue entre mayúsculas y minúsculas, entonces, ¿qué hace?

lblFirstName, txtFirstName Uno es una etiqueta, el otro es el cuadro de texto

Entonces, ¿cómo los nombras sin sensibilidad a las mayúsculas y realmente sabes lo que son?

uxFirstName & uxFirstName no funciona

la única respuesta que he encontrado es utilizar la notación húngara, sí, vomité en mi boca. Por otra parte, es vb.net y debe ser sensible a mayúsculas y minúsculas, ya que .net es y todas las compilaciones a IL.