Comentarios
Respuesta
Un buen programador es como un buen jugador de billar.
Cuando veas a un jugador de billar profesional, al principio puede que no te impresione: «¡Claro, metieron todas las bolas, pero solo hicieron tiros fáciles!» Esto se debe a que, cuando un jugador de billar está lanzando su tiro, no piensa en qué bola entrará en qué tronera, también está pensando en dónde terminará la bola blanca . Prepararse para la siguiente toma requiere mucha habilidad y práctica, pero también significa que parece fácil.
Ahora, incorporando esta metáfora al código, una buena El codificador escribe código que parece fácil y directo de hacer . Muchos de los ejemplos de Brian Kernighan en sus libros siguen este patrón. Parte del «truco» es idear una conceptualización adecuada del problema y su solución . Cuando no entendemos un problema lo suficientemente bien, es más probable que compliquemos demasiado nuestras soluciones y no veremos ideas unificadoras.
Con una conceptualización adecuada del problema, se obtiene todo más: legibilidad, mantenibilidad, eficiencia y corrección. Debido a que la solución parece tan sencilla, probablemente habrá menos comentarios, porque no es necesaria una explicación adicional. Un buen programador también puede ver la visión a largo plazo del producto y formar sus conceptualizaciones en consecuencia.
Comentarios
Responder
s por minuto
( original )
EDITAR: La idea básica es que la «Calidad del código» no se puede poner en reglas, de la misma manera que no se puede poner «Buen arte» o «Buena poesía» en reglas para que una computadora determine que diga «Sí, buen arte «o» No, mala poesía «. Actualmente, la única forma es ver qué tan fácil de entender el código es para otros humanos.
Comentarios
Respuesta
Realmente no hay buenos criterios para otros que lo rápido que puede entender el código. Puede hacer que su código se vea bien al encontrar el compromiso perfecto entre concisión y legibilidad.
Los «WTF» por minuto «(arriba) es cierto pero es sólo un corolario de la regla más general. Cuantas más WTF, más lenta será la comprensión.
Comentarios
Respuesta
Sabes que escribes un buen código cuando …
El cliente está contento
Los compañeros de trabajo toman prestado tu código como punto de partida
Al nuevo chico / chica le dijeron que hiciera modificaciones a un sistema que usted construyó hace 6 meses y nunca le hizo una pregunta
Su jefe le pide que desarrolle nuevos widgets para el equipo a utilizar
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 medir si el código es bueno …
¿Cuál es el tiempo de respuesta?
¿Cuántos viajes de ida y vuelta al servidor hace?
¿Utilizaría personalmente la aplicación o cree que es torpe?
¿La construiría de la misma manera la próxima vez?
Un buen código funciona cuando es supone. El buen código se puede modificar fácilmente cuando sea necesario. El buen código se puede reutilizar para obtener ganancias.
Comentarios
Responder
Un código que es
sin errores
reutilizable
independiente
menos complejo
bien documentado
fácil de cambiar
se llama buen código.
Un buen programa funciona perfectamente y no tiene errores. Pero, ¿qué cualidades internas producen tal perfección ?. No es ningún misterio, solo necesitamos un recordatorio 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 , capas, diseño, eficiencia, elegancia y claridadeficiencia, elegancia y claridad
Fuente: MSDN
Comentarios
Respuesta
¿Te parece familiar?
Philips me dio la oportunidad de ver el diseño de un nuevo producto. A medida que se desarrolló, me sentí cada vez más incómodo y comencé a confiarle mis preocupaciones a mi supervisor. En repetidas ocasiones le dije que los diseños no eran «limpios» y que debían ser «hermosos» en la forma en que lo eran los diseños de Dijkstra. No le pareció un comentario útil.Me recordó que éramos ingenieros, no artistas. En su mente, simplemente estaba expresando mi gusto y 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. Intenté encontrar una explicación de por qué la «belleza» era útil.
Consulte el resto aquí .
Comentarios
Respuesta
Aparte de los criterios naturales de calidad del código (copia / pegado mínimo, sin espaguetis, etc.), un buen código industrial siempre debe verse 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;
en lugar de
Record r = cache.get(i++, false);
Comentarios
Respuesta
Quizás una respuesta ilustrando lo contrario ayudaría (además es una excusa para obtener XKCD aquí).
Un buen código es
simple de entender,
fácil de mantener ,
no intenta resolver todos los problemas, solo el que tiene a mano
perdura durante mucho tiempo sin que los desarrolladores busquen alternativas
Los ejemplos incluyen
Apache Commons
Marco Spring
Marco Hibernate
Respuesta
Simplemente iré con «mantenible»
Todo el código debe mantenerse: no es necesario que esa tarea sea más difícil de lo necesario
Si algún lector no comprende este simple requisito o necesita que se le explique, entonces ese lector no debería estar escribiendo código …
Respuesta
Un buen código será diferente para cada persona y el idioma con el que están trabajando también tiene un impacto sobre lo que podría considerarse ser un buen código. Generalmente, cuando me acerco a un proyecto, busco lo siguiente:
¿Cómo está organizado el proyecto? ¿Los archivos fuente están organizados de manera limpia y puedo encontrar código sin demasiado esfuerzo?
¿Cómo está organizado el código? ¿Está claramente documentado lo que hace el código en el archivo, por ejemplo, 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 están organizadas las funciones? ¿Existe un patrón claro en el que 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 el por qué y / o cómo de lo que hace el código?
Más allá de todo esto, ¿el diseño la aplicación tiene sentido en su conjunto? El código que reside en la aplicación puede ser el mejor del mundo, pero puede resultar complicado trabajar con él si el diseño general de la aplicación no tiene sentido.
Respuesta
Permítame tener la amabilidad de no estar de acuerdo con la legibilidad. No, no del todo: 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 llegó más allá de la programación 101, y aquellos en los que no entiendes absolutamente la genialidad del código. Algunos códigos pueden parecer muy extraños primero, pero en realidad es una solución muy inventiva para un problema difícil. El segundo no debería contar en el medidor de WTF y puede evitarse mediante comentarios.
El código muy legible puede ser muy, muy lento . Una solución menos legible puede mejorar la velocidad muchas veces. R es un gran ejemplo de un lenguaje en el que eso a menudo es cierto. A uno le gusta evitar los bucles for allí tanto como sea posible.En general, consideraría que el código más rápido es el mejor, 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 legible, tiende a ser un poco descuidado en el uso de la memoria: solo 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 consume menos memoria es el mejor, independientemente de la legibilidad.
Así que sí, la legibilidad es importante para un buen código. Conozco el adagio de Uwe Liggis: pensar 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 velocidad y la mitad de la memoria vale mucho más que ese poco de facilidad de lectura.
Comentarios
está pasando allí (allí mismo en los comentarios)?