variables - ¿Está usando "es" para nombrar malas prácticas booleanas?

naming

Question

¿Nombrar booleanos que comienzan con "es" mala práctica ahora? Mi gerente cree que "isAnything" está desactualizado y es una mala práctica. ¿Es esto cierto?

myManager.isLame ? correct() : incorrect();

Answer 1

Es una cuestión de estilo, y lo he visto a tu manera muchas veces (y lo hago yo mismo en muchos idiomas).

Answer 2

Estilísticamente, mi voto sería para hasValue o isNullOrEmpty. Sin embargo, el uso de accesos directos ingeniosos o declaraciones one-line if como esa es universalmente malo. Reduce drásticamente la legibilidad del código y en la mayoría de los idiomas no generará ninguna ganancia de rendimiento.

Answer 3

No usaría ninguna regla dura y rápida aquí. Aunque encuentro que un prefijo como "Es" es útil para identificar una propiedad booleana, hay muchos casos en los que "Es" no sería la mejor opción.

• Car.HasFlatTyre vs Car.IsFlatTyre
• Cars.AreAllRed vs Cars.IsAllRed
• etc ...

Las pautas de nombres de MSDN incluyen los siguientes consejos relevantes.

Nombre propiedades booleanas con una frase afirmativa (CanSeek en lugar de CantSeek). Opcionalmente, también puede prefijar las propiedades booleanas con Is, Can o Has, pero solo donde agregue valor.

Answer 4

Se usa con bastante frecuencia en muchos idiomas, pero no sé si se puede decir con certeza que es el método preferido.

Creo que la coherencia y que todos en un equipo determinado usen los mismos estándares / estilos es lo más importante a tener en cuenta.

Answer 5

sería mejor si crea una variable booleana con un nombre claro

boolean lame;

y hacer un método para verificar su valor

isLame(){
  return lame;
}

En general, es mejor enfoque invocar el método que el acceso directo a la variable.

Answer 6

isLame() es muy común, y considero que no es cojo. En Java, es parte de la especificación JavaBeans y, por lo tanto, es una práctica bastante instalada.