Qué es Clean Code

Cuando programé mis primeros proyectos solo Dios y yo sabíamos qué estaba haciendo Ahora solo Dios sabe.

Reinaldo Mendoza

x2, luego escribiendo mejor código ya me permito entender que quise hacer, pero al inicio de mi carrera era bastante común que me pasara eso

Billy Torres

jajajja

Sharon Gizela Arana Mendoza

Me paso que trabajé con una chica que copiaba y pegaba una y otra vez los procesos para no hacer funciones y para acabarla, todo se llamaba 'character, characteer, chaaracter, characters' :c

Reinaldo Mendoza

Oh por Dios, si es hasta mas difícil hacer eso, ja

Humberto Guardado

yo estuve allí igualmente, solo que la chica de al lado usaba una microfalda, y no entendía para que servía el botón que decía "SAVE".
Ella tuvo que tomar un curso de inglés antes de meterse a nuevos cursos del tema.

LEONARD CUENCA

Por mi experiencia y duro inicio recomiendo los siguientes tips

Antes de programar tener una hoja en blanco y escribir o garabatear lo que vas a hacer esto ayuda mucho organizar tus ideas
Para mí programar es como jugar o armar bloque de LEGO, esto ayuda a categorizar lo que vas a hacer y ayuda a generar un código limpio por los principios del LEGO cualquier persona puede armar un bloque
Tener buenas bases, NO hablo de ser experto, o ser un supergenio, Hablo de que sepas que piezas de LEGO puedes usar y entender tus habilidades y limitaciones
Por favor usar las reglas básicas de doc documents, tú sabes comentar cada variable que no es obvia, y por favor cada función anexarle una descripción
Mantener un código identado ayuda mucho.
Si es algo complejo de hacer es difícil de explicar así que simplifica

Irving Juárez

Robert C. Martin es un gran autor, yo lo recomiendo bastante, de hecho el fue el que acuño el termino SOLID (el no invento estos principios, solo dio el nombre), para las reglas "universales" que se tienen que seguir al escribir una buena arquitectura de sofware. Sin embargo, la mayoria de sus libros estan enfocados en POO. Por esa razón, se dice que en React no se pueden ocupar los principios SOLID. . En el caso de JS, al ser un lenguage de programación que esta enfocado en funciones y que tiene "first-class functions", muchas veces las autoproclamadas "reglas universales" de programación como SOLID, no aplican. Ya que JS nos permite ejercer otros patrones de diseño que en la mayoria de los lenguages no se pueden hacer. Esto es, debido al feature de "first-class functions" que nos proporciona JS

Joan Manuel Theran Burgos

la frese celebre: antes Dios y yo sabiamos que decia el codigo, ahora solo Dios lo sabe

Humberto Guardado

print("totalmente de acuerdo")

Jose Luis Tovar Fernández

Cada vez que chequeo un proyecto en el que he trabajado, digo lo mismo... Quien escribió esto. Al menos me doy cuenta de todo lo que he aprendido

Kevin Giovanni Cano Blanco

Hace unos años trabajaba con de una forma que funcionaba pero si regresaba al código luego de un par de meses, no lo entendía, es como la frase que dice: "Cuando hice este código solo dios y yo sabíamos que hacía, ahora solo dios sabe" Trabajaba con mucho código espagueti y ni hablar de las malas practicas.

Jose Gabriel Argüello

Que es clean Code?

Es un termino popularizado por Robert C martin en su libro CleanCode: A handbook of Agile Software Craftsmanship en el 2008. El código limpio es aquel que se ha escrito con la intención que otra persona lo entienda

Jasubi Lehem Piñeyro Legaspi

Actualmente, debido a mi falta de experiencia y no teniendo conocimiento de las buenas prácticas, mi equipo tuvo que refactorizar los Test E2E que realice justo cuando nos quedaba 1 semana para integrar a producción. 😅

Luis Rodolfo Reyes

cuando empecé, a veces escribía variables como :

var jjjj = 0, no sé si a alguien más le haya pasado

Eric Daniel Cavanzo

SJSJSJ cuando yo practico (ademas de que hasta ahora empiezo) no se me ocurren nombres, entonces si son codigos cortos directamente pongo ("si", "no", "a", "b") Lo cual si me doy cuenta que esta re mal hecho SJSJ pero no se me ocurrían nombres

Oscar Andrey Martinez Calderon

Me resulta la mejor manera de medir la calidad de nuestro código:

Emerson Cedeño

WTFs/minute ... buena unidad de medida! 🤣

Ikal Esteban Fernández Galván

¡Recuerda!

Es bueno poner comentarios para describir algunas cosas, ¡pero no es bueno usarlos de más! Mejor ponle nombres descriptivos a tus variables o funciones.

Luis Eduardo Payano Villar

Algunos de los principios clave del Clean Code son:

1. Legibilidad

El código debe ser fácil de leer y entender para otros desarrolladores. Esto implica usar nombres descriptivos para variables, métodos y clases, y evitar abreviaturas confusas.
La legibilidad se mejora utilizando una correcta indentación y espaciado, así como comentarios solo donde sea realmente necesario, ya que el código debe ser lo suficientemente claro por sí mismo.

2. Funciones Pequeñas y Concisas

Las funciones deben ser pequeñas y realizar una única tarea bien definida. Es preferible dividir tareas complejas en varias funciones más simples y específicas.
Evitar funciones largas y con múltiples responsabilidades, ya que esto facilita su testeo y reusabilidad.

3. Nombres Significativos

Los nombres de las variables, métodos y clases deben comunicar claramente su propósito. Se debe evitar nombres genéricos como temp o data, a menos que sean apropiados en el contexto.
Un nombre claro y preciso facilita el entendimiento del código sin necesidad de comentarios adicionales.

4. Evitar la Duplicación de Código

La duplicación de código es un síntoma de mala estructura. Se debe extraer funcionalidad repetida en métodos comunes para que sea más fácil de modificar y mantener.

5. Código Auto-Documentado

Un buen código debe ser auto-explicativo. En lugar de añadir comentarios extensivos para explicar el código, se debe escribir el código de tal manera que no necesite explicaciones adicionales.

6. Uso de Excepciones en Lugar de Códigos de Error

En vez de usar códigos de error que requieren lógica adicional para manejarlos, se debe usar excepciones, que permiten separar la lógica de manejo de errores de la lógica principal del programa.

7. Desacoplamiento

El código debe estar diseñado de manera que los módulos, clases o funciones no dependan demasiado unos de otros. Esto permite que los cambios en una parte del sistema no afecten demasiado a otras partes.
Se puede utilizar la inyección de dependencias para reducir el acoplamiento entre componentes.

8. Principio SOLID

Clean Code suele estar asociado con los principios SOLID:
- S: Single Responsibility Principle (Principio de Responsabilidad Única)
- O: Open/Closed Principle (Principio Abierto/Cerrado)
- L: Liskov Substitution Principle (Principio de Sustitución de Liskov)
- I: Interface Segregation Principle (Principio de Segregación de Interfaces)
- D: Dependency Inversion Principle (Principio de Inversión de Dependencias)

9. Pruebas Unitarias

El código limpio está bien probado. Las pruebas unitarias garantizan que cada parte del código funcione correctamente de manera aislada, permitiendo refactorizaciones seguras.

10. Mantener el Código Simple (KISS)

El principio de KISS ("Keep It Simple, Stupid") indica que el código debe ser lo más sencillo posible. La complejidad innecesaria introduce errores y dificulta el mantenimiento del software.

En resumen, el Clean Code se enfoca en la simplicidad, claridad y en la creación de código que sea sostenible y fácil de mejorar.

Maria Alejandra Luna Tito

Hace un año

si me suele pasar que cuando ya voy a terminar la funcionalidad veo cosas que podría mejorar o cosas q no entiendo o se ven algo mal. O cuando lo vuelvo a ver digo pucha como hice esto asi.

Melissa Maya López

Clean code: Es un termino popularizado, para determinar la calidad del código, es decir, es aquel que fue escrito con la intención de que otra persona lo entienda.

Melisa Barrera

El chat gtp: aquí tienes un resumen de los puntos más importantes del libro "Clean Code: A Handbook of Agile Software Craftsmanship" de Robert C. Martin (también conocido como "Uncle Bob"):

Código limpio: El código debe ser simple y directo, fácil de leer y comprender. Debe ser como una buena literatura, donde cada línea de código cuenta una historia.
Nombres significativos: Los nombres de variables, funciones y clases deben ser claros y descriptivos. Deben reflejar su propósito y uso.
Funciones pequeñas: Las funciones deben ser cortas y hacer solo una cosa. Idealmente, una función no debe tener más de 20 líneas de código y debe tener un único nivel de abstracción.
Uso de comentarios: Los comentarios deben ser evitados si es posible. En lugar de comentarios, se debe escribir código autoexplicativo. Los comentarios deben ser utilizados solo para explicar por qué se tomó una decisión particular.
Formateo consistente: El código debe tener un formato consistente que facilite su lectura. Esto incluye el uso adecuado de espacios, sangrías y saltos de línea.
Manejo de errores: El manejo de errores debe ser claro y no debe interrumpir el flujo del código principal. Se deben utilizar excepciones en lugar de códigos de error.
Pruebas unitarias: Escribir pruebas unitarias es esencial para mantener el código limpio. Las pruebas aseguran que el código funciona como se espera y ayudan a prevenir futuros errores.
Estructuras de datos y objetos: Se deben utilizar estructuras de datos y objetos adecuados. Los datos y las operaciones sobre esos datos deben estar encapsulados en clases.
Evitar duplicación: El código duplicado debe ser eliminado. La duplicación hace que el mantenimiento sea más difícil y propenso a errores.
Refactorización: El código debe ser continuamente refactorizado para mejorar su diseño y limpieza. La refactorización es una parte esencial del desarrollo ágil.
Simplicidad: La simplicidad es clave. Se debe evitar la sobreingeniería y mantener el código tan simple como sea posible.
Principios de diseño SOLID: Seguir los principios SOLID para un diseño de código robusto y mantenible:
- S: Single Responsibility Principle (Principio de Responsabilidad Única)
- O: Open/Closed Principle (Principio de Abierto/Cerrado)
- L: Liskov Substitution Principle (Principio de Sustitución de Liskov)
- I: Interface Segregation Principle (Principio de Segregación de Interfaces)
- D: Dependency Inversion Principle (Principio de Inversión de Dependencias)

Estos puntos resumen la filosofía y las prácticas recomendadas por Robert C. Martin para escribir código limpio y mantenible. Aplicar estos principios puede llevar a un código de alta calidad y fácil de mantener a lo largo del tiempo.

Aramis Garcia Guerrero

Nos pasa a todos, a través del tiempo nos vamos dando cuenta todo lo que hemos aprendido, por ejemplo yo implementaba una funcionalidad en 100 líneas, cuando se podía hacer en 30 :/

Eugenio Condori

“El código limpio es aquel que se ha escrito con la intención de que otra persona lo entienda”

José manuel Sanchez Juarez

Yo jaja trabajando en un proyecto legacy pense que seguía el mismo concepto de codificación anterior toca dar mantenimiento no me acuerdo ni como funciona para rematar no tiene test

Jose Ever Muñoz Muñoz