[ home ] [ a / jp / h / lain ] [ b / hum ] [ mu / tech / v / vis / x ] [ meta / nexo ]

/tech/ - Tecnología

No rompas las leyes de Isaac Asimov
Nombre
Email
Comentario
Archivo





[]
Adjuntar
Clave (Para eliminar el post.)

  • Archivos soportados: [ jpg, jpeg, png, gif ] , [ ogg, mp3 ] , [ webm ] & [ pdf ].
  • Adjuntos soportados: [ youtube, vimeo, dailymotion, metacafe & vocaroo ].
  • Tamaño máximo total 20MB.



File: 161204302052.jpg (128.54 KB, 628x768) ImgOpsiqdb

128.54 KB

No.2528

Según tú, Wai, ¿qué es el código limpio?, ¿cómo lo ejemplificarías?; ¿cómo sabes si es ese código limpio?; ¿acaso la simpleza de un código en un algoritmo significa "código limpio"?
>>

No.2529

- Fácil de leer
- Fácil de entender
- Fácil de extender
>>

No.2536

>>2529
Esto es muy genérico, para mi el código legible y ordenado DEBE tener estas especificaciones:
- 80 caracteres por línea como máximo
- no usar simbolitos como "{}()" innecesariamente
- siempre separar literales y variables de otros símbolos con un espacio (ejemplo: i += 5 en lugar de i+=5)
- que haga algo de la forma más simple posible, no es necesario que intentes mostrar cuán "hábil" eres haciendo algo más rebuscado (aka innecesariamente complejo), simplemente haz todo de la forma más simple
- las variables, constantes, métodos y demás deben tener nombres descriptivos/memotécnicos
- no colocar comentarios idiotas en el código, ejemplo "// este código es para esto, lo siento si es muy largo chicos XDDD".
- los comentarios únicamente se han de usar para mencionar QUÉ hace algo, no CÓMO lo hace. Se supone que alguien que sabe programar es capaz mentalmente para saber leer un algoritmo.
- esto sonará tonto, pero las identaciones deben ser consistentes. Hay gente que aún mezcla espacios con tabulaciones y se ve horriblemente mal. Si vas a usar 4 espacios, usa 4 espacios para TODO el proyecto. Si vas a usar tabulaciones de tamaño 8, lo mismo.
- en el caso de C/C++, organizar bien las llaves ("{}") por ejemplo, he visto quienes mezclan identación K&R con estilo BSD, y también se ve mal.
- evitar declarar variables innecesarias, ejemplo:

int resultado = hacer_algo();
if (resultado != OK) {
mostrar_error();
}

en su lugar debería ser:

if (hacer_algo() != OK)
mostrar_error();
>>

No.2537

File: disappointment.png (175.29 KB, 397x399) ImgOpsiqdb

175.29 KB
>>2536
Olvidé otra: No mezclar de forma incoherente snake_case, camelCase y PascalCase. Es horrible, si van a usar pascal para clases por ejemplo, úsenlo para TODAS las clases. Si usan snake para variables, lo mismo.
Esto también es algo estúpido pero mucha gente aún lo hace.
>>

No.2538

>>2536
>>2537
¿Algunos de esos puntos son para el estándar?; ¿has leído The C programming language?
>also
>- siempre separar literales y variables de otros símbolos con un espacio (ejemplo: i += 5 en lugar de i+=5)
Solo por decir: Eso siempre lo he hecho.
>>

No.2539

>>2538
Hablo de una forma generalizada para todos los lenguajes. Soy contribuyente a algunos proyectos libres y normalmente todos piden que sigas esos puntos para que el código sea mantenible, pero luego salgo de ese mundillo y me topo con estudiantes, aficionados o incluso programadores de profesión que escriben código terrible. Personalmente si no estoy seguro de cómo organizar algo para que se vea legible, me baso en las directrices del kernel de Linux porque son bastante consistentes y en general te hacen escribir código mantenible.
>The C programming language
Solo leí ese libro a medias, de hecho de por ese libro adopté K&R para ordenar las llaves ({}).
>>

No.2540

>>2539
>Soy contribuyente a algunos proyectos libres y normalmente todos piden que sigas esos puntos para que el código sea mantenible
Solo por curiosidad, ¿en qué software has contribuido?


[Post a Reply]
[ ]
[ home ] [ a / jp / h / lain ] [ b / hum ] [ mu / tech / v / vis / x ] [ meta / nexo ]