En una entrevista que TED hizo en 2016 a Linus Torvalds, este habló sobre lo que él considera buen gusto en programación. Como ejemplo, presenta dos implementaciones de eliminación de elementos en listas simplemente enlazadas (singly linked lists). Para eliminar el primer elemento de una lista, una de las implementaciones requiere un caso especial, la otra no. Linus, obviamente, prefiere la opción que no contempla casos especiales.
#9:
#6 780 megas ocupa el código fuente del proyecto web en que trabajo. Chorrocientas librerías en javascript de las que sólo usamos un puñado de funciones, que ni siquiera llevaría demasiado tiempo desarrollarlas nosotros mismos. Son otros tiempos.
#6 780 megas ocupa el código fuente del proyecto web en que trabajo. Chorrocientas librerías en javascript de las que sólo usamos un puñado de funciones, que ni siquiera llevaría demasiado tiempo desarrollarlas nosotros mismos. Son otros tiempos.
Ah, los viejos tiempos en los que al salir de tu aplicación al MS-DOS te daba un error de memoria porque la habías cagado con los punteros.
No tener que gestionar manualmente la memoria ha sido uno de los grandes avances para la programación. Antes tenías que dejarte los ojos y los sesos buscando dónde porras no habías liberado bien.
#4 Eso es... aun hay que saber del tema si hay que optimizar (y es algo que ultimamente veo que falta en las nuevas incorporaciones, manejan framework y ya).
#2 Eran los buenos tiempos, cuando un desarrollador daba valor a la memoria y la usaba con cabeza, no como ahora donde un "hello world" ocupa 512mb en RAM
He leído el texto y me parece que efectivamente la segunda es más ingeniosa y elegante, pero menos legible.
Yo, que tiendo a ser zote, prefiero el código que pueda entenderse de un primer vistazo, aunque haya que usar algún caso particular. Para mí, la solución elegante en este caso requiere si tienes que revisar el código meses después, tengas que pensar por qué hiciste eso.
#1 "si tienes que revisar el código meses después...." eso va a dar igual, siempre siempre.., te preguntarás .., cómo llegaste a esa solución.
Linus, tiene razón, cuanto más general sea el código mejor, porque podrá sacarte de más apuros en más ocasiones, reutilizando esa estrategia probada más veces en más escenarios.
Además cuantas menos excepciones tengas en el código menos puntos de ruptura y más liviano el código que se ejecuta, que a fin de cuentas es.., es lo que importa. Quiero que mi windows, linux, office, ....etc, funcionen, lo que piense el programador es irrelevante, si puede o no puede mantenerlo 4 meses después...
#3 Que sea legible o más tosco no quiere decir que funcione peor.
Yo sólo hablo desde mi punto de vista de zote. Leer código muy pulido como este cuesta más trabajo de análisis, y a veces modificarlo es más complicado que uno obvio que quizá va a ocupar sólo unos bytes más.
En este caso concreto se trata de una operación muy habitual en C con cadenas de punteros. La primera solución es obvia para cualquier desarrollador en C. La segunda requiere una explicación, como demuestra el artículo.
Claro que no me comparo con Torvalds, que supongo que será un monstruo en C. Sólo digo que personalmente el código legible facilita mucho el trabajo y se cometen menos errores.
#1#5 El problema es que la legibilidad depende de quien lee, no de quien escribe. Lo que a ti te puede parecer obvio, a otros no, y viceversa. Y depende también especialmente de los conocimientos que se tengan del lenguaje en cuestión (y también estoy de acuerdo con #3 en este punto).
En este caso basta con tener conocimientos normales de C para entenderlo (no así para desarrollarlo, ese es otro tema), por lo que yo siempre iré por la solución óptima en lugar de la más “legible” por las razones antes indicadas.
#8 En cero, por supuesto, porque un array (en C) no es más que una suma de un número (puntero al primero elemento) más un offset, que es cero, evidentemente, para el primer elemento
Otra cosa son los arrays en Pascal, en D, en Java, en Javascript… que aunque también empiezan en cero, su implementación es totalmente diferente.
#1 Nunca hay que sacrificar la legibilidad. Un código poco legible sólo lleva a cometer más errores, a tardar más en modificarlo, y a necesitar programadores muy experimentados
Sólo en casos extremos que afecten al rendimiento sacrifico la legibilidad.
#1 Cuando el código es general, como en este caso, mejor que sea altamente elegante, y en realidad altamente eficiente incluso a expensas de la legibilidad, y lo cubres con unit tests.
#10 Yo creo que es una cuestión de preferencias, estilo y de inteligencia (personalmente ya digo que me cuesta trabajo leer ese código, y uno evidente no)
Comentarios
#6 780 megas ocupa el código fuente del proyecto web en que trabajo. Chorrocientas librerías en javascript de las que sólo usamos un puñado de funciones, que ni siquiera llevaría demasiado tiempo desarrollarlas nosotros mismos. Son otros tiempos.
#9 el veneno de los frameworks.....
#11 Ya ves...abomino de Ionic por ejemplo, porque lleva una cantidad de mierda que flipas...
#14 No hace mucho me pasan un proyecto en ReactJS par mostrara una tabla y pesaba casi 100 megas.
Y preguntas pa que todo eso y te dicen, no se, me lo bajé así.....
Los quise matar.
#9 ¡Que horror! Transpilo solo de pensarlo
Ah, los viejos tiempos en los que al salir de tu aplicación al MS-DOS te daba un error de memoria porque la habías cagado con los punteros.
No tener que gestionar manualmente la memoria ha sido uno de los grandes avances para la programación. Antes tenías que dejarte los ojos y los sesos buscando dónde porras no habías liberado bien.
#2 si necesitas hacer algo que vaya realmente rápido todavía es necesario. Pero sí, nos ha mejorado la existencia.
#4 Eso es... aun hay que saber del tema si hay que optimizar (y es algo que ultimamente veo que falta en las nuevas incorporaciones, manejan framework y ya).
#2 Eran los buenos tiempos, cuando un desarrollador daba valor a la memoria y la usaba con cabeza, no como ahora donde un "hello world" ocupa 512mb en RAM
He leído el texto y me parece que efectivamente la segunda es más ingeniosa y elegante, pero menos legible.
Yo, que tiendo a ser zote, prefiero el código que pueda entenderse de un primer vistazo, aunque haya que usar algún caso particular. Para mí, la solución elegante en este caso requiere si tienes que revisar el código meses después, tengas que pensar por qué hiciste eso.
#1 "si tienes que revisar el código meses después...." eso va a dar igual, siempre siempre.., te preguntarás .., cómo llegaste a esa solución.
Linus, tiene razón, cuanto más general sea el código mejor, porque podrá sacarte de más apuros en más ocasiones, reutilizando esa estrategia probada más veces en más escenarios.
Además cuantas menos excepciones tengas en el código menos puntos de ruptura y más liviano el código que se ejecuta, que a fin de cuentas es.., es lo que importa. Quiero que mi windows, linux, office, ....etc, funcionen, lo que piense el programador es irrelevante, si puede o no puede mantenerlo 4 meses después...
#3 Que sea legible o más tosco no quiere decir que funcione peor.
Yo sólo hablo desde mi punto de vista de zote. Leer código muy pulido como este cuesta más trabajo de análisis, y a veces modificarlo es más complicado que uno obvio que quizá va a ocupar sólo unos bytes más.
En este caso concreto se trata de una operación muy habitual en C con cadenas de punteros. La primera solución es obvia para cualquier desarrollador en C. La segunda requiere una explicación, como demuestra el artículo.
Claro que no me comparo con Torvalds, que supongo que será un monstruo en C. Sólo digo que personalmente el código legible facilita mucho el trabajo y se cometen menos errores.
#1 #5 El problema es que la legibilidad depende de quien lee, no de quien escribe. Lo que a ti te puede parecer obvio, a otros no, y viceversa. Y depende también especialmente de los conocimientos que se tengan del lenguaje en cuestión (y también estoy de acuerdo con #3 en este punto).
En este caso basta con tener conocimientos normales de C para entenderlo (no así para desarrollarlo, ese es otro tema), por lo que yo siempre iré por la solución óptima en lugar de la más “legible” por las razones antes indicadas.
#8 En cero, por supuesto, porque un array (en C) no es más que una suma de un número (puntero al primero elemento) más un offset, que es cero, evidentemente, para el primer elemento
Otra cosa son los arrays en Pascal, en D, en Java, en Javascript… que aunque también empiezan en cero, su implementación es totalmente diferente.
#1 Nunca hay que sacrificar la legibilidad. Un código poco legible sólo lleva a cometer más errores, a tardar más en modificarlo, y a necesitar programadores muy experimentados
Sólo en casos extremos que afecten al rendimiento sacrifico la legibilidad.
#1 Cuando el código es general, como en este caso, mejor que sea altamente elegante, y en realidad altamente eficiente incluso a expensas de la legibilidad, y lo cubres con unit tests.
#10 Yo creo que es una cuestión de preferencias, estilo y de inteligencia (personalmente ya digo que me cuesta trabajo leer ese código, y uno evidente no)
#10 y con buenos comentarios
Venga, los arrays ¿empezando en 0 o en 1?