¿Deberías sacrificar la legibilidad del código con la eficacia del código? [cerrado]

¿Deberías sacrificar la legibilidad del código con la eficacia del código?

por ejemplo, 3 líneas de código en 1 línea.

Leí en Code Craft por Pete Goodliffe que la legibilidad es la clave.

¿Tus pensamientos?

"Menos líneas" no siempre es lo mismo que "más eficiente". Supongo que quiere decir "¿Debería acortarse un programa a expensas de la legibilidad?".

Los programas deben estar escritos para que la gente los lea, y solo de manera incidental para que las máquinas se ejecuten.

-Abelson & Sussman, Estructura e interpretación de programas de computadora

En general, creo que es más importante que un programa se entienda fácilmente que que sea breve. Sin embargo, debo tener en cuenta que hacer que un programa sea más corto a menudo también lo hace más legible (existe el umbral obvio al llegar cuando el código comienza a verse como ruido de línea, pero hasta ese punto, expresar algo más sucintamente parece hacerlo más claro).

Hay excepciones específicas (como sus scripts de shell personales o uno de código de mezcla de datos) que nadie tendrá que mantener, y solo usted tendrá que leer. En esa situación, probablemente esté bien sacrificar algo de legibilidad por conveniencia, siempre y cuando todavía pueda entenderlo.

A veces sí.

La legibilidad es algo bueno para luchar. La mayor parte del código escrito para aplicaciones de línea de negocio típicas será lo suficientemente eficiente y es importante centrarse en la legibilidad. En áreas más exigentes de rendimiento (como la programación de videojuegos o el cálculo pesado), puede ser importante renunciar a la legibilidad a favor del uso de una función de lenguaje particular que es terriblemente ilegible y, sin embargo, increíblemente eficiente.

Para ver un ejemplo de esto último, vea la raíz cuadrada inversa rápida en Wikipedia.

En general, creo que es mejor hacer algo legible primero y preocuparme por el rendimiento después, siempre que se tomen precauciones de sentido común, como no elegir un algoritmo O (n ^ 2) sobre O (n). Sacrificar la legibilidad solo por brevedad es, en mi opinión, equivocado.

La única vez que sacrificaría la legibilidad sería cuando se demostrara que el código es un cuello de botella de rendimiento y una reescritura lo solucionaría. En ese caso la intención del código debe estar bien documentada para que, si hay un error, pueda rastrearse más fácilmente.

Eso no dice que la reescritura tiene que ser ilegible, por supuesto.

Lo cité antes , y lo citaré nuevamente:

Hazlo correcto,
déjalo claro,
hazlo conciso,
rápido.

En ese orden.

Wes Dyer

¿Deberías sacrificar la lectura del código con la eficacia del código?

En términos de código, siempre es bueno auto documentarse. Pero a veces eso no puede suceder. A veces es necesario optimizar y, a veces, ese código no es en sí mismo muy legible.

Para esto se inventaron los comentarios . Usalos, usalos a ellos. Incluso la asamblea tiene comentarios. Si ha escrito una gran cantidad de código y no hay ningún comentario a la vista, estoy preocupado. Los comentarios no afectan el rendimiento del tiempo de ejecución, pero algunas notas sobre lo que está sucediendo siempre ayudan.

En mi opinión, no hay absolutamente ninguna excusa para no tener algunos comentarios básicos. Claramente if ( x == 0 ) /* check if x is 0 */es totalmente inútil; no debe agregar ruido innecesario al código, sino algo como esto:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Es bastante útil

¿Deberías sacrificar la lectura del código con la eficacia del código?

Si la eficiencia es su objetivo actual (como en la fase de optimización) y sabe que tiene métricas, ¿no? - esa (s) línea (s) de código es el cuello de botella actual, entonces sí.

De lo contrario, no: la legibilidad le permitirá a usted (u otro) cambiar este código más adelante para hacerlo más eficiente, ya que es más fácil de entender.

Nadie gana Code Golf

por ejemplo, 3 líneas de código en 1 línea

Una idea particularmente terrible.

Costo de jugar código de golf - muy alto.

Costo para mantener programas ilegibles - astronómicos.

Valor de este tipo de código minimizado: cero. Todavía funciona, pero no funciona "mejor".

Eficiencia sabiamente elegida

Costo para elegir el algoritmo y la estructura de datos correctos: moderado.

Costo para mantener el algoritmo y la estructura de datos correctos: bajo.

Valor del algoritmo y estructura de datos correctos: alto. El uso de recursos es bajo.

Eficiencia tonta ("micro-optimización")

Costo de jugar alrededor de micro-optimización - alto.

Costo para mantener el código ilegible, micro optimizado, muy alto.

Valor de la microoptimización: varía. Cuando hay un valor distinto de cero aquí, los costos aún lo superan.

Depende de si estamos hablando de eficiencia en términos de qué tan rápido se ejecuta el código o eficiencia en qué tan rápido el desarrollador puede escribir el código. Si está sacrificando la legibilidad del código a favor de poder escribir código muy rápido, es probable que tenga que pagar el tiempo en el futuro en términos de depuración.

Sin embargo, si estamos hablando de sacrificar la legibilidad del código en términos de cuán rápido se ejecuta el código, entonces es probable que sea una compensación aceptable siempre que el código deba preformarse de manera eficiente. Escribir algo que se ejecute lo más rápido posible solo porque puede no es una razón tan buena como porque es algo así como la raíz cuadrada inversa rápida donde el rendimiento es clave. El truco va a estar entre equilibrar el código y asegurarse de que aunque la fuente sea difícil de leer, los comentarios que describen lo que hace explican lo que está sucediendo.

Muchos trucos, que se suponía que harían el código más rápido, pero tienden a hacerlo menos legible, ya no son necesarios, ya que los compiladores se volvieron muy inteligentes (incluso más inteligentes que la mayoría de los desarrolladores) o las máquinas se volvieron ridículas rápidamente.

No acepto el argumento de "legibilidad sobre rendimiento". Déjame darte una respuesta con un giro diferente.

Algunos antecedentes: ¿Sabes lo que me enferma? Cuando hago doble clic en Mi PC y tengo que esperar a que se complete. Si eso lleva más de 5 segundos, me siento realmente frustrado. Lo estúpido es, y no solo culpe a Microsoft por esto, ¡es que en algunos casos la razón por la que lleva tanto tiempo es que es necesario tomar una decisión sobre qué icono mostrar! Está bien. Así que aquí estoy sentado, solo interesado en ir a mi unidad C:, y tengo que esperar a que el controlador acceda a mi CD-ROM y leer el icono desde allí (suponiendo que haya un CD en la unidad).

OKAY. Entonces, por un segundo, imagínense todas las capas entre mí haciendo doble clic en Mi PC y realmente hablando a través de controladores al CD-ROM. Ahora imagina que cada capa es ... más rápida ...

Verá, detrás de todo esto hay miles de programadores felices porque su código es "más legible". Eso es genial. Estoy feliz por ti. Pero desde la perspectiva del usuario, simplemente apesta (término técnico). Y entonces duermes bien por la noche diciéndote que hiciste lo correcto al asegurarte de que el código sea más legible y, sin embargo, más lento. Incluso un poco más lento de lo que puede ser. Y así miles de desarrolladores hacen esto, y terminamos esperando nuestras PC por tu culpa. En mi opinión, no eres digno. No digo que tus primeras líneas deban ser las mejores.

Aquí está mi enfoque: Primero, haz que funcione, luego hazlo más rápido. Apunte siempre a escribir código eficiente y si tiene que sacrificar la legibilidad, complételo con comentarios. No sacrificaré la eficiencia para que algún programador mediocre pueda mantenerla. Sin embargo, explicaré mi código, pero si eso no es suficiente, lo siento, eres simplemente incompetente para trabajar aquí. Porque aquí, escribimos código que es rápido y legible, y aunque hay un equilibrio, el código legible puede explicarse mientras que la ineficiencia es simplemente inaceptable.

Esta pregunta a menudo me viene a la mente cuando se discuten las entrevistas en la oficina. Hace muchos años, cuando me gradué, me hicieron la pregunta "¿Crees que el código es autodocumentado?". Ahora, debía responder a esta pregunta como programador y, en lo que respecta al entrevistador, era una pregunta en blanco y negro, por lo que no había término medio. El proceso debería sobrevivir a la actividad individual, ya que las personas irán y vendrán más que animadas y usted querrá tener nuevos comienzos listos lo antes posible, y cuanto más fácil sea leer el código, más rápido será comprender lo que está sucediendo.

Hace un tiempo leí un libro que era bastante bueno, llamado Desarrollo impulsado por dominio : Diseño impulsado por dominio: Abordar la complejidad en el corazón del software. Es cierto que es una lectura un poco seca al principio, pero el material está bien presentado. Esto muestra un buen enfoque que conduce a sistemas que se documentan bien. El lenguaje es el medio para comunicar su solución, de modo que cuanto más clara sea la solución, más fácil será adaptarla si el rendimiento se convierte en un factor crítico. Esa es mi creencia y parece haber funcionado bien para mí.

Raramente valdría la pena el ROI al hacer que el código se ejecute más rápido a expensas de la legibilidad. Las computadoras modernas funcionan tan rápido que dudo que haya un escenario en el que quieras esto. Si una computadora está ejecutando el código, ese código debe mantenerse.

Para ese fin, encuentro la legibilidad muy importante. Por supuesto, como se dijo en numerosas ocasiones, solo porque el código sea legible no necesariamente significa que sea más lento.

Un buen ejemplo es un nombre de variable: $a

Que es $a?? Esto está fuera de contexto, por lo que no puede responder eso, pero ¿alguna vez se encontró con esto en el código real? Ahora suponga que alguien escribió $file_handle, ¿qué es eso? Está claro incluso fuera de contexto. La longitud del nombre de la variable hace una diferencia insignificante para la computadora.

Creo que hay sentido común aquí.

Algunas aplicaciones pueden justificar un atajo de cambio de bits que no todos entenderán, pero creo que en algún momento hay rendimientos disminuidos y encontrar un escenario es raro *.

* esto depende de la industria y otras cosas similares. Estoy mirando esto desde la perspectiva del desarrollador de software empresarial (Business Information Systems).

Para ver esto desde otra perspectiva (pero no para divagar), trabajo en una empresa que hace SAAS. Cuando un sitio se cae, tenemos que arreglarlo muy, muy rápido, por lo general, alguien más está arreglando el código de otro desarrollador.

Yo mucho más bien alguien haga algo muy ineficiente, pero fácil de leer que para que sea de lujo y "rápida". Nuestros servidores web son de vanguardia y no es necesario entregar una solicitud en millonésimas de segundo. No tenemos problemas de carga.

Entonces, en la práctica, creo que es más probable que te hagas daño a ti mismo oa otros ... (Prefiero recuperar mi fin de semana).

Para la mayoría de los casos, la respuesta es "Confíe en su compilador para hacer su trabajo" y escriba un código que sea legible. Esto implica que el código está estructurado lógicamente (es decir, sin espagueti) y autodocumentado (es decir, nombres suficientemente claros de variables, funciones, etc.). Complemente el código que no está auto documentado con comentarios significativos. No comente por comentar, es decir,

x++; // Add one to x

Más bien, comente para usted, el lector, en 6 meses o 12 meses o algún otro tiempo suficientemente largo. Adopte un estándar de codificación y sígalo.

El código limpio es un código rápido. Claramente escrito, el código fácil de mantener tiende a ser más rápido porque es un indicador de que el programador entendió la tarea en cuestión y refactorizó el código para su propósito principal.

Además, los compiladores modernos optimizan las instrucciones de manera muy efectiva. La cantidad de líneas de código que escribe para hacer algo y lo que crea el compilador en términos de instrucciones no están necesariamente relacionadas. Lea los compiladores para comprender por qué ese es el caso.

Cuando estoy trabajando en algo basado en el rendimiento, como los gráficos, ocasionalmente sacrificaré la legibilidad / mantenibilidad cuando estoy haciendo cosas como el procesamiento de imágenes cuando estoy trabajando en los algoritmos anidados más profundos donde las pequeñas optimizaciones pueden tener un efecto importante. E incluso entonces solo lo hago después de crear un perfil para garantizar que los cambios realmente aceleren las cosas. No puedo decir cuántas veces he intentado 'optimizaciones' codificadas a mano solo para descubrir que en realidad ralentizó la aplicación debido a la forma en que el compilador optimizó el código escrito a mano.

¡La legibilidad es una excusa para programadores incompetentes y perezosos (en realidad, lo mismo se aplica a la "simplicidad" cuando se usa como argumento para defender un algoritmo / diseño malo)!

¡Para cada problema, debe luchar por la solución óptima! El hecho de que las computadoras de hoy sean rápidas no es excusa para desperdiciar los ciclos de CPU. La única restricción debería ser "tiempo de entrega". Tenga en cuenta que "solución óptima" aquí significa la que USTED puede encontrar (no todos podemos encontrar la mejor solución; o tenemos la habilidad / conocimiento para implementarlas).

Como alguien más mencionó si hay aspectos "difíciles de entender" de una solución, para eso están los comentarios. El orden "correcto, legible, rápido" (o algo así), que alguien más mencionó es solo una pérdida de tiempo.

Me cuesta mucho creer que hay programadores por ahí, que cuando se les presenta un problema piensan en las líneas "... esto debe hacerse así, pero haré de esa manera que sea menos eficiente pero más legible / mantenible y otros tipos de basura ... ". La falacia de esto es que el próximo desarrollador (al ver las ineficiencias) probablemente modificará el código y el siguiente hará lo mismo y así sucesivamente ... El resultado final es que después de algunas versiones, el código se convertirá en lo que el original El desarrollador debería haber escrito en primer lugar. La única excusa para el desarrollador original es a. él / ella no lo pensó (lo suficientemente justo) y (como se mencionó anteriormente) b. limitaciones de tiempo y recursos.

si la disminución de la legibilidad ayuda al rendimiento / optimización del código (como en swfobject y otras bibliotecas js) es una razón para seguir escribiendo código bien formateado y claramente legible y convertirlo en ilegible / optimizado como parte del proceso de "compilación" / lanzamiento.