Pregunta

¿Cuál sería la mejor manera más legible / escribir un cheque condicional múltiple tal como se muestra a continuación?

Dos posibilidades que se me ocurrió (esto es Java, pero el lenguaje realmente no importa aquí):

Opción 1:

   boolean c1 = passwordField.getPassword().length > 0;
   boolean c2 = !stationIDTextField.getText().trim().isEmpty();
   boolean c3 = !userNameTextField.getText().trim().isEmpty();

   if (c1 && c2 && c3) {
      okButton.setEnabled(true);
   }

Opción 2:

   if (passwordField.getPassword().length > 0 &&
         !stationIDTextField.getText().trim().isEmpty() &&
         !userNameTextField.getText().trim().isEmpty() {
      okButton.setEnabled(true);
   }

Lo que no me gusta de la opción 2 es que la línea envuelve y luego se convierte en una muesca dolor. Lo que no gusta de la opción 1 es que crea las variables de nada que exige examinar dos lugares.

Entonces, ¿qué te parece? Cualquier otro opciones?

¿Fue útil?

Solución

if (HasPassword() && HasStation() && HasUserName())
  okButton.setEnabled(true);


bool HasPassword() {
 return passwordField.getPassword().length > 0;
}

etc.

Otros consejos

Tenga en cuenta que la opción 1 no permite el comportamiento cortocircuitos. Es decir, se calcula el valor de todos los condicionales antes de evaluar el resultado de la primera.

Me modificar la opción 1, de modo que está utilizando nombres de variables que en realidad tienen un significado. Es decir, cambiar el nombre de "c2" a ser algo así como "stationIDIsEmpty" (y mover el NO en el condicional). De esa manera el condicional se puede leer sin tener que mirar hacia atrás y hacia adelante para cada variable.

Así que mi código, probablemente se vería como:

boolean enteredPassword = passwordField.getPassword().length > 0;
boolean stationIDIsEmpty = stationIDTextField.getText().trim().isEmpty();
boolean userNameIsEmpty = userNameTextField.getText().trim().isEmpty();

if (enteredPassword && !stationIDIsEmpty && !userNameIsEmpty) {
   okButton.setEnabled(true);
}

He votado por la respuesta de Chris Brandsma.

Pero sólo quería mencionar el principal problema que tengo con la opción 1 es que está perdiendo el beneficio de &&. Con la opción uno, aunque creo que es más fácil de leer, que está procesando comparaciones cuando puede no ser necesaria.

En lo personal, me gusta la segunda manera, porque me parece que el uso de esa manera puede hacer que la predicación de los condicionales clara. Es decir, con este método se hace correctamente, puede hacer que el condicional comprensible "verablizing" que (sea o no en realidad se habla es irrelevante).

Es decir, con su segunda opción, se hace evidente que su condición se traduce más o menos como esto: "Si la longitud de la contraseña es mayor que cero, y la stationIDTextField (recortado) no está vacío, y el usernameTextField (recortado) no es vacío, entonces ... "

Yo prefiero lo siguiente:

if (passwordField.getPassword().length > 0
    && ! stationIDTextField.getText().trim().isEmpty()
    && ! userNameTextField.getText().trim().isEmpty())
{
    okButton.setEnabled(true);
}

Con este estilo de codificación que lograr dos cosas:

  • I puede ver fácilmente que cada línea adicional de la si es parte de la condición debido a la && (o ||) en el beggining.
  • I puede ver fácilmente en la sentencia if termina debido a la {en la línea siguiente.

Opción 1 es primo para aplicar la refactorización ' Reemplazar temporal con la consulta '. La razón es que alguien puede meter en el código entre la variable se inicializa y el cheque y cambiar el comportamiento del código. O el cheque podría hacerse con los valores rancios .. una actualización se ha realizado para los campos de texto entre la inicialización y comprobación.

Así que mi intento de esto sería

if (GetPasswordLength() > 0 
   && FieldHelper.IsNotEmpty(stationIDTextField) 
   && FieldHelper.IsNotEmpty(userNameTextField) 
{
   okButton.setEnabled(true);
}

FieldHelper es una clase con métodos estáticos públicos (también llamadas a / clase estática clase de utilidad en C #)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top