¿Qué hace que el "buen estilo" en Java? [cerrado]

9

Había hecho esta pregunta en Stackoverflow, y antes de que se abucheara, recibí la sugerencia útil de Péter Török de que este podría ser un mejor lugar para publicarla.

He estado programando en Java por algunos años. A menudo he discutido las decisiones de diseño con colegas sobre la base de lo que constituye un "buen estilo". De hecho, hay una serie de preguntas / respuestas de StackOverflow que discuten un diseño sobre la base de si algo es 'buen estilo'.

Pero, ¿qué hace "buen estilo"? Como muchas cosas, lo sé cuando lo veo ... pero quería tener una mejor idea que solo mi conciencia diciendo que este diseño no se siente bien.

¿En qué piensa para producir un código bueno y bien diseñado?

(Reconozco que esto es algo subjetivo, ya que lo que es 'buen estilo' dependerá de la tarea en cuestión). (Además, debo agregar que no estoy interesado en los estilos de equipo, por ejemplo, "usamos sangrías de 2 espacios en lugar de 4" ..., y no estoy interesado en las convenciones de código Java).

Editar: gracias por todas las buenas respuestas / comentarios hasta ahora. ¿Me interesan especialmente las respuestas que ayuden a codificar aquellas cosas que hacen que la conciencia de un programador (y posiblemente el estómago) se desgarre?

java coding-style

— asombro
fuente

Entre muchas otras cosas enumeradas aquí, definitivamente me aseguraría de decir simplemente que las computadoras pueden compilar código de casi cualquier forma en que lo escriba, pero en última instancia, el código debe ser legible para los humanos . Comenta como loco! Una buena prueba que me gusta usar: ¿podría una persona leer solo mis comentarios para saber qué hace el código, cuáles deberían ser sus entradas y salidas y los algoritmos utilizados para hacerlo?

— Brian

1

@brian, haz que tu código explique cómo . Deja comentarios reales para explicar por qué . En otras palabras, no comente como loco (en el caso general)

44

Brian: Esa técnica definitivamente no se considera una buena práctica. Una buena práctica común es apuntar a hacer que su código sea lo más autodocumentable posible (con nombres de variables claros y cohesión de funciones), con comentarios para explicar el "por qué" y no el "cómo". Los comentarios que explican cada pequeño detalle generalmente se consideran distractores y, a menudo, peligrosos, ya que es menos probable que las personas mantengan los comentarios que el código.

— Casey Patton

1

@Brian: Tu última declaración lo dice todo. El código debe ser legible. Los comentarios se vuelven obsoletos. El código nunca lo hace. Si siente la necesidad de comentarios, refactorice hasta que el código sea tan claro que los comentarios simplemente repitan lo que dice el código. El único buen comentario es uno que dice por qué el código funciona de una manera particular, como evitar un error en una biblioteca de terceros, para que alguien no regrese y lo cambie por algo que no funcionará por una razón. eso no es inmediatamente aparente.

— Ryan Stewart el

2

Oficialmente he sido humillado. Lo siento @amaidment. Supongo que es necesario investigar buenos estándares de codificación cuando se trata de comentarios.

— Brian

17

Algunos breves puntos:

Nombres reveladores
No hay comentarios no instructivos.
Ningún método con una complejidad tan alta que no puedas meterlo todo en tu cabeza a la vez
Objetos de responsabilidad única
Siga las convenciones de código (usted dijo que no le importaba, pero es de vital importancia)

— Ryan Stewart
fuente

3

+1. Quizás lo más crítico: minimizar el código duplicado. Si tiene la tentación de cortar y pegar más de unos pocos tokens, debe extraer una función. Incluso si la función es una sola línea de código.

— Kevin Cline

44

En el código duplicado, tomo la siguiente postura. Cortar y pegar = está bien. Eso es solo mover el código (suponiendo que use pegar una vez). Copiar y pegar = horrible. Si solo elimina el botón copiar de su vocabulario, es más probable que haga lo correcto.

— jsternberg

@jsternberg: +1 para la distinción de cortar / copiar, pero noto que mucha gente dice "cortar / pegar" cuando quieren decir "copiar / pegar". No sé cómo se perdió la distinción.

— Ryan Stewart

55

No te repitas a ti mismo. No te repitas a ti mismo. No te repitas a ti mismo.

— Configurador

1

@configurator, hueles un poco raro ...

9

Agregando a la lista de Ryan:

Sigue los principios SOLIDOS
Asegúrese de que su código no tenga demasiada complejidad cíclica
Test Driven Java siempre es algo bueno
Si tienes una xFactoryFactoryclase, lo estás haciendo mal :-)
Dadas las bibliotecas de código abierto en el ecosistema de Java, reinventar la rueda es un mal estilo
Use la hora de Joda para la fecha y la hora

Me detendré ahí.

— Martijn Verburg
fuente

2

¿Pero qué hay de la HammerFactoryFactoryFactoryclase? ;-)

— Wayne Molina

@Wayne, las fábricas son una indicación de que algunas decisiones deben retrasarse, y FactoryFactoryFactories indican que realmente hay que tomar una decisión en tiempo de ejecución pero no se pudo.

Lo sé, estaba siendo sarcástico y hacía referencia a ese artículo sobre por qué entonces J2EE era demasiado complejo, con HammerFactories y HammerFactoryFactories y creo que HammerFactoryFactoryFactories. :)

— Wayne Molina

@ Martijn - gracias por el enlace SÓLIDO; No me he encontrado con eso antes. Sugieres usar JodaTime; ¿Es esto solo una aversión (apropiada) a las clases Java Calendar / Date? ¿Qué pasa con JSR310 (el sucesor de JodaTime)?

— sorpresa

Con suerte, JSR-310 llegará a Java 8 (hay un montón de nosotros preparándonos para ayudar a que eso suceda, contácteme si desea involucrarse). Mientras tanto, el tiempo de Joda es el estándar de facto para tratar con la fecha y la hora en Java. Hay tantas cosas mal con el sistema de fecha y calendario de Java que ni siquiera sé por dónde empezar ;-). El asesino es que las fechas son mutables y que no hay un concepto de un instante o período o ... no, me detendré allí :-).

— Martijn Verburg el

1

Si bien aprecio las respuestas de los demás, pensé que era justo compartir algunas de las cosas en las que pienso cuando intento escribir un buen código:

¿Qué necesita saber sobre esta clase / método / variable? es decir, ¿dónde debería vivir este conocimiento?
¿Cómo podría este código afectar la memoria / rendimiento de mi aplicación? (Reconozco que 'la optimización prematura es la raíz de todo mal'; por lo tanto, no sugiero pasar mucho tiempo optimizando, sino más bien una conciencia mientras escribo inicialmente mi código).
¿Está claro (del código y las estructuras de código) qué hace esto? (Trato de seguir la máxima: "Esforzarse por no hacer posible que la gente entienda, esforzarse por hacer que sea imposible que la gente malinterprete").

— asombro
fuente

1

Lea la clase String y ArrayList para obtener excelentes ejemplos de programación Java adecuada. Pero son muy concisos, casi estilo C, lo que no es necesariamente el mejor para el código mantenible con documentos java mínimos. La práctica común en mi tienda es no hacer comentarios, por lo que trato de comentar por código usando nombres var. Detallados de camelCase y el uso excesivo de nuevas líneas para delimitar una línea de pensamiento de otra. Sigo debatiendo el uso de pestañas para separar los vars de sus valores. Las pestañas pueden mejorar la legibilidad, IMO, pero solo cuando se hace mínimamente y es muy subjetivo. Me parece que se trata realmente de la audiencia. No hay mejor respuesta aquí.

— carlmart
fuente