Programando con claridad [ENG]

El código necesariamente bueno sólo por funcionar. También debe ser fácil de leer, entender y modificar. Necesita claridad, y para lograrlo, tiene que estar bien organizado, con una planificación cuidadosa y una separación adecuada de las ideas que se llevan a cabo antes incluso de abrir el editor. Programar para claridad es algo que separa a los grandes desarrolladores de los meramente bueno, y hay algunos principios básicos que pueden ayudar en ese camino.

[#2 ElPerroDeLosCinco]

Hay personas que programan de una forma tan enrevesada que hasta el compilador les saca un mensaje de: "Sintácticamente es correcto y yo lo compilo, pero no sé qué cojones va a hacer esto, la verdad".

[#12 squanchy]

#2 Yo estoy ahora con frameworks y librerías de javascript. Tu propio código react + redux + lodash a veces tienes que leerlo varias veces para descifrar qué es lo que hace, y piensas "mierda, por qué no pondría un comentario".

[#1 Desactivado]

Muy buen articulo. Gracias
Se lo pasare a uno del curro que siempre que miro su codigo mi medidor WTF se dispara

[#8 chulonsky]

El que no sabe programar, supongo que la mayoría, ésto le importa un pimiento.
Y el que sabe programar, que se dedica a ésto, el artículo es un refrito de principios de la programación orientada a objetos, algún principio SOLID, y algún principio de programación imperativa.

Así que la conclusión es que lo menea programadores amateurs, mucho mas valientes que los carpinteros amateurs, que no los veo yo subiendo a portada tutoriales de cómo agarrar un martillo correctamente.

[#10 sunes]

#8 No soy programadora amateur. Lo meneo porque veo principios básicos en este artículo que ya me gustaría que unos cuantos colegas míos utilizasen al menos una vez en la vida. Todas las cagadas que describe el artículo te las puedes encontrar día sí y día también, y la verdad es que a mi me saca de mis casillas.

Y ni te digo si juntas a programadores "amateurs" (de formación solamente pica-códigos) con la permanente falta de tiempo para entregas, y te salen churros infumables que hay que estar toqueteando cada X meses.

Por eso creo que este meneo merece la pena: a algunos les vendría muy bien imprimírselo y colgarlo al lado de su pantalla, a ver si se les pega algo!

[#14 Desactivado]

Sí, claro ¡con claridad! Para que venga un junior y entienda lo que he escrito. Nada, aquí a programación ofuscada, para que no puedan sacar ni con agua caliente

[#6 Desactivado]

No es que JS de para mucho más...

Para todo lo demás, Clean Code + Refactoring (Fowler)

[#3 chochis]

Hablamos de SOLID y código declarativo a estas alturas?

[#4 Cidwel]

jajjajajaj mira que no dudaba que hablaban de javascript
Cada dia estamos alejando más y más a los backenders haciendo un lenguaje que no se parece en nada a ningún otro, y me parece sexualmente atrayente

[#17 snake94]

#4 Es un claro beef a lennart poettering

[#18 dreierfahrer]

#4 JS es tan old-school.... Es tan.... 2015

Lo que se lleva ahora es kotlin, JS esta pasado de moda.

[#24 maloconocido]

#18 que es muy 2015??

[#13 Mannu]

Perfecto para imprimirlo... y grapárselo en la frente a más de uno.

[#7 Desactivado]

Aquí uno que es un desastre. Intento aprender, pero no paso de nivel aprendiz.

[#5 Desactivado]

js es mal

[#16 Efnauj72]

Cuando te piden que lo tienes que tener para ayer dejas la claridad a un lado y pones tu pequeña cagadita. Y ahí se quedará durante mucho tiempo. Esto ocurre así casi siempre. Hasta el mejor de los programadores necesita tiempo para programar bien.

[#19 angelitoMagno]

#16 Bueno, si estamos hablando de un cambio rápido, la "pequeña cagadita" se hace en menos tiempo.

Pero un proyecto que vaya a necesitar meses de desarrollo se hará de forma más rápida si se hace bien. Al principio tal vez tarde un poco más en arrancar, pero después todo irá más fluido. Entre otras cosas porque irán apareciendo menos "bugs extraños" durante el desarrollo.

[#22 dreierfahrer]

#16 19 Porque una cosa que tenemos que tener clara es que nos pagan por acabar los productos en fechas...

No por hacer TDD o un codigo super limpio....

Es por eso que creo que estas cosas de clean code hay q saberlas BIEN y aplicarlas siempre que sea posible y saber cuando no es posible...

Is very dificult todo esto...

[#25 mr_b]

Es una descripción más o menos completa de los principios SOLID. Nunca está demás recordarlos.

[#20 Acido]

#0

"El código necesariamente bueno sólo por funcionar. "
Frase sin verbo. Lo que luego se entiende que quería decir:
"El código no es necesariamente bueno sólo por funcionar. "


"También debe ser fácil de leer, entender y modificar. Necesita claridad, y para lograrlo, tiene que estar bien organizado, con una planificación cuidadosa y una separación adecuada de las ideas que se llevan a cabo antes incluso de abrir el editor."

Pues no parece que esta entradilla predique con el ejemplo...

" Programar para claridad es algo que separa a los grandes desarrolladores de los meramente bueno, y hay algunos principios básicos que pueden ayudar en ese camino. "

Falta de concordancia de número entre el adjetivo ('bueno', en singular) y el artículo ('los', en plural) y sustantivo ('desarroladores', en plural)

[#21 Desactivado]

¡Que iluso!

[#9 angat]

Uf, para mi muy flojo el artículo, con algunas metáforas muy raras y además algunos ejemplos, como el del getName que también hace un setCookie y un lowecase, para mi no lo ha resuelto correctamente

[#11 sunes]

#9 Pues por ejemplo la de un nene guardando los juguetes en el armario de cualquier manera me parece muy gráfica y fácil de entender
"Have you ever seen a kid clean a room by stuffing everything into the closet? Sure, it works, but it’s impossible to find anything and things that don’t belong together often get placed right next to each other. The same can happen with our code if we don’t strive for a high level of cohesion."

[#23 angat]

#11 #15 Cuando contesté lo hice desde el móvil y no quería extenderme... pero voy a soltar mi opinión sobre ese ejemplo concreto del getFirstName() y la solución propuesta que me parece incorrecta en cierta manera. Para mi la función original tiene dos problemas:

1) Ese setCookie no pinta nada ahí dentro. La solución es sacarlo fuera, eso es obvio, nada que objectar.
2) El toLowerCase(), si está ahí metido, es porque queremos que siempre se muestre el nombre en minúsculas. De acuerdo con que la función getFirstName() no puede hacer eso, pero entonces lo que habría que hacer es separar el método en dos:

- getFirstName() => hace la consulta y devuelve el nombre (como esté el dato)
- formatFirstName() => lo convierte a minúsculas (o le aplica lo que sea para transformarlo)

Y personalmente, yo crearía una función getFirstNameFormatted() que llamase a las dos funciones, una tras otras, de forma que el cambio en el código original fuese mínimo.

A lo que voy es a que la solución que propone, además del cambio en la función, cambiaría los usos de la función, este trozo de código:

var activeFirstName = getFirstName();

Por este otro:

var activeFirstName = getFirstName().toLowerCase()
setCookie("firstName", activeFirstName);

Y ese .toLowerCase(), si hay que meterlo cada vez que queremos el nombre del usuario "formateado", es un error desde mi punto de vista importante, puesto que debería encapsularse en una función para que si en el futuro queremos mostrar siempre el nombre en mayúsculas por decir algo, sea tan fácil como ir a "formatFirstName()" y cambiar el toLowerCase() por un toUpperCase():

var activeFirstName = getFirstNameFormatted()
setCookie("firstName", activeFirstName);

Nada, que me apetecía explicarlo

[#15 Desactivado]

#9 Justamente muchos programadores con muchos años de experiencja de p. orientada a objetos, fallan en cosas como que una funcion no debe modificar datos colateralmente,como la function getFirstName(), o similares.

Terrible cuando hacen una funcion tipo myResult = calcStuff(myObj); y al pasas un objeto ppr referencia que a su vez hace llamadas similares, terminan en algún lado por modificar el objeto o realizar alguna acción colateral. Es terrible.