sábado, 5 de junio de 2010

The art of Unix Programming

El libro de Eric S Raymond (La peor pesadilla de microsoft)es una de las obras imperdibles para todo aquel que quiera dedicarse a la programación. (si, aunque programes con .net)

The art of Unix Programming


Las 17 Reglas de Raymond sobre la programación:
  • Rules of Modularity: Write simple parts connected by clean interfaces.
  • Rule of Clarity: Clarity is better than cleverness.
  • Rule of Composition: Design programs to be connected to other programs.
  • Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  • Rule of Simplicity: Design for simplicity; add complexity only where you must.
  • Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  • Rule of Transparency: Design for visibility to make inspection and debugging easier.
  • Rule of Robustness: Robustness is the child of transparency and simplicity.
  • Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  • Rule of Least Surprise: In interface design, always do the least surprising thing.
  • Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  • Rule of Repair: When you must fail, fail noisily and as soon as possible.
  • Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  • Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  • Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  • Rule of Diversity: Distrust all claims for ìone true wayî.
  • Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Traducción al español desde viva linux:
  • Regla de la Modularidad: Escribe partes simples conectadas por interfaces simples.
  • Regla de la Claridad: La claridad es mejor que las cosas brillantes rebuscadas.
  • Regla de la Composición: Diseña programas que se conecten con otros programas.
  • Regla de la Separación: Separa pliítica del mecanismo, separa las interfaces de las máquinas.
  • Regla de la Simplicidad: Diseña para la simplicidad, agrega complejidad sólo cuando debas.
  • Regla de la Parsimonía: Escribe un programa enorme sólo cuando es claro por demostración que nada más funcionará.
  • Regla de la Transparencia: Diseña para la visibilidad, para hacer fáciles la inspección y el debugging.
  • Regla de la Robustez: La robustez es la hija de la transparencia y la simplicidad.
  • Regla de la Representación: Divide el conocimiento en los datos, para que la lógica de la programación pueda ser estúpida y robusta.
  • Regla de la Menor Sorpresa: En el diseño de la interface, siempe haz la cosa menos sorprendente.
  • Regla del Silencio: Cuando un programa no tiene nada sorprendente que decir, que no diga nada.
  • Regla de la Reparación: Cuendo tengas que fallar, falla estridentemente tan rápido como puedas.
  • Regla de Economía: El tiempo del programador es caro, consérvalo prefiriendo el tiempo de las máquinas.
  • Regla de la Generación: Evita el hackeo artesanal, escribe programas que escriban programas sólo cuando puedas.
  • Regla de la Optimización: Haz prototipos antes de publicarlos. Consigue que funcionen antes de optimizarlos.
  • Regla de la Diversidad: Desoye todas las afirmaciones de "una única solución"
  • Regla de la Extensibilidad: Diseña para el futuro, porque estará aquí antes de lo que piensas.

No hay comentarios:

Publicar un comentario