Código Limpio • Juan's blog

01

Dios está en los detalles

02

Un fragmento de código debe estar donde esperamos encontrarlo; en caso contrario, refactorice hasta conseguirlo

03

Crear código legible es tan importante como crear código ejecutable

04

El poeta francés Paul Valery afirma que un poema no se acaba nunca y que tiene que retocarse continuamente, y que dejar de trabajar en el poema es señal de abandono

05

la abstracción es el mal. El código es el remedio al mal y el código limpio puede que sea divino

06

Está leyendo este libro por dos motivos. Por un lado, es programador. Por otro, quiere ser mejor programador. Perfecto. Necesitamos mejores programadores.

07

Después es igual a nunca.

08

Seguramente piense que, si no hace lo que su jefe le dice, le despedirán. Es improbable. Muchos jefes sólo quieren la verdad, aunque lo disimulen. Muchos quieren código correcto, aunque estén obsesionados con los objetivos. Pueden defender apasionadamente los objetivos y los requisitos, pero es su trabajo. El nuestro es defender el código con la misma intensidad.

09

un programador que cree código limpio es un artista que puede transformar un lienzo en blanco en un sistema de código elegante

10

Grady mantiene las mismas ideas que Bjarne, pero adopta una perspectiva de legibilidad. Me gusta especialmente que el código limpio se pueda leer como un texto bien escrito. Piense en un buen libro. Recordará que las palabras desaparecen y se sustituyen por imágenes, como ver una película. Mejor todavía. Es ver los caracteres, escuchar los sonidos, experimentar las sensaciones.

11

Como una buena novela, el código limpio debe mostrar de forma clara el suspense del problema que hay que resolver.

12

El código limpio se puede leer y mejorar por parte de un programador que no sea su autor original

13

el código limpio facilita las labores de mejora de otros.

14

El código limpio siempre parece que ha sido escrito por alguien a quien le importa.

15

Dejar el campamento más limpio de lo que se ha encontrado

16

La longitud de un nombre debe corresponderse al tamaño de su ámbito

17

¿Qué nombres debe asignar? ¿IShapeFactory y ShapeFactory? Prefiero las interfaces sin adornos. La I inicial, tan habitual en los archivos de legado actuales es, en el mejor de los casos, una distracción, y en el peor, un exceso de información. No quiero que mis usuarios sepan que se trata de una interfaz, solamente que se trata de ShapeFactory. Si tengo que codificar la interfaz o la implementación, opto por ésta última. Es mejor usar ShapeFactoryImp o incluso CShapeFactory, que codificar la interfaz.

18

Una diferencia entre un programador inteligente y un programador profesional es que este último sabe que la claridad es lo que importa. Los profesionales usan sus poderes para hacer el bien y crean código que otros puedan entender.

19

Queremos usar un modelo en el que el autor sea el responsable de transmitir el significado, no un modelo académico que exija investigar el significado mostrado.

20

La maestría se consigue de dos formas: conocimientos y trabajo.

21

Debe adquirir el conocimiento de los principios, patrones, prácticas y heurística propios de un maestro, y dominar dichos conocimientos a través de la práctica.

22

Si ha experimentado alguna fase de esta historia, ya sabrá que dedicar tiempo a que el código sea correcto no sólo es rentable, es una cuestión de supervivencia profesional.

23

Afirma que el código atractivo hace que el lenguaje parezca creado para el problema. Por tanto, somos responsables de que el lenguaje parezca sencillo. No es el lenguaje el que hace que los programas parezcan sencillos, sino el programador que consigue que el lenguaje lo parezca.

24

En realidad, la proporción entre tiempo dedicado a leer frente a tiempo dedicado a escribir es de más de 10:1. Constantemente tenemos que leer código antiguo como parte del esfuerzo de crear código nuevo

25

Es un problema de formación más que técnico, empresarial o administrativo. Como resultado, mucha gente del sector no aprende a hacerlo bien.

26

Las funciones deben tener una longitud aproximada de 20 líneas.

27

las funciones no deben tener un tamaño excesivo que albergue estructuras anidadas. Por tanto, el nivel de sangrado de una función no debe ser mayor de uno o dos. Evidentemente, de esta forma las funciones son más fáciles de leer y entender.

28

LAS FUNCIONES SÓLO DEBEN HACER UNA COSA. DEBEN HACERLO BIEN Y DEBE SER LO ÚNICO QUE HAGAN.

29

Los argumentos son todavía más complicados desde un punto de vista de pruebas. Imagine la dificultad de crear todos los casos de prueba para garantizar el funcionamiento de las distintas combinaciones de argumentos.

30

Las partes que ignoramos son las que esconden los errores

31

Objeto de argumento Cuando una función parece necesitar dos o más argumentos, es probable que alguno de ellos se incluya en una clase propia. Fíjese en la diferencia entre las dos siguientes declaraciones: Circle makeCircle (double x, double y, double radius); Circle makeCircle(Point center, double radius); La reducción del número de argumentos mediante la creación de objetos puede parecer una trampa pero no lo es. Cuando se pasan grupos de variables de forma conjunta, como x e y en el ejemplo anterior, es probable que formen parte de un concepto que se merece un nombre propio.

32

Éste es un ejemplo de palabra clave como nombre de función. Con este formato codificamos los nombres de los argumentos en el nombre de la función. Por ejemplo, assertEquals se podría haber escrito como assertExpectedEqualsActual(expected, actual), lo que mitiga el problema de tener que recordar el orden de los argumentos.

33

El efecto secundario es la invocación de Session.initialize(). La función checkPassword, por su nombre, afirma comprobar la contraseña. El nombre no implica que inicialice la sesión