Pregunta

Considere esta línea:

if (object.getAttribute("someAttr").equals("true")) { // ....

Es evidente que esta línea es un error potencial, el atributo podría ser null y vamos a conseguir un NullPointerException. Así que tenemos que refactorizar a una de dos opciones:

Primera opción:

if ("true".equals(object.getAttribute("someAttr"))) { // ....

Segunda opción:

String attr = object.getAttribute("someAttr");
if (attr != null) {
    if (attr.equals("true")) { // ....

La primera opción es difícil de leer, pero más concisa, mientras que el segundo es clara en su intención, pero detallado.

¿Qué opción prefiere en términos de facilidad de lectura?

¿Fue útil?

Solución

Siempre he usado

if ("true".equals(object.getAttribute("someAttr"))) { // ....

porque aunque es un poco más difícil de leer es mucho menos detallado y yo creo que es lo suficientemente legible para que se acostumbre a ella muy fácilmente

Otros consejos

En la segunda opción, se puede tomar ventaja de && cortocircuitos:

String attr = object.getAttribute("someAttr");
if (attr != null && attr.equals("true")) { // ....

Hay ciertas situaciones en las que el enfoque concisa siente mal para empezar, pero con eficacia se convierte idiomática. Este es uno de ellos; el otro es algo como:

String line;
while ((line = bufferedReader.readLine()) != null) {
  // Use line
}

Los efectos secundarios en una condición? ¡Inconcebible! Excepto que es básicamente mejor que las alternativas, cuando se reconoce el patrón particular.

Este patrón es similar - es tan común en Java que yo esperaría razonablemente que cualquier desarrollador con experiencia para reconocerlo. El resultado es una grata concisa. (Sorprendentemente, a veces veo el código C # que utiliza el mismo idioma, innecesariamente -. El operador de igualdad funciona bien con cadenas en C #)

En pocas palabras: usar la primera versión, y familiarizarse con ella

.

Me gusta la opción 1 y yo diría que es lo suficientemente legible.

Opción 3 por cierto sería introducir un método getAttribute que toma un valor predeterminado como un parámetro.

Siempre aspiran para el código más corto, dado que ambos son funcionalmente equivalentes. Especialmente en el caso como éste, donde no se sacrifica la legibilidad.

- Util.isEmpty(string) vuelve string == null || string.trim().isEmpty() vuelve Util.notNull(string) "" si string == null, cadena de otra manera. Util.isNotEmpty(string) vuelve! Util.isEmpty(string)

Y tenemos una convención que para cuerdas, Util.isEmpty(string) significa semánticamente verdadera y Util.isNotEmpty(string) semánticamente significa falso.

Es una muy buena pregunta. Yo suelo usar el agraciado no:

if (object.getAttribute("someAttr") != null && object.getAttribute("someAttr").equals("true")) { // ....

(y no voy a usarlo nunca más)

tengo otra respuesta;

List<Map<String, Object>> group = jjDatabase.separateRow(db.Select("SELECT * FROM access_user_group  WHERE user_id=1 ;"));

no hay "group_c80" como columna en 'access_user_group' en mi base de datos, por lo que en get (0) .get ( "group_c80") acuerdos excepción de puntero nulo. Pero lo manejé a través de código siguiente:

for (int j = 1; j < 100; j++) {
                    String rulId="0";//defult value,to privent null pointer exeption in group_c
                    try {
                        rulId = group.get(0).get("group_c" + j)).toString();
                    } catch (Exception ex) {
                        ServerLog.Print( "Handeled error in database for " + "group_c" + (j < 10 ? "0" + j : j) +"This error handeled and mot efect in program");
                        rulId = "0";
                    }}

Esta es mi enfoque, necesita una clase PropertyUtil sin embargo, pero su único escrito una vez:

/**
 * Generic method to encapsulate type casting and preventing nullPointers.
 * 
 * @param <T>          The Type expected from the result value.
 * @param o            The object to cast.
 * @param typedDefault The default value, should be of Type T.
 * 
 * @return Type casted o, of default.
 */
public static <T> T getOrDefault (Object o, T typedDefault) {
    if (null == o) {
        return typedDefault;
    }
    return (T) o;
}

El código de cliente puede hacer esto:

PropertyUtil.getOrDefault(obj.getAttribute("someAttr"), "").equals("true");

o, para una lista:

PropertyUtil.getOrDefault(
    genericObjectMap.get(MY_LIST_KEY), Collections.EMPTY_LIST
).contains(element);

O a un consumidor de la lista, que rechazarían objeto:

consumeOnlyList(
    PropertyUtil.getOrDefault(
        enericObjectMap.get(MY_LIST_KEY), Collections.EMPTY_LIST
    )
)

El valor predeterminado puede ser un impl del patrón de objeto nulo https://en.wikipedia.org/wiki / Null_Object_pattern

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