Você está na página 1de 2

Resumen de sugerencias del libro Cdigo sin Errores (Writing Solid Code)

Captulo 1 Un compilador imaginario


Active todas las opciones de advertencias (warnings) del compilador.
Use herramientas que tiene a su alcance que le permita encontrar errores.

Captulo 2 - Valide su propio cdigo


Mantener versiones de depuracin y de produccin sobre todo en el cdigo crtico.
Utilice validaciones para comprobar los parmetros que se recibe en las funciones y procedimientos.
Elimine de su cdigo el comportamiento indefinido, o utilice validaciones para encontrar usos
ilegales de este comportamiento.
Documente las validaciones en forma corta y precisa.
Elimine las suposiciones implcitas o bien utilice validaciones que las verifiquen.
Tenga en cuenta las condiciones imposibles, deben ser detectadas.
No programa en forma defensiva ya que suele ocultar errores.
Si es posible use un segundo algoritmo para comprobar los resultados. NO use otra implementacin
del mismo algoritmo.
No espere a que ocurran los errores, utilice comprobaciones iniciales.

Captulo 3 Proteja sus subsistemas


Elimine comportamientos aleatorios.
Fuerce que los errores sean reproducibles.
Destruya sus datos sobrantes para no emplearlos mal.
Si algo ocurre pocas veces, fuerce a que ocurra a menudo.
Mantenga informacin de depuracin para permitir una comprobacin de errores ms estricta.
Construya comprobaciones completas del subsistema y utilcelas frecuentemente.
Disee sus pruebas con cuidado. Nada de ser arbitrario.
No aplique las restricciones de la versin de depuracin a la versin comercial. La capacidad y
velocidad mejoran a costa de la deteccin de errores.

Captulo 4 Haga un seguimiento del cdigo


No espere a que haya un error para seguir el cdigo paso a paso.
Siga paso a paso cualquier posible camino.
Cuando siga su cdigo, cntrese en el flujo de datos.
Los depuradores a nivel de cdigo fuente pueden mantener oculto detalles de ejecucin. Siga paso a
paso el cdigo crtico a nivel de instruccin.

Captulo 5 Interfaces de mquinas automticas


Haga que sea difcil ignorar las condiciones de error.
No encubra cdigos de error con los valores devueltos.
Busque y elimine los defectos de sus interfaces.
No escriba funciones de propsito mltiple. Escriba funciones separadas que permita una validacin
de argumentos ms estricta.
No sea indeterminado. Defina explcitamente los argumentos de funcin.
Escriba funciones que, empleando entradas vlidas, no puedan fallar.
Escriba comentarios que destaquen el peligro potencial.

Captulo 6- Riesgos del oficio


Use los tipos de datos bien definidos.
Pregntese siempre: Esta variable o esta expresin puede rebasar el lmite superior o inferior?.
Implemente la tarea una sola vez.
Elimine las instrucciones if sin relevancia.
Evite la utilizacin de operadores ?: anidados.
Trate caso especiales slo una vez.
Evite las expresiones arriesgadas del lenguaje.
No mezcle tipos de operadores innecesariamente. Si debe hacerlo utilice parntesis para aislarlos.
Evite las llamadas a funciones que devuelven errores.

Captulo 7- Caminos equivocados


No referencie memoria de la que no es dueo.
No referencie memoria que ha liberado.
No utilice memoria de salida como memoria de trabajo intermedia.
No pase datos en memoria esttica (o global ).
No escriba funciones parsitas.
No abuse del lenguaje de programacin.
Escriba cdigo para el programador medio.

Sea inteligente; escriba cdigo aburrido. Tendr menos errores y los programadores de
mantenimiento se lo agradecern.

Captulo 8- Lo importante es la actitud.


Los errores no desaparecen
No deje los errores para despus; corrjalos ahora.
Corrija la causa, no el sntoma.
No elimine elementos del cdigo, a menos que sea importante para el xito del producto.
No implemente utilidades no estratgicas.
No hay utilidades gratuitas.
No permita flexibilidad innecesaria.
No obtenga soluciones intentando cosas hasta que encuentre una que funcione. Emplee su tiempo
en encontrar la solucin correcta.
Escriba y pruebe el cdigo en trozos pequeos. Pruebe siempre su cdigo, aunque signifique alterar
su plan.
No confi en que el grupo de pruebas encuentre sus errores.
No eche la culpa a los comprobadores por encontrar sus errores.
Establezca sus prioridades y sgalas.

Caramba, no lo s
No ha visto alguna vez el cdigo de alguien y se ha preguntado porqu lo haba escrito de la forma
en que lo ha hecho? Y cuando le ha preguntado sobre el cdigo no ha contestado algo como esto
Caramba, no se por qu lo he hecho as. Supongo que entonces pensaba que estaba correcto?

Siempre que reviso cdigo, busco la manera de ayudar a los programadores a mejorar sus tcnicas y
he descubierto que la respuesta Caramba!, no lo s es enormemente normal. Tambin he
descubierto que los programadores que responden Caramba!, no lo s no tienen claras sus
prioridades; toman decisiones basndose, o eso parece, en lo que han almorzado ese da. Los
programadores que tiene claras sus prioridades saben exactamente por qu eligen una
implementacin concreta y si se les pregunta dirn claramente las razones.

Si descubre que suele no saber por qu ha escrito un trozo de cdigo de la forma en que lo ha hecho,
esto es un buen aviso de que necesita detenerse y crear su propia lista de prioridades.

Eplogo Cul es el siguiente paso?


No permita que el mismo error le haga tropezar dos veces.

Você também pode gostar