Código limpio, cómo programar con respeto

En esta charla trataremos los principales puntos a tener en cuenta para crear código limpio. El principal objetivo será el de crear conciencia, y dar una breve guía práctica con ejemplos sobre lo que se puede considerar un código limpio. Un código cuya principal virtud sea el respeto y la profesionalidad.

Las bases de la charla parten de los contenidos del libro "Clean Code" de Robert C. Martin (Uncle Bob), sobre todo sus apartados iniciales que son asequibles para programadores de cualquier nivel de experiencia, y también intentaremos abrir un debate que nos permita construir cada uno nuestra propia opinión sobre cada apartado.

Charla para dotnetmalaga impartida el 14 de Septiembre de 2017.

https://www.meetup.com/es-ES/dotnetMALAGA/events/242742139/

Transcript

1. código limpio Cómo programar con respeto Francisco M. González
2. Bienvenidos Francisco M. González Padre Coleccionista de Cómics Malagueño Construyendo cosas en Ciklum @fmgonzalez76
6. Clean Code, Robert C. Martin
7. Indice - ¿Qué es código limpio? - Naming - Functions - Comments - Code Style
10. About Clean Code Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler
11. el código es para ser leído
14. ¿Qué NO es código limpio? - No describe lo que hace - Es difícil de entender - Es difícil de modificar
15. VS.
16. hack horrible vs. solución temporal Hack horrible que no es mío Hack horrible que es mío
17. mal organizado vs. arquitectura compleja Código mal organizado que no es mío Código mal organizado que es mío
18. Necesita un refactor vs. solución limpia Funciona pero no lo entiendo Funciona y lo entiendo
20. ¿Cómo es el buen Código? - Legible - Robusto - Reutilizable - Eficiente
21. ¿Cómo es el Código Limpio? - Elegante - Eficiente - Simple y directo - Legible como prosa - Cuidado - Pequeño
22. ¿Cómo es el Código Limpio? - Elegante - Eficiente - Simple y directo - Legible como prosa - Cuidado - Pequeño - Legible - Robusto - Reutilizable - Eficiente
23. About respect Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods
26. excusas - Hay que ir rápido - Planificaciones vertiginosas - Gestores intransigentes - Presión de los clientes
30. Todo son nombres - Clases - Namespaces - Funciones - Variables - Ficheros - Directorios - ...
31. declara intención // elapsed time in days int d; int elapsedTimeInDays; int fileAgeInDays; int daysSinceCreation;
32. declara intención /** Useful range constant */ CONST INCLUDE_NONE = 0; CONST INCLUDE_FIRST = 1; CONST INCLUDE_SECOND = 2; CONST INCLUDE_BOTH = 3;
33. Evita la desinformación public function getCountry(); public function getCountryName(); Dice lo que hace y hace lo que dice
34. Nombres pronunciables y que se puedan buscar getXYZ(); genDDMMYY(); m_qdox; qty_pass_m; qty_pass_s;
35. Evita codificaciones y sufijos de tipo IAccount (interface) pWriter (pointer) bActive (boolean) eStatus (enum) m_size (member attribute) Mejor usa solo nombres
36. Nombres de clase Nombres, no verbos Evitar sufijos Data o Info Métodos: - Verbos - Accessors: get - Mutators: set - Predicates: is / has
37. La longitud de las variables acorde al ámbito foreach ($items as $item) { $item->doSomething(); }
38. La longitud de las variables acorde al ámbito try { ... } catch (Exception $e) { log($e->getMessage()); }
39. La longitud de los métodos acorde al ámbito Private: - tryProcessInstructions() - closeServiceInSeparateThread() Public: - open() - close() - save()
40. Atención con la herencia - La herencia tiende a alargar los nombres, añadiendo adjetivos. Account ← SavingAccount
41. naming. Resumen - Elige los nombres cuidadosamente - Comunican intención - Evita la desinformación - Pronunciables - Busca la prosa - Recuerda la regla del ámbito
42. f ( )
43. dos reglas básicas para las funciones 1. Hazlas pequeñas
44. dos reglas básicas para las funciones 1. Hazlas pequeñas 2. Hazlas más pequeñas
45. Do One Thing - Sólo una cosa - Hacerla bien - Sólo esa cosa
46. Las funciones deben... - Hacer algo (cambiar el estado de un objeto). Una orden - Devolver algo. Una consulta No ambas. Recordad: Do one thing
47. extrae hasta que no puedas más - Si puedes extraer parte de tu función a otra función, DEBES hacerlo. - Por definición está haciendo más de una cosa - Debes extraer hasta que no puedas más
48. No mezclar niveles de abstracción // Alto nivel de abstracción getHtml(); // Nivel intermedio String htmlPageSection = SectionParser.render(section); // Nivel bajo outputHtml.append(“\n”);
49. step down rule - Leerse como un libro - Definir conceptos de arriba a abajo - Evitar los saltos por el fichero para entender la prosa
50. nombres descriptivos - No temas usar nombres largos - Un nombre largo y descriptivo es mejor que uno corto y confuso - Prueba con varios, no temas renombrarlos hasta que te parezcan adecuados
51. Argumentos - Niladic. Ideal - Monadic o Dyadic - Triadic. Evitar si es posible - Polyadic. Requieren de una clara justificación y después NO usarlos de todos modos. - Flag arguments
52. Devolver las transformaciones void transform(StringBuffer out); StringBuffer transform(StringBuffer in);
53. salidas - No devuelvas varias salidas - Mejor lanzar excepciones que códigos de error - Extrae los bloques de try/catch El tratamiento de errores ya es one thing
54. Functions. Resumen - Pequeñas - Más pequeñas - Nombres descriptivos - Hacen una sola cosa. Órdenes y consultas. - Extrae hasta que no puedas más
55. /** * comments */
56. los comentarios son errores - Los ignoramos al leer - Son señal de mal naming - El único comentario bueno es el que no escribes - Deben ser raros y destacados en el IDE - Engañosos y fuente de errores
57. ABOUT COMMENTS Incorrect documentation is often worse than no documentation. - Bertrand Meyer
58. Buenos comentarios - Legales (no hay más remedio) - Formato (como una expresión regular) // format matched kk:mm:ss EEE, MMM dd, yyyy string pattern = “\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*”
59. algunos ejemplos de comentarios /* The logger class */ protected $logger; /* The version */ public $version;
60. algunos ejemplos de comentarios /** * @param $item The item to be added * @param $position The position to be added */ public function addItem($item, $position = 0);
61. algunos ejemplos de comentarios /** * 11/12/2010 - Added the colour feature * 03/02/2011 - removed deprecated function * 07/02/2011 - Fixed bug in addPoints * …
62. algunos ejemplos de comentarios /** Added by Franci */
63. algunos ejemplos de comentarios // ======================== // = INSTANCE VARIABLES = // ========================
64. algunos ejemplos de comentarios if (firstName.equals(monthName)) { return validMonthName; } // end if
65. Comentarios. Resumen - No los uses - Puedes hacerlo mejor
68. ¿Por qué usar un estilo de código? - El estilo de código persiste más que el código en sí - Facilita la modificación y la refactorización - Es más legible - Es un acuerdo de equipo - Es una herramienta de comunicación
69. aumenta la dadilibigel - Aumenta la legibilidad - Aumenta la confianza - Te sientes más cómodo - Se pierde la sensación de posesión del código
70. Elige tu estilo de código (como un equipo) namespace Foo; public class Bar { public function __construct() { … } } namespace Foo; public class Bar { public function __construct() { … } }
71. Elige tu estilo de código (como un equipo) namespace Foo; public class Bar { private string $title = ‘title’; private int $code = 0; ... } namespace Foo; public class Bar { private string $title = ‘title’; private int $code = 0; ... }
72. estándares - PHP: PSR-1, PSR-2, Zend, Symfony, PEAR, Wordpress, Drupal,... - Javascript: airbnb, es6,... - .NET: Microsoft
73. Herramientas - phpcs, eslint,... - editorconfig - posibilidad de automatizar (IDE, githooks, CI)
74. Code Style. Resumen - Facilita el mantenimiento - Es un acuerdo de equipo - Elige un estándar - Automatiza
78. private bool isValidUserName(string userName) { return hasValidLength(userName) && isAlphaNumeric(userName) && !containsCurseWords(userName) && isUniqueUserName(userName); }
79. Comprueba si tu código es limpio - Haz que tus compañeros lo lean y te den su opinión - Vuelve a tu código 3-4 semanas después (cuando lo hayas olvidado) y mira si puedes seguirlo - Si puedes, publica tu código - Enseña tu código a otros programadores cuya opinión respetes
80. Gracias por vuestra atención