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
Es interesante que es una nueva recomendación, explica la mayoría de winforms que no tienen el prefijo Is. –
@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 –
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. –