Filosofía del buen programador

Filosofía del buen programador

• Bello es mejor que feo., si se ve bien por dentro es probable que lo sea también por fuera y funcione muy bien.
• Explícito es mejor que implícito, no espere que quien lea su código sea un guru, es probable que mas tarde ni usted mismo se entienda, su propia genialidad.
• Simple es mejor que complejo.
• Complejo es mejor que complicado.
• Plano es mejor que anidado.
• Disperso es mejor que denso., pequeños trozos de código son mas legibles que extensos galimatias de código criptico.
• La legibilidad cuenta., si al leerlo choca es probable que sea difícil de mantener, alinear, tabular, separar, emparejar y nunca descansar.
• Los casos especiales no son tan especiales como para quebrantar las reglas.no olvide que las excepciones son eso, casos excepcionales no trate de pasarse de listo con esto.
• Aunque lo práctico gana a la pureza., tres lineas de código prosaico son a menudo mas mas fáciles de darles soporte que una sola linea genial.
• Los errores nunca deberían dejarse pasar silenciosamente, cuando menos los pienses si pueden fallar , fallarán
• A menos que hayan sido silenciados explícitamente.
• Frente a la ambigüedad, rechaza la tentación de adivinar, si no sabes pregunta.
• Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo.,  código rebuscado lo único que ayudan es  engrandecen el ego de quien lo hizo, y a madriar a quien le toca darle soporte.
• Aunque esa manera puede no ser obvia al principio.
• Ahora es mejor que nunca.
• Aunque nunca es a menudo mejor que ya mismo.
• Si la implementación es difícil de explicar, es una mala idea., lo mas seguro que el menos la entiende, es usted mismo.
• Si la implementación es fácil de explicar, puede que sea una buena idea.
• Los espacios de nombres (namespaces) son una gran idea, no invente nombre que luego no recuerde que son., se supone que deben ser una ayuda, no un mensaje de espías.
• Vertical es mejor que horizontal, si una una linea tiene mas de 80 caracteres separe en 2 o mas,  en general las pesonas captan mas facil el contenido de informacion de ina linea corta que una larga en la que tengan que desplazar la mirada.
• Corto es mejor que largo, si no puede ver el contido completo del codigo o lo que hace de un vistazo , trate de separarlo en funciones o procesos cortos que faciliten la comprension., por lo general un golpe de vista supone unas 25 lineas maximo.
  
• Si un proceso se repite mas de una vez, es probable que sea mejor crear una funcion o proceso para que lo efectua , el mantenimiento se fcilita y la compresnsion del codigo tambien.