¿Hay alguna forma más concisa de escribir este código Java?

Este foo que es devuelto por lookup podría ser null.¿Hay alguna forma más concisa de escribir este código Java?

Es por eso que estoy tratando de evitar que se pongan en foo.getFooStr() un valor null empezando por volver null si es foonull.

¿Pero hay una forma mejor (más concisa) de escribir esto?

public static String getFooStr(String input) 
{ 
    Foo foo = lookup(input); 
    if(foo==null) 
    { 
     return null; 
    } 
    return foo.getFooStr(); 
}

Fuente

2011-09-11 Brandon Pike

Esta pregunta es lo suficientemente similar (pero no idéntica) para poder brindarle alguna idea: http://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java –

No hay nada de malo con lo que has escrito Escribirlo para que parezca más corto no necesariamente lo hace mejor. – Matt

Además, puede tener puntos de corte en diferentes líneas para el caso de que la cadena sea nula o no nula. Eso ayuda con la depuración. –

Por qué no hay un lookup que devuelve la cadena foo apropiado?

Fuente

2011-09-11 22:49:51

+1 sí, debe hacerse por búsqueda. –

+1 Esto sería lo más conciso. ;) –

Tienes dos preguntas: ¿existe una mejor manera de escribir el código, y es que hay una manera más concisapara escribir el código.

En cuanto más concisa , esto podría funcionar:

public static String getFooStr(String input) { Foo foo = lookup(input); return foo == null ? null : foo.getFooStr(); }

En cuanto mejor: valoro la legibilidad sobre la concisión cualquier día, y por un amplio margen. Tu código original se ve bien para mí. Lo que importa es lo que se ve bien para ti, y que es más fácil de entender y depurar dentro de 3 meses. He escuchado a alguien decirlo mejor: escriba su código para que otros lo entiendan fácilmente y, lo que es más importante, para su yo futuro.

Fuente

2011-09-11 22:50:15

+1 en mi humilde código menos es bueno, siempre y cuando todavía está claro, y esto es. Por cierto, eliminé el ruido del soporte (es decir, 'foo == null' en lugar de' (foo == null) ') para una mejor legibilidad. Espero que no te importe. – Bohemian

@Bohem: ¡gracias! –

@Bohem: HFOE lo dijo bien, lo que importa es qué ... es más fácil de entender y de depurar ... y para que sea fácilmente comprensible para otros. El "ruido de paréntesis" que eliminó puede ser solo ruido para aquellos de nosotros que conocemos la gramática de los operadores tipo C como casi una lengua materna; para las personas menos experimentadas (que son muchas más personas, pero pueden no ser su audiencia), los paréntesis lo hacen más legible, porque no tienen que saber si '?:' tiene una precedencia mayor que '=='. No digo que te equivoques al eliminar los parens, pero no son ruidosos, y lo más probable es que los deje en. – LarsH

No estoy en Java, pero sí me gusta el código limpio ... El código fuente debe ser fácil de leer y entender para los humanos: a la máquina no le importa cómo se ve, pero sus colegas sí. El código más conciso generalmente toma un momento o dos más para comprender (a veces mucho más dependiendo de la cantidad y complejidad). Mantenga el código comprensible y será mantenible (¡incluso si es un poco más detallado)!

Fuente

2011-09-11 22:51:45

Groovy does it nicer.

return lookup(input)?.fooStr

or even just:

lookup(input)?.fooStr

Fuente

2011-09-11 22:53:24

no necesita la devolución ;-) – Steven

Muy cierto @Steven, gracias! Actualizado. –

Para Java 7, en algún momento se planeó que usted podría escribir lo siguiente:

public static String getFooStr(String input) 
{ 
    Foo foo = lookup(input); 
    return foo?.getFooStr(); 
}

Pero hasta que esta característica es ampliamente conocido, deberá apegarse al operador ?:.

Fuente

2011-09-11 22:54:20

Si actualmente está disponible en Java7 cualquier doco, por favor enlace si es posible. Me interesaría leer sobre esto. –

Esa característica no entró en Java7 y dudo que se agregue pronto. Aunque C# obviamente lo tiene ;-) – Voo

El operador de Elvis fue eliminado de Java 7 en 2009. El sitio Project COIN dice esto: * "Mientras que el operador de Elvis y los operadores relacionados son útiles en Groovy, las diferencias entre Groovy y Java, como el la presencia de tipos primitivos y las interacciones con el boxeo/unboxing hacen que los operadores sean menos útiles en Java. JDK 7 soportará otras formas de aliviar el dolor del manejo nulo, como la comprobación nula habilitada por JSR 308. "* (JSR 308 es tipo anotaciones, y eso quedó en JDK 8) –

No me gustan los retornos múltiples en ningún lugar y en ningún código. Sólo voy a cambiarlo a

public static String getFooStr(String input) 
{ 
    Foo foo = lookup(input); 
    String fooString; 
    if(foo!=null) 
    { 
     fooString = foo.getFooStr(); 
    } 
    return fooString; 
}

también la versión completa de @Hovercraft de anguilas es bueno en mi opinión pero menos legible, pero sigue siendo una forma común de hacerlo.

Fuente

2011-09-11 23:34:58

Si no le gustan las devoluciones múltiples, entonces no mire 'Throwable'. –

si el código anterior no es lo suficientemente claro, no debería estar codificando @EricLindauer –

@EricLindauer ¿me ha bajado? –

¿Hay alguna forma más concisa de escribir este código Java?

Respuesta

Cuestiones relacionadas