Retorno booleano de set.add () en if conditional?

El operador add de la clase set devuelve un valor booleano que es verdadero si el elemento (que se agregará) ya no estaba allí, y falso de lo contrario. Esta escribiendo

if (set.add(entry)) {
    //do some more stuff
}

considerado un buen estilo en términos de escribir código limpio? Me pregunto ya que haces dos cosas a la vez. 1) agregar el elemento y 2) verificar si el elemento existió.

Sí lo es.

El punto habitual de que una operación devuelva un valor booleano es que puede usarlo para tomar decisiones, es decir, dentro de una ifconstrucción. La única otra forma en que podría darse cuenta de este potencial sería almacenar el valor de retorno en una variable y luego reutilizarlo inmediatamente en un if, lo cual es simplemente tonto y ciertamente no es preferible de ninguna manera a la escritura if(operation()) { ... }. Así que solo adelante y haz eso, no te juzgaremos (por eso).

Diría que no es tan limpio como sea posible, porque obliga al mantenedor a saber o buscar lo que significa el valor de retorno. ¿Significa que el valor ya existía, no existía, se insertó con éxito? Si no lo usa mucho, no lo sabrá, e incluso si lo hace, es mucha más carga mental.

Preferiría lo siguiente:

boolean added = set.add(entry);

if (added) {
    //do some more stuff
}

Sí, un poco más detallado, pero el compilador debería generar prácticamente el mismo código de bytes, e incluso las personas que no han usado conjuntos de Java en años pueden seguir la lógica sin buscar nada.

Si verdadero significa éxito, entonces es bueno, código claro.

Existe una convención generalizada de que una función o método devuelve verdadero (o algo que se evalúa como verdadero) en caso de éxito. Mientras su código siga eso, creo que poner el método en condicional está bien.

Un código como este está innecesariamente desordenado en mi opinión:

boolean frobulate_succeeded = thing.frobulate();

if (frobulate_succeeded) {
    ...
}

Se siente como si te estuvieras repitiendo.

Sin embargo, la pregunta es ambigua sobre el significado del valor de retorno. Usted dice "un valor booleano que indica si el elemento agregado ya existía", lo que podría implicar que verdadero significa que el elemento existió (y no se produjo la suma). Si ese es el caso, idealmente cambiaría el comportamiento de retorno del método para que sea más convencional. Si eso no es posible, agregaría una variable intermedia adicional que le permite etiquetar claramente el resultado de retorno en su código (como lo sugieren otros).

Yo diría que es muy parecido a C. La mayoría de las veces preferiría tener una variable con un nombre descriptivo para un resultado de mutación, y que no ocurra mutación en una ifcondición.

Un compilador eliminará esta variable si se reutiliza de inmediato. Un humano tendrá más fácil leer la fuente; Para mí, es más importante.

Si alguien tiene que extender la condición agregando una cláusula and/ ora la condición if, puede terminar no llamando .add()en ciertos casos debido a la evaluación de cortocircuito. A menos que se anticipe específicamente un cortocircuito, esto puede terminar como un error.

Su código parece romper la separación de consulta de comando . Esto se discute en el libro Clean Code y en el video Function Structure . Entonces, desde una perspectiva de Código limpio, creo que no se considera un buen estilo.

“El código limpio es simple y directo. El código limpio se lee como una prosa bien escrita. El código limpio nunca oscurece la intención del diseñador, sino que está lleno de abstracciones nítidas y líneas de control directas.

- Grady Booch, autor de Análisis y diseño orientado a objetos con aplicaciones "

Para mí, la intención de su código no está clara. ¿Se ejecuta ambos si la entrada se agrega con éxito o también cuando ya existe? ¿Qué add()devuelve? ¿el objeto? El código de error?