¿Nombra los controles en los formularios utilizando la misma convención que una variable privada?

Question

Por alguna razón nunca veo que se haga esto.¿Hay alguna razón por la que no?Por ejemplo, me gusta _blah para las variables privadas, y al menos en Windows Forms los controles son variables miembro privadas de forma predeterminada, pero no recuerdo haberlas visto nunca con ese nombre.En el caso de que esté creando/almacenando objetos de control en variables locales dentro de una función miembro, es especialmente útil tener alguna distinción visual.

Answer 1

Esto puede resultar contrario a la intuición para algunos, pero utilizamos la temida notación húngara para los elementos de la interfaz de usuario.

La lógica es simple:para cualquier objeto de datos determinado, puede tener dos o más controles asociados.Por ejemplo, tienes un control que indica una fecha de nacimiento en un cuadro de texto, tendrás:

• el cuadro de texto
• una etiqueta que indica que el cuadro de texto es para fechas de nacimiento
• un control de calendario que le permitirá seleccionar una fecha

Para eso, tendría lblBirthDate para la etiqueta, txtBirthDate para el cuadro de texto y calBirthDate para el control de calendario.

Sin embargo, me interesa saber cómo otros hacen esto.:)

Answer 2

Notación húngara o no, tengo más curiosidad si la gente antepone m_ o _ o lo que sea que usen para las variables miembro privadas estándar.

Answer 3

Personalmente prefijo objetos privados con _

Los controles de formulario siempre tienen como prefijo el tipo, el solo La razón por la que hago esto es por Intellisense.Con formularios grandes, resulta más fácil "obtener el valor de las etiquetas" simplemente escribiendo libra y seleccionándolo de la lista ^_^ También sigue el Lógica expresada por Jon Limjap..

Aunque esto se repite en las pautas de codificación .NET de Microsoft, échales un vistazo aquí.

Answer 4

Para mí, la gran victoria con la convención de nomenclatura de anteponer un guión bajo a los miembros privados tiene que ver con Intellisense.Dado que el guión bajo precede a cualquier letra del alfabeto, cuando hago Ctrl-espacio para abrir Intellisense, están todos mis _privateMembers, justo en la parte superior.

Los controles, sin embargo, son una historia diferente, en lo que respecta a los nombres.Creo que se supone que el alcance y anteponer algunas letras para indicar el tipo (txtMyGroovyTextbox, por ejemplo) tiene más sentido por la misma razón;Los controles están agrupados en Intellisense por tipo.

Pero en el trabajo, todo es VB y usamos mPrivateMember.Creo que la m podría significar módulo.

Answer 5

Pasé por VB y mantuve el prefijo de tipo de control para los controles.Mis miembros privados usan minúsculas camel (firstLetterLowercase) mientras que los miembros públicos usan Pascal/mayúsculas camel (FirstLetterUppercase).

Si hay demasiados identificadores/miembros/locales para tener un 90% de posibilidades de recordar/adivinar cómo se llama, probablemente sea necesaria más abstracción.

Nunca me he convencido de que un prefijo de tipo de almacenamiento sea útil y/o necesario.Sin embargo, tengo el fuerte hábito de seguir el estilo de cualquier código que esté usando.

Answer 6

No lo hago, pero aprecio tu lógica.Supongo que la razón por la que la mayoría de la gente no lo hace es que los guiones bajos se verían un poco feos en la ventana Propiedades en el momento del diseño.También ocuparía un carácter adicional de espacio horizontal, lo cual es escaso en una ventana acoplada como esa.

Answer 7

Notación húngara o no, tengo más curiosidad si las personas prependen M_ o _ o lo que sea que usen para las variables de miembros privados estándar.

Lucas,

Utilizo el prefijo _ para los objetos de mi biblioteca de clases.Utilizo la notación húngara exclusivamente para la interfaz de usuario, por el motivo que dije.

Answer 8

Nunca uso guiones bajos en los nombres de mis variables.Descubrí que cualquier cosa que no sean caracteres alfa (a veces alfanuméricos) es excesiva a menos que lo exija el idioma.

Answer 9

Estoy en el campo de mayúsculas/minúsculas ("título" es privado, "Título" es público), mezclado con la notación "húngara" para los componentes de la interfaz de usuario (tbTextbox, lblLabel, etc.), y estoy feliz de que no tengamos Desarrolladores visuales que no distinguen entre mayúsculas y minúsculas en el equipo :-)

No me gusta el guión bajo porque se ve un poco feo, pero debo admitir que tiene una ventaja (o una desventaja, según el punto):En el depurador, todas las variables privadas estarán en la parte superior debido a que _ está en la parte superior del alfabeto.Pero, de nuevo, prefiero que mi par privado/público esté juntos, porque eso permite una depuración más sencilla de la lógica getter/setter al ver las propiedades pública y privada una al lado de la otra.

Answer 10

Escribo el nombre de la columna de la base de datos que representan.

Answer 11

Utilizo m_ para variables miembro, pero cada vez me siento más tentado a usar lowerCamelCase como lo hago para parámetros de métodos y variables locales.El material público está en UpperCamelCase.

Esta parece ser una convención más o menos aceptada en toda la comunidad .NET.