¿Qué significa escribir "buen código"? [cerrado]

En esta pregunta le pregunté si ser un mal escritor le impide escribir un buen código. Muchas de las respuestas comenzaron con "depende de lo que entiendas por buen código".

Parece que el término "código bueno" y "código malo" son muy subjetivos. Como tengo una vista, puede ser muy diferente de la vista de los demás.

Entonces, ¿qué significa escribir "buen código"? ¿Qué es el "buen código"?

Un buen codificador es como un buen jugador de billar.

Cuando ve a un jugador de billar profesional, al principio puede que no le impresione: "¡Claro, metieron todas las bolas, pero solo tenían tiros fáciles!" Esto se debe a que, cuando un jugador de billar está haciendo su tiro, no piensa en qué bola irá a qué bolsillo, también está pensando en dónde terminará la bola blanca . Prepararse para la próxima toma requiere una gran habilidad y práctica, pero también significa que parece fácil.

Ahora, trayendo esta metáfora al código, un buen codificador escribe código que parece que fue fácil y sencillo de hacer . Muchos de los ejemplos de Brian Kernighan en sus libros siguen este patrón. Parte del "truco" es llegar a una conceptualización adecuada del problema y su solución . Cuando no comprendemos un problema lo suficientemente bien, es más probable que complicamos demasiado nuestras soluciones y no veremos ideas unificadoras.

Con una conceptualización adecuada del problema, obtiene todo lo demás: legibilidad, facilidad de mantenimiento, eficiencia y corrección. Debido a que la solución parece tan sencilla, es probable que haya menos comentarios, porque no es necesaria una explicación adicional. Un buen codificador también puede ver la visión a largo plazo del producto y formar sus conceptualizaciones en consecuencia.

( original )

EDITAR: La idea básica es que "Calidad de código" no se puede poner en reglas, de la misma manera que no se puede poner "Buen arte" o "Buena poesía" en las reglas para que pueda dejar que una computadora determine que diga "Sí, buen arte" o "No, mala poesía". Actualmente, la única forma es ver cuán fácilmente comprensible es el código para otros humanos.

Realmente no hay un buen criterio que no sea qué tan rápido puede entender el código. Hace que su código se vea bien al encontrar el compromiso perfecto entre la concisión y la legibilidad.

El "WTF por minuto" (arriba) es cierto, pero es solo un corolario de la regla más general. Cuantos más WTFs, más lenta será la comprensión.

Sabes que escribes un buen código cuando ...

1. El cliente es feliz
2. Compañeros de trabajo toman prestado su código como punto de partida
3. Se le dijo al nuevo chico / chica que hiciera modificaciones a un sistema que construiste hace 6 meses y nunca te hizo una pregunta
4. Tu jefe te pide que desarrolles nuevos widgets para que el equipo los use
5. Miras el código que escribes hoy y te dices a ti mismo: "Ojalá hubiera escrito un código como este hace dos años".

¿Cómo se mide si el código es bueno ...

• ¿Cuál es el tiempo de respuesta?
• ¿Cuántos viajes de ida y vuelta al servidor hace?
• ¿Usaría personalmente la aplicación o cree que es torpe?
• ¿Lo construirías de la misma manera la próxima vez?

Un buen código funciona cuando se supone que debe hacerlo. Un buen código puede modificarse fácilmente cuando sea necesario. Un buen código puede ser reutilizado para obtener ganancias.

Un código que es

1. Libre de errores

2. reutilizable

3. independiente

4. menos complejo

5. bien documentado

6. fácil de cambiar

se llama buen código.

Un buen programa funciona a la perfección y no tiene errores. ¿Pero qué cualidades internas producen tal perfección? No es ningún misterio, solo necesitamos algún recuerdo ocasional. Ya sea que codifique en C / C ++, C #, Java, Basic, Perl, COBOL o ASM, toda buena programación exhibe las mismas cualidades tradicionales: simplicidad, legibilidad, modularidad, estratificación, diseño, eficiencia, elegancia y claridad, eficiencia, elegancia. y claridad

Fuente: MSDN

¿Te parece familiar?

Philips me dio la oportunidad de ver el diseño de un nuevo producto. A medida que se desarrolló, me puse cada vez más incómodo y comencé a confiar mis preocupaciones a mi supervisor. Le dije repetidamente que los diseños no eran "limpios" y que deberían ser "hermosos" en la forma en que los diseños de Dijkstra eran hermosos. No encontró que esto sea un comentario útil. Me recordó que éramos ingenieros, no artistas. En su mente, simplemente estaba expresando mi gusto y él quería saber qué criterio estaba usando para hacer mi juicio. ¡No pude decírselo! Como no podía explicar qué principios se estaban violando, mis comentarios simplemente fueron ignorados y el trabajo continuó. Sintiendo que debe haber una manera de explicar y motivar mi "gusto", Comencé a tratar de encontrar un principio que distinguiera los buenos diseños de los malos. Los ingenieros son muy pragmáticos; Pueden admirar la belleza, pero buscan la utilidad. Traté de encontrar una explicación de por qué la "belleza" era útil.

Por favor, vea el resto aquí .

aparte de los criterios de calidad del código natural (mínimo copiar / pegar, sin espagueti, etc.), un buen código industrial siempre debe parecer un poco ingenuo, un poco demasiado detallado, como

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

Opuesto a

Record r = cache.get(i++, false);

Quizás una respuesta al ilustrar lo contrario ayudaría (además es una excusa para obtener XKCD aquí).

Buen código es

• simple de entender
• facil de mantener,
• no intenta resolver todos los problemas solo el que está a la mano
• vive por mucho tiempo sin hacer que los desarrolladores busquen alternativas

Ejemplos incluyen

• Apache Commons
• Marco de primavera
• Marco de hibernación

Simplemente iré con "mantenible"

Se debe mantener todo el código: no es necesario que esa tarea se haga más difícil de lo necesario

Si algún lector no comprende este simple requisito o necesita que se lo explique, entonces ese lector no debería estar escribiendo código ...

Un buen código será diferente para cada persona y el lenguaje con el que están trabajando también tiene un impacto sobre lo que podría considerarse un buen código. Generalmente cuando me acerco a un proyecto busco lo siguiente:

• ¿Cómo se organiza el proyecto? ¿Los archivos fuente están organizados de manera limpia y puedo encontrar el código sin demasiado esfuerzo?
• ¿Cómo se organiza el código? ¿Está claramente documentado lo que hace el código en el archivo, como mediante el uso de un encabezado de archivo o mediante el uso de cada clase que reside en su propio archivo? ¿Hay funciones en el archivo que ya no se utilizan en la aplicación?
• ¿Cómo se organizan las funciones? ¿Existe un patrón claro sobre dónde se declaran las variables, o es un patrón bastante aleatorio? ¿El código tiene un flujo lógico y evita estructuras de control innecesarias? ¿Está todo claramente documentado con el código auto documentado donde sea necesario y los comentarios expresan claramente por qué y / o cómo está haciendo el código?

Más allá de todo esto, ¿tiene sentido el diseño de la aplicación en su conjunto? El código que reside en la aplicación puede ser el mejor del mundo, pero aún puede ser difícil trabajar con él si el diseño general de la aplicación no tiene sentido.

Permítanme amablemente estar en desacuerdo sobre la lectura. No, no completamente: un buen código debe ser legible, y eso se puede lograr fácilmente con suficientes comentarios.

Pero considero dos tipos de WTF: aquellos en los que te preguntas si el programador fue más allá de programar 101, y aquellos en los que no entiendes absolutamente la genialidad del código. Algunos códigos pueden parecer muy extraños al principio, pero en realidad es una solución muy ingeniosa para un problema difícil. El segundo no debe contar en el medidor WTF, y puede evitarse mediante comentarios.

El código muy legible puede ser muy, muy lento. Una solución menos legible puede proporcionar una mejora múltiple en la velocidad. R es un gran ejemplo de un lenguaje donde eso a menudo es cierto. A uno le gusta evitar for-loops allí tanto como sea posible. En general, consideraría que el código más rápido es el mejor código aunque sea menos legible. Es decir, si la mejora es sustancial por supuesto, y se insertan suficientes comentarios para explicar lo que hace el código.

Aún más, la gestión de la memoria puede ser crucial en muchas aplicaciones científicas. El código que es muy fácil de leer, tiende a ser un poco descuidado en el uso de la memoria: simplemente se crean más objetos. En algunos casos, el uso inteligente de la memoria hace que el código vuelva a ser menos legible. Pero si hace malabares con gigabytes de secuencias de ADN, por ejemplo, la memoria es un factor crucial. Una vez más, considero que el código que requiere menos memoria es el mejor código, independientemente de la legibilidad.

Entonces sí, la legibilidad es importante para un buen código. Conozco el adagio de Uwe Liggis: pensar que duele y las computadoras son baratas. Pero en mi campo (genómica estadística), los tiempos computacionales de una semana y el uso de memoria de más de 40 Gb no se consideran anormales. Por lo tanto, una mejora del doble de la velocidad y la mitad de la memoria vale mucho más que ese bit adicional de legibilidad.

En lo que respecta a mí ... Sé que estoy escribiendo un buen código cuando aparece un compañero de trabajo que trabaja en otro proyecto y puede intervenir y comprender lo que estoy haciendo sin que revise cada bloque de código. y mostrando lo que está haciendo.
En lugar de que él diga: "Espera un minuto, ¿qué?" Él dice: "Oh, está bien, veo lo que hiciste allí".

Un buen código tampoco tiene muchas soluciones furtivas o 'hacks'. Líneas cuando, mientras lo escribes, también te dices a ti mismo: "Sé que esta no es una buena manera de hacerlo, pero por ahora tendré que hacerlo de esta manera. Te recordaré yo mismo para mejorarlo más tarde ... "

Hay muchas características del código 'bueno', pero la más importante, en mi humilde opinión, son la legibilidad y la facilidad de mantenimiento.

Su código será contener errores, será probablemente se extenderá y volver a utilizarse, y debiera ser re-factorizada en algún momento - incluso si es que se volvió a acceder a él, lo más probable es que no tienen ni idea de qué demonios lo hiciste en primer lugar, para hacerte un favor y no poner barreras en el camino.

Claro, use ese algoritmo complejo pero súper eficiente, pero asegúrese de dedicar un poco más de tiempo a documentarlo, pero de lo contrario haga que su código sea claro y consistente.