2010-09-01 15 views
6

A lo largo de Silverlight y WPF, propiedades que son valores booleanos llevan el prefijo Es (almost all), por ejemplo:IsEnabled or Enabled?

IsEnabled
IsTabStop
IsHitTestVisible

En todos los demás marcos de Microsoft (winforms, BCL, ASP.NET) No se usa. ¿Qué llevó a su equipo a alejarse de la convención de nomenclatura original? ¿Fue una evolución o un error de nomenclatura lo que tuvo que quedar?

Respuesta

13

Personalmente, siempre trato de prefijar los valores booleanos con algo que agrega un poco más de significado (es, tiene, puede, etc.). Mi costumbre viene de las siguientes directrices de Microsoft:

nombre Do propiedades booleanas con un frase afirmativa (canSeek en lugar de CantSeek). Opcionalmente, también puede prefijar las propiedades booleanas con Is, Can, o Has, pero solo donde agrega el valor .

MSDN - Names of Type Members

No creo que esto siempre fue el caso Esto no fue siempre el caso. Esas prácticas datan de .NET 2.0. Antes de eso, las cosas eran un juego justo. Limpiar esos nombres en versiones más recientes del Framework, sin embargo, causaría todo tipo de dolores de cabeza (por lo tanto, parte del código del Framework utiliza la convención y otros no).

Definitivamente hace las cosas más legibles. Incluso usando un ejemplo de tu pregunta. ¿Qué preferirías tener?

// ambiguous naming, could mean many things 
myTab.TabStop 

o

// definitely a true/false value 
myTab.IsTabStop 
+1

Es interesante que es una nueva recomendación, explica la mayoría de winforms que no tienen el prefijo Is. –

+1

@Chris S - Es difícil hacer las cosas bien la primera vez. Esta podría haber sido una de las lecciones aprendidas de .NET 1/1.1 –

+0

Para TabStop, "Is" agrega valor claro: el valor de la propiedad le dice si algo es una tabulación; el valor no es una tabulación en sí. Para habilitado, el valor agregado es más sutil. "Es" aquí se distingue entre si algo está habilitado y un "habilitado", sea lo que sea, quizás una copia habilitada del objeto. Otro valor agregado es que el objeto se parece más al inglés: myObject.IsEnabled. –

3

El prefijo Is puede dar una pista sobre el hecho de que la propiedad solo tiene un descriptor de acceso get y, como dijeron Thomas y Rachel, es un bool. Omita el prefijo si tiene la intención de implementar los accesos get y set y su tipo es distinto de bool.

+5

me acuerdo, sé que he puesto IsEnabled en algunos objetos antes. Probablemente sea porque es un valor booleano y no algo que pueda establecerse en ningún valor. – Rachel

+5

Tiendo a estar de acuerdo con esa explicación, pero muchas propiedades de lectura/escritura en WPF tienen este prefijo ...Creo que está más bien destinado a mostrar que la propiedad es un bool –

+0

@Thomas y Rachel; de hecho, eso es lo que quería decir, pero me las arreglé para escribir algo más :) – devnull

3

El prefijo Is es parte del marco de las directrices oficiales Microsoft Design (esto no quiere decir que todos los productos de EM se adhieren a ella ...).

Personalmente, me resulta útil, si se utiliza de forma coherente. Inmediatamente le dice que una Propiedad es un Booleano. Es posible utilizar o no, lo más importante es ser constante en ello ...

Thomas