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

37

¿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?

TeaDrinkingGeek
fuente
13
¿Por qué crees que el código con menos líneas es más eficiente? Raramente es el caso con los lenguajes modernos, aunque podría haberse aplicado a los intérpretes BASIC de 8 bits.
David Thornley
69
Ni la legibilidad ni el rendimiento se miden en líneas.
En muy pocos casos, sacrificaría la legibilidad por la velocidad, pero muy raramente. El código incrustado que ejecuta maquinaria de alta velocidad es un caso. Para la mayoría del software, la legibilidad es mucho más importante.
Jim C
1
Respuesta relacionada: programmers.stackexchange.com/questions/39047/…
Nicole
Siempre favorecería la legibilidad hasta que el rendimiento se convierta en un problema. Entonces comenzaría a preocuparme por eso.
Pete

Respuestas:

62

"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.

revs Inaimathi
fuente
3
+1 Hay rendimientos decrecientes, pero también he descubierto que un programa corto generalmente es más fácil de leer que uno largo.
Michael K
23
Desafortunadamente, he encontrado que un código único de intercambio de datos que no se elimina de inmediato se convierte en código a largo plazo, con demasiada frecuencia. Siempre espere que las cosas cuelguen, se reutilicen y se expandan, a menos que elimine el código.
Vatine
1
Estoy de acuerdo con Vatine. ¿Alguna vez volviste y trataste de descubrir algo que alguna vez pensaste que era "perfectamente claro" cuando?
Wonko the Sane
+ 1 para SICP. Impresionante libro.
Jason Yeo
30

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.

Adam Lear
fuente
44
Creo que podría haber una diferencia entre "código legible" y "conocer el algoritmo". Supongo que cualquier código, si no conoce el algoritmo, será más o menos difícil de leer y comprender. Por ejemplo, en el caso de FISR mencionado, el código simple en realidad es bastante legible, pero el algoritmo no está documentado. Si conocieras el algoritmo FISR, ¿cuánto más legible podrías escribir el código? Una pregunta estrechamente relacionada podría ser: ¿cuándo elegir un algoritmo elegante?
Maglob
@Maglob Me refería específicamente al uso de 0x5f3759df. Sin tener en cuenta el rendimiento, podría utilizar implementar el algoritmo ISR utilizando la división regular, lo que probablemente sería más legible para una persona menos familiarizada con los componentes internos de la computadora.
Adam Lear
3
Esto quizás podría expresarse como "A veces es correcto reemplazar un algoritmo ingenuo expresado en 5 líneas de comentarios y 20 líneas de código con un algoritmo sofisticado expresado en 15 líneas de comentarios y 5 líneas de código".
Peter Taylor
1
Tenga en cuenta también que la ofuscación horriblemente obtusa para un desarrollador en un dominio puede ser un modismo perfectamente aceptable para un desarrollador en otro dominio. Si bien la constante mágica en el algoritmo ISR parece haber empujado un poco los límites, supongo que en ese momento ese tipo de pirateo a nivel de bit para aproximaciones de punto flotante era bastante común en el desarrollo del juego en ese momento. Del mismo modo, al trabajar en sistemas embebidos, hay muchas tonterías que son idiomáticas pero que pueden parecer demasiado obtusas para un desarrollador de aplicaciones.
Cercerilla
una de las maravillas de Internet -> al implementar un algoritmo complejo (ejemplo: distancia levenshtein con la optimización diagonal ... solo estoy trabajando en ello;)), uno puede hacer referencia a un artículo o incluso copiar el artículo en la documentación del proyecto y poner una referencia en el código. De esta manera, las personas que conocen los algoritmos solo siguen los comentarios que explican las pruebas / optimizaciones específicas, mientras que los principiantes primero tendrán que leer sobre el algoritmo y luego volver a la implementación.
Matthieu M.
22

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.

ChrisF
fuente
22

Lo cité antes , y lo citaré nuevamente:

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

En ese orden.

Wes Dyer

revs Benjol
fuente
2
+1 Me desplacé hacia abajo rápidamente para asegurarme de que esta cita estuviera incluida. Ahora no tengo que poner una respuesta. :-)
RationalGeek
9

¿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

usuario10197
fuente
6

¿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.

revs Klaim
fuente
4

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.

S.Lott
fuente
2

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.

rjzii
fuente
2

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.

Maltrap
fuente
"Está bien. Así que por un segundo imagina que todas las capas entre mí hacen doble clic en Mi PC y en realidad están hablando a través de controladores al CD-ROM. Ahora imagina que cada capa fue ... más rápida ..." instantánea para mí con 2 DVD Drives
Rangoric
Una palabra: Actualización
jmort253
2
Chicos, trabajen conmigo aquí, es una ilustración ...
Maltrap
@Rangoric, eso es lo que llamo usar los avances tecnológicos como una muleta en lugar de un regalo. Funciona bien para la industria si puede persuadir a los usuarios para que abran sus billeteras con más frecuencia.
Jonathan Neufeld
Creo que el impacto energético del código inflado exige más escrutinio y medidas más estrictas. La gestión ambiental es deficiente aquí. Teniendo en cuenta que estamos viendo aumentos de 4 grados en las temperaturas globales ahora, ¿por qué la complejidad computacional queda en segundo plano?
Jonathan Neufeld
2

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í.

Desolate Planet
fuente
1

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).

Frank V
fuente
1

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.

Retroceso1986
fuente
+1 para "Confía en tu compilador para hacer su trabajo". Ese es mi nuevo comentario de Skype.
jmort253
0

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.

Gran maestro B
fuente
-1

¡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.

alguien
fuente
-2

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.

www0z0k
fuente