¿Es una buena práctica declarar variables "definitivas" siempre que sea posible?

Duplicar posibles:
When should one use final?¿Es una buena práctica declarar variables "definitivas" siempre que sea posible?

tiendo a declarar todas las variables final menos que sea necesario. Considero que es una buena práctica porque permite al compilador verificar que el identificador se usa como espero (por ejemplo, no está mutado). Por otro lado, complica el código, y tal vez este no es "el camino de Java".

Me pregunto si hay una mejor práctica generalmente aceptada con respecto al uso no requerido de las variables finales, y si hay otras compensaciones o aspectos de esta discusión que deben tenerse en cuenta.

Fuente

2012-05-21 Landon Kuhn

La idea del código opcional que puede o no expresar la intención del desarrollador y que puede o no conducir a optimizaciones del compilador suena como algo sacado de un comic de XKCD. – jordanpg

Lo importante es tener mucho cuidado con lo que quieres decir con final. los objetos mutables finales aún se pueden modificar, lo que algunos novatos olvidan. Este es el gran problema que tengo con el final realmente, cada vez que estoy trabajando con un objeto mutable el * intento * de final se pone turbio, conozco el significado literal, pero la persona que usa el final realmente está bien conmigo modificando el contenido del objeto a pesar de que es final o no? – dsollen

Algunas buenas herramientas de análisis, como PMD, consejos para poner siempre final a menos que sea necesario. Entonces la convención en esas herramientas dice que es una buena práctica

Pero creo que tantos tokens finales en el código pueden hacer que sea menos amigable para los humanos.

Fuente

2012-05-21 18:23:04 richarbernal

Considero que es una buena práctica, más para los programadores de mantenimiento (incluyéndome a mí) que para el compilador. Es más fácil pensar en un método si no necesito preocuparme acerca de qué variables pueden estar cambiando dentro de él.

Fuente

2012-05-21 18:23:13

¡Sí! Ese es un buen punto. La legibilidad se mejora porque instantáneamente sabe que esta variable no va a cambiar. Lo hace más simple de pensar. –

Me gustaría aclarar esto un poco, sobre todo para los novatos de Java que pueden leer mal esto. Mi primera lectura perezosa me hizo pensar que dijiste que era más fácil usar un método existente porque no tenías que preocuparte de que el método cambiara nada, lo cual no tenía sentido ya que el finial no protege contra eso. Al volver a leerlo, estoy bastante seguro de que te refieres a que cuando lees un método existente y averiguas qué es, es más fácil analizarlo con un final asignado, lo que tiene más sentido. Sin embargo, me temo que los novatos de Java pueden leerlo de la forma original y ser demasiado nuevo para darse cuenta de que eso no funciona. – dsollen

Definitivamente le da un mejor código, fácil de ver qué variables se van a cambiar.

También informa al compilador que no va a cambiar, lo que puede resultar en una mejor optimización.

Además, permite a su IDE darle una notificación de tiempo de compilación si tiende a cometer un error.

Fuente

2012-05-21 18:24:51 mprabhat

No estoy de acuerdo. Puede declarar una colección como definitiva pero aún así podrá cambiar sus contenidos ... ¡Lo único que no podrá hacer es asignar otra REFERENCIA! Estoy de acuerdo en usar campos finales para cuando sea necesario, pero para variables de métodos locales ??? Su alcance debería ser lo suficientemente limitado ... Esa es solo mi opinión. – Lawrence

Más o menos, resumió los pros y los contras ...

sólo puedo añadir otro ámbito:

el lector del código no necesita razonar en absoluto sobre el valor de una variable final (a excepción de raros casos de código incorrecto).

Entonces, sí, es una buena práctica.

Y el desorden no es tan malo, después de que te acostumbras (como unix :-P). Además, los IDEs típicos lo hacen automáticamente para usted ...

Fuente

2012-05-21 18:26:02 yair

La "forma de Java" es intrínsecamente intrincada.

Digo que es una buena práctica, pero no una que sigo.

Las pruebas generalmente aseguran que estoy haciendo lo que pretendo, y es también cluttery para mi estética.

Fuente

2012-05-21 18:27:15

Esto resume exactamente cómo me siento al respecto. Solo uso final en mis cadenas estáticas. Dado que Java pasa los objetos por valor (a diferencia de C), el uso de final allí también es solo abarrotar cosas. Al final, o sabes lo que estás haciendo o no. NUNCA he tenido un error que podría haberse evitado mediante el uso de la final ... ¡Nunca! – Lawrence

Sí, es una muy buena idea, porque muestra claramente qué campos se deben proporcionar en la construcción del objeto.

Estoy totalmente en desacuerdo con que crea un "desorden de código"; es un aspecto bueno y poderoso del lenguaje.

Como principio de diseño, debe hacer sus clases immutable (todos los campos finales) si puede, porque pueden publicarse de forma segura (es decir, se pueden pasar libremente sin temor a que se corrompan). Aunque tenga en cuenta que los campos también necesitan ser objetos inmutables.

Fuente

2012-05-21 18:27:18 Bohemian

Yo diría que sí, no tanto para la optimización del compilador, sino más bien para la legibilidad.

Pero personalmente yo no lo uso. Java es bastante detallado por sí mismo, y si seguimos todo lo que se considera "buena práctica", el código sería irreprochable de todos los repetitivos. Sin embargo, es una cuestión de preferencia.

Fuente

2012-05-21 18:30:37

Yo habitualmente aplico final a las variables locales en mi código y, además, resulta código lectura mucho más fácil después de la primera de haber marcado todas effictively finales variables con la palabra clave final. Considero esto como una mejora genuina del código, y lo comprometo justo después.

En cuanto a la preocupación del desorden de código, cuando se aplica a las variables locales no me parece dañino —, de hecho, me hace detectar todas las declaraciones más fácilmente debido a la coloración de sintaxis.

tengo que admitir, sin embargo, que yo hago encontrarlo insoportablemente cluttery cuando final se utiliza en los parámetros de captura, bloques mejorado de los bucles y todos los demás lugares, excepto las variables locales en el sentido estricto. Esto es bastante desafortunado porque una reasignación en estos casos es aún más confusa y deberían haber sido definitivas por defecto.

Fuente

2012-05-21 18:32:29

¿Es una buena práctica declarar variables "definitivas" siempre que sea posible?

Respuesta

Cuestiones relacionadas