NeoProgramadores - Tips y recursos gratuitos para principiantes en el Arte de la Programación
Tips y recursos gratuitos para
principiantes en el Arte de la Programación
Acerca de NP | Preguntas Frecuentes (FAQ) | Autor | Colabora | Contáctanos | Añádenos a Tus Favoritos (Ctrl-D)

Home Page > Citas Textuales
Ir al sitio de Google 


Web NeoProgramadores
Secciones
Libros Electrónicos
Software y Utilidades
Lecturas Recomendadas
Webs Recomendadas
Tips de Programación
Citas Textuales

Recursos Para Aprender...
C Estándar (ANSI)
C++ (C Más Más)
Pascal
Visual Basic

Libros + Populares (PDF)
Serie "Aprenda... como si estuviera en primero"
Aprenda a programar... (67pág./764Kb)

Aprenda Lenguaje C... (71pág./461Kb)

Aprenda C++ Básico... (70pág./673Kb)

Aprenda C++ Avanzado... (78pág./736Kb)

Aprenda Visual Basic 6.0... (105pág./892Kb)



Logo Cumple con el Estándar HTML 4.1 de la W3C
Sitio diseñado para 800x600+, visible con cualquier navegador y libre de frames. Mejor visto con FireFox y JavaScript activado.

Citas Textuales

(Próximamente esta lista de citas será actualizada y organizada en categorías para una mejor lectura.)

"Muchos programas y proyectos comienzan en el papel, no hay que avergonzarse de hacer un borrador de un algoritmo difícil. A veces una idea puede lograr un alto nivel de abstracción que puede ser más comprensible mediante un dibujo."

Gustavo Rondina, de su artículo Ingeniería de Software


"Escribe programas que hagan una cosa y la hagan bien."

Eric S. Raymond, de su libro The Art of Unix Programming
(El Arte de la Programación en UNIX)


"Los desarrolladores deberían leer documentos científicos y libros técnicos sobre diseño de software. Muchos programadores simplemente buscan que su software produzca los resultados deseados, pero si un programador quiere ser un desarrollador exitoso y tener gran calidad y software confiable, es esencial conocer las bases teóricas que se esconden bajo la práctica."

Gustavo Rondina, de su artículo Ingeniería de Software


"Haz que cada programa haga bien una sola cosa. Para hacer una nueva tarea, construye un nuevo programa en lugar de complicar los viejos agregándole nuevas funcionalidades."

Eric S. Raymond, de su libro The Art of Unix Programming
(El Arte de la Programación en UNIX)


"El conocer la sintaxis de un lenguaje de programación no significa que se conozca cómo desarrollar un buen programa y un software de calidad."

Gustavo Rondina, de su artículo Ingeniería de Software


"Regla 2: Mide. No optimices buscando velocidad hasta que hayas medido, y aún entonces no lo hagas a menos que una parte del código abrume al resto."

Rob Pike, de su libro Notes on C Programming
(Notas sobre la Programación en C)


"Un programa no es simplemente ejecutar un editor de textos y comienzar a escribir código y compilarlo, esperando obtener los resultados esperados."

Gustavo Rondina, de su artículo Ingeniería de Software


"Controlar la complejidad es la esencia de la programación de computadoras."

Brian Kernighan


"Para alcanzar el rápido avance tecnológico en la industría de hardware, los diseñadores de software y programadores, cuyo trabajo es desarrollar el núcleo del software, deben tener la idea de que es necesario no simplemente crear y desarrollar un producto que trabaje, sino un producto que implemente buenas prácticas de ingeniería de software, asegurando que la computadora o los esfuerzos del programador no sean derrochados."

Gustavo Rondina, de su artículo Ingeniería de Software


"Regla 4. Los algoritmos fantasiosos son más propensos a los errores que los simples, y son mucho más difíciles de implementar. Usa algoritmos simples al igual que estructuras de datos simples."

Rob Pike, de su libro Notes on C Programming
(Notas sobre la Programación en C)


"El conocer varios lenguajes de programación y paradigmas de lenguajes dan al programador más flexibilidad mientras elije la mejor forma de resolver el problema, puesto que cada lenguaje tiene sus propios limites."

Gustavo Rondina, de su artículo Ingeniería de Software


"El software es una producción inmaterial del cerebro humano y tal vez una de las estructuras más complicadas que la humanidad conoce. De hecho, los expertos en computación aún no entienden del todo cómo funciona, su comportamiento, sus paradojas y sus límites."

Miquel Vidal, de su ensayo Cooperación sin mando: una introducción al software libre



"Lo sepamos o no, nos guste o no, nuestro carácter está reflejado en cada línea de código que escribimos, en cada informe que diseñamos, en cada interfaz de usuario que construimos, en cada diagrama que hacemos."

Daniel Read, de su ensayo
Los Principios del Programador>


"La cuestión no es si uno es capaz de escribir el mejor código posible, si no, si se preocupará por intentarlo."

Daniel Read, de su ensayo
Los Principios del Programador>


"La estética es especialmente importante en el desarrollo de software, un terreno en el que siempre estamos tratando con niveles de abstracción. Los aspectos estéticos de nuestras abstracciones están directamente relacionados con su entendibilidad y, por lo tanto, con su utilidad."

Daniel Read, de su ensayo
Los Principios del Programador>


"Un programador debe esforzarse en conseguir la belleza, sin importar la herramienta o el lenguaje de programación que esté utilizando. La belleza puede conseguirse a muchos niveles, desde el alto nivel de la elegancia en el diseño del sistema hasta el más bajo nivel de la apariencia visual del código en la pantalla."

Daniel Read, de su ensayo
Los Principios del Programador>


"El mejor código no solo funciona de forma correcta y eficiente, y está bien formado desde el punto de vista del compilador; el mejor código es también agradable de ver por el ojo humano-- y por lo tanto más fácil de absorber y de comprender para el cerebro humano."

Daniel Read, de su ensayo
Los Principios del Programador>


"La claridad en el código es un estado que debemos buscar activamente. Uno de los mayores delitos que como desarrolladores podemos cometer es olvidar que nuestro código tiene una vida más allá de los pocos momentos que nos lleva escribirlo. Las probabilidad de que alguien, posiblemente nosotros mismos, maneje nuestro código en el futuro son muy altas."

Daniel Read, de su ensayo
Los Principios del Programador>


"Hay una diferencia entre claro y correcto, y muchas veces se confunden. La corrección es siempre el principal interés del desarrollador, como debe ser. La corrección lleva a que la sintaxis del código sea correcta a los ojos del compilador, que el diseño de la interfaz cubra las necesidades del usuario, y que los algoritmos que se implementan cumplan con sus requerimientos. Pero si no se dedica una atención igual a la claridad, la comprensibilidad y la mantenibilidad del código sufrirán mucho. Para que nuestro código sea lo más claro posible, debemos deliberadamente usar técnicas como la utilización de identificadores descriptivos, la modularidad, la indentación (el sangrado), los espacios en blanco, la cohesión del código, el acoplamiento débil del código, propiciar la fácil realización de las pruebas y la documentación, y comentar adecuadamente."

Daniel Read, de su ensayo
Los Principios del Programador>


"... la distribución visual no solo sirve para hacer el código visualmente más atractivo, sino que también actúa a nivel del subconsciente haciendo el código más entendible al lector. El objetivo es reducir la cantidad de trabajo que un lector necesita para entender el código. La apariencia visual debe ser nuestra primera herramienta para comunicarnos con claridad con un lector humano que esté leyendo nuestro código."

Daniel Read, de su ensayo
Los Principios del Programador>


"Como desarrolladores, debemos esforzarnos en el desarrollo de un estilo de codificación sólido, lo cual es la clave del código auto-documentado. Debemos estar constantemente mejorando y perfeccionando nuestro estilo, de forma que cada programa que escribimos sea mejor que el anterior."

Daniel Read, de su ensayo
Los Principios del Programador>


"Como desarrolladores, debemos esforzarnos en el desarrollo de un estilo de codificación sólido, lo cual es la clave del código autodocumentado. Debemos estar constantemente mejorando y perfeccionando nuestro estilo, de forma que cada programa que escribamos sea mejor que el anterior. Un estilo bien desarrollado se consigue incorporando técnicas probadas, como el uso de identificadores informativos y consistentes; la modularización bien cohesionada y acoplada; evitar el uso de técnicas difíciles de comprender; hacer una buena distribución visual del código; dar nombres adecuados a las constantes; probando y documentando las suposiciones; y muchas otras."

Daniel Read, de su ensayo
Los Principios del Programador>


"El código bien escrito no debe necesitar demasiados comentarios; debe explicarse por si mismo."

Daniel Read, Principio de Código Auto-Documentado, de su ensayo
Los Principios del Programador>


"La documentación más fiable para el software es el propio código. En muchos casos, el propio código es la única documentación. Por lo tanto, esfuérzate en hacer que tu código sea auto-documentado, y allí donde no sea posible, añade comentarios."

Daniel Read, Principio de Código Auto-Documentado, de su ensayo
Los Principios del Programador>


"Las comprobaciones son la piedra angular de la programación defensiva. En realidad en cada pieza de código hacemos suposiciones. Lo que ocurre es que algunas son obvias y no es necesario que se comprueben ni se documenten. Sin embargo, podemos y debemos comprobar (y documentar) las muchas otras suposiciones que son menos evidentes."

Daniel Read, de su ensayo
Los Principios del Programador>


"Como desarrolladores de software, nuestra principal responsabilidad en cuanto a la interacción con el usuario descansa en el diseño de la interfaz de usuario."

Daniel Read, de su ensayo
Los Principios del Programador>


"Comentar el código, su adecuada distribución visual, el control de errores, la modularización adecuada, la correcta implementación, etc... El momento de hacer todas esas tediosas tareas asociadas a la codificación es el preciso momento en el que se está escribiendo el código."

Daniel Read, de su ensayo
Los Principios del Programador>


"El disfrute visual e intelectual de un código bien formateado es un placer que pocos no-programadores pueden apreciar. Pero los programadores que se sienten orgullosos de su trabajo experimentan una gran satisfacción artística puliendo la estructura visual de su código."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Una buena distribución visual [del código] muestra la estructura lógica de un programa."

Steve McConnell, Teorema Fundamental del Formateo, de su libro
Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Los buenos programadores resuelven problemas. Los mejores los evitan."

César Becerra Santamaría (Versión aparentemente pirateada de cierto documento sobre hackers)


"Las técnicas de codificación superiores y las prácticas de programación son los sellos de un programador profesional. El grueso de la programación consiste en tomar una gran cantidad de pequeñas elecciones mientras se intenta resolver un conjunto mayor de problemas. Qué tan sabiamente se hacen esas elecciones depende bastante de la habilidad y la experiencia del programador."

Rob Caron, de su artículo Coding Techniques and Programming Practices (Técnicas de Codificación y Prácticas de Programación)


"Las técnicas de codificación son fundamentalmente las que mejoran la legibilidad y la mantenibilidad del código, mientras que las prácticas de programación son en su mayoría mejoras en el desempeño."

Rob Caron, de su artículo Coding Techniques and Programming Practices (Técnicas de Codificación y Prácticas de Programación)


"La legibilidad del código fuente tiene un impacto en qué tan bien un desarrollador comprende un sistema de software. La mantenibilidad del código se refiere a qué tan fácilmente ese sistema de software puede ser cambiado para agregarle nuevas funcionalidades, modificar las existentes, corregir errores, o mejorar el desempeño. Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una faceta particular del desarrollo del software en la cual los desarrolladores tienen una influencia es en la técnica de codificación. El método más fácil de asegurarse que un equipo de desarrolladores will yield la calidad del código es establecer un estándar de codificación, el cual sea reforzado mediante revisiones rutinarias de código."

Rob Caron, de su artículo Coding Techniques and Programming Practices (Técnicas de Codificación y Prácticas de Programación)


"Conocer un vocabulario y una gramática no equivale a saber un idioma. Conocer un idioma implica además el hábito de combinar sus elementos de forma semiautomática para producir frases que expresen lo que uno quiere decir. Conocer las palabras, las sentencias y la sintaxis del C no equivalen a saber programar, pero son condición necesaria para estar en condiciones de empezar a hacerlo, o de entender cómo funcionan programas ya hechos."

José Javier García de Jalón de la Fuente, y otros, de su libro Aprenda lenguaje ANSI C como si estuviera en primero


"Cuando el programa está siendo probado, es muy tarde para hacer cambios de diseño."

Duke Hillard, de su escrito El Tao de la Programación


"La depuración no es en sí una forma de mejorar la calidad de tu software; es una manera de diagnosticar errores. La calidad del software debe integrarse desde el inicio. La mejor manera de construir software de calidad es desarrollar cuidadosamente los requerimientos, diseñar bien, y usar prácticas de codificación de alta calidad."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Un buen estilo de programación comienza con la efectiva organización del código. Usar una organización clara y consistente de los componentes de tu programa lo hace más eficiente, legible y mantenible."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"Si no se ha hecho una buena definición del problema, podrías estar resolviendo el problema equivocado durante la construcción."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Su computadora, su compilador y la ayuda de su entorno son buenos maestros. Si no está seguro de cómo funciona una característica de C, escriba un programa de muestra con dichas características, compile y ejecute el programa, y vea qué es lo que ocurre."

H.M. Deitel & P.J. Deitel, de su libro Cómo programar en C/C++.
Prácticas sanas de programación


"No importa qué tan buenas sean las herramientas que te ayudan a detectar errores en tus programas, la meta de cada programador debería ser evitar los bugs en primer lugar. Las herramientas de depuración sirven para un propósito, pero confiar en ellas para atrapar tus errores de programación no te hace un mejor programador. Lo que te hace un mejor programador es aprender de tus errores."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"Un computador hará lo que le digas, pero ello puede ser muy diferente de lo que tengas en mente."

Joseph Weizenbaum


"El 20% del código contiene el 80% de los errores. ¡Encuéntrelos y corríjalos!"

Lowell Arthur


"La mayoría de las compañías aún no emplean métodos de usabilidad sistemáticos para conducir sus diseños."

Jakob Nielsen, de su artículo
"Concepciones Erróneas Acerca de la Usabilidad"


"Aquel que duda y no investiga, se torna no sólo infeliz, sino también injusto."

Blaise Pascal, en cuyo honor se nombró el famoso lenguaje Pascal


"La depuración es la piedra angular de ser un programador... Un programador que no puede depurar efectivamente está ciego."

Robert L. Read, de su ensayo Cómo ser un Programador. Un Resumen Corto, Comprensivo y Personal


"Una interfaz de usuario está bien diseñada cuando el programa se comporta exactamente como el usuario piensa que debería."

Joel Spolsky, de su libro User Interface Design For Programmers
(El Diseño de la Interfaz de Usuario para Programadores)


"El depurador no es un sustituto para el buen razonamiento. Pero, en algunos casos, pensar tampoco es sustituto para un buen depurador. La combinación más efectiva es un buen razonamiento y un buen depurador."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Programar una computadora requiere paciencia y concentración. Solamente la atención a los mínimos detalles evitará los frustrantes errores gramaticales. Solamente la planeación rigurosa y la adherencia al plan prevendrá los errores lógicos serios en nuestros diseños. Pero cuando finalmente dominemos el diseño de programas, habremos aprendido habilidades que son útiles más allá del campo de la programación."

Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi, de su libro How to Design Programs - An Introduction to Computing and Programming (Cómo Diseñar Programas - Una Introducción a la Computación y a la Programación)


"Las técnicas de la Programación Defensiva hacen los errores más fáciles de detectar y de corregir y menos dañinos en el software en producción."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"La organización es la clave para un programa bien escrito. Un buen estilo de programación ayuda a presentar los detalles y la lógica de tu programa de una manera clara y fácil de comprender."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"Un denominador común de los programadores que construyen software de alta calidad es su uso de prácticas de alta calidad. Tales prácticas enfatizan la calidad al comienzo, a la mitad, y al final de un proyecto."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"El estilo de programación y la estética están relacionados. Un programa bien escrito da gusto verlo, leerlo y comprenderlo. Tu meta al formatear un programa es hacerlo claro a la vista, bien organizado, y hermoso."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"En general, el principio es encontrar un error lo más cerca posible del momento en que fue introducido. Entre más persista el efecto en la cadena alimenticia del software, más daño causa en las partes inferiores de la cadena."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"¿Qué es un programa amistoso con el usuario? Simplemente un programa que el usuario considera un amigo en lugar de un enemigo... Ocasionalmente un usuario intentará hacer algo que cause daño permanente y pérdida de datos a su sistema. Un programa amistoso con el usuario provee a los usuarios una red de seguridad [como la que usan los trapecistas de circo] previniéndolos de hacer algo estúpido a menos que realmente quieran hacerlo."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"Comprender la diferencia entre programar en un lenguaje y programar con un lenguaje es crítico... La mayoría de los principios de programación importantes no dependen de un lenguaje específico sino de la forma en que lo usas. Si tu lenguaje adolesce de construcciones que quieres usar o es propenso a otros tipos de problemas, trata de comprensarlos. Inventa tus propias convenciones de codificación, estándares, bibliotecas de clases, y otras adiciones."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Invertir tiempo y esfuerzo en el problema de comprender por qué existen los bugs es el primer paso para escribir código libre de errores. El segundo paso es entrar en acción e instituir políticas que eliminen el problema o ayuden a detectarlo."

Steve Oualline, de su libro C Elements of Style (Elementos de Estilo en C)


"Usa un depurador solamente como un último recurso. Tener que recurrir a un depurador significa que tus metodologías de programación han fallado."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"La arquitectura cuidadosa de la interfaz de usuario hace la diferencia entre un programa preferido y uno que nunca es usado."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Regla 1. No puedes decir a priori dónde gastará un programa la mayor parte de su tiempo. Los cuellos de botella ocurren en lugares sorprendentes, así que no intentes adivinar ni colocar un hackeo optimizador de velocidad hasta que hayas probado que es ahí donde está el cuello de botella."

Rob Pike, de su libro Notes on C Programming
(Notas sobre la Programación en C)


"Regla 4:Los algoritmos fantasiosos son más propensos a los errores que los simples, y son mucho más difíciles de implementar. Usa algoritmos simples al igual que estructuras de datos simples."

Rob Pike, de su libro Notes on C Programming
(Notas sobre la Programación en C)


"El uso de los ciclos es uno de los aspectos más complejos de la programación; sobre cómo y cuándo usar cada tipo de ciclo es un factor decisivo en la construcción de software de alta calidad."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Regla 5: Los datos dominan. Si has escogido las estructuras de datos correctas y organizaste bien las cosas, los algoritmos serán casi siempre auto-evidentes. Las estructuras de datos, y no los algoritmos, son el centro de la programación."

Rob Pike, de su libro Notes on C Programming
(Notas sobre la Programación en C)


"Debido a que el mantenimiento es tan importante y tan caro, debes escribir programas como si la comunicación más importante que ellos hagan no es hacia la computadora que los ejecuta sino a los seres humanos que leerán y mantendrán el código fuente en el futuro (incluyéndote a ti mismo)."

Eric S. Raymond, de su libro The Art of Unix Programming
(El Arte de la Programación en UNIX)


"El costo de corregir un error se eleva dramáticamente desde el momento en que fue introducida hasta que es detectado."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"Nunca te esfuerces en decifrar un código astuto tres veces. Una vez podría ser una suerte, pero si te encuentras a ti mismo teniendo que comprenderlo una segunda vez -porque la primera fue hace mucho y has olvidado los detalles- es tiempo de comentar el código de tal manera que la tercera vez sea relativamente indolora."

Henry Spencer


"Un sistema de software es transparente cuando puedes ver en él e inmediatamente comprender lo que está haciendo y cómo. Es descubrible cuando tiene facilidades para monitorear y exhibir su estado interno de tal forma que tu programa no solamente funcione bien sino que pueda verse que funciona bien."

Eric S. Raymond, de su libro The Art of Unix Programming (El Arte de la Programación en UNIX)


"Comprende la raíz del problema antes de corregirlo. Las divinanzas aleatorias acerca de las fuentes de los errores y las correcciones aleatorias dejarán el programa en peores condiciones que cuando empezaste."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"La clave para dividir y vencer como una técnica de depuración es la misma que para el diseño de algoritmos: mientras hagas un buen trabajo dividiendo el misterio a la mitad, no tendrás que dividirlo demasiadas veces, y estarás depurando rápidamente."

Robert L. Read, de su ensayo Cómo Ser Un Programador: Un Resumen Corto, Comprensivo y Personal


"La clave para mejorar el desempeño de un sistema muy complicado es analizarlo lo suficientemente bien para encontrar los cuellos de botella, o lugares donde se consumen la mayoría de los recursos."

Robert L. Read, de su ensayo Cómo Ser Un Programador: Un Resumen Corto, Comprensivo y Personal


"Regla de Simplicidad: Diseña pensando en la simplicidad; agrega complejidad solamente donde debas."

Eric S. Raymond, de su libro The Art of Unix Programming
(El Arte de la Programación en UNIX)


"Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea."

Eric S. Raymond, de su ensayo La Catedral y el Bazar


"La robustez no es un módulo que puede ser incrustado a un lado de un sistema preexistente --es mucho más efectivo en costos desarrollar software robusto si te esfuerzas por esta calidad desde el día uno."

John Viega y John McManus, de su artículo La Importancia de la Prueba del Software


"Sencillez, claridad, y elegancia son los sellos de los buenos programas; oscuridad, ingeniosidad, y complejidad son indicaciones de un diseño inadecuado y un pensamiento mal orientado."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"Los depuradores son herramientas grandiosas, pero no son sustituto de las buenas metodologías de programación que ayudan a eliminar errores en primera instancia."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"Los errores ocurren cuando cualquier aspecto de un producto software es incompleto, inconsistente o incorrecto. Las tres grandes clases de errores del software son los de requisitos, de diseño, y de implantación."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"Una buena interface de función provee al usuario una interface a la función pequeña y sencilla."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"La alta calidad no se puede lograr sólo mediante la prueba del código fuente... En el supuesto de que los errores del código fuente fueran la única medida de la calidad, las pruebas, por sí solas, no podrían garantizar la ausencia de errores de un programa."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"El código bien escrito puede ayudar a un programador a comprender qué pasa, pero la mejor forma de comunicación es el comentario. Los comentarios se usan para explicar todo. Sin comentarios, un programador tiene que pasar por el largo y doloroso proceso de desencriptar el programa para entender qué rayos hace."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"La actividad más importante para mejorar el mantenimiento durante el diseño estructural es recalcar la claridad, la modularidad, y la facilidad de modificación como los principales criterios de diseño..."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"La estructura de un programa bien estructurado es obvia; no requiere inspección detallada."

Steve Oualline, de su libro C Elements of Style
(Elementos de Estilo en C)


"El objetivo principal del desarrollo del sofware debe ser la producción de sistemas de software que faciliten su propio mantenimiento. El mantenimiento, como todos los atributos de calidad de alto nivel, se puede expresar en términos de atributos construidos dentro del producto. Los atributos primarios del producto que contribuyen al mantenimiento son la claridad, la modularidad, y la buena documentación interna del código fuente, además de documentos de apoyo apropiados."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"Un compilador optimizador ayuda a que un programa corra más rápido, pero en todos los casos, un buen diseño hace que un programa corra rápido. Un gran diseño produce el programa más rápido. Invertir un poco más de tiempo en un problema de programación generalmente resulta en un mejor diseño, el cual pude hacer que un programa corra significativamente más rápido."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"La mejor manera de minimizar el número de errores en un programa es encontrarlos durante el análisis y diseño, de modo que se introduzcan pocos errores al código fuente."

Richard Fairley, de su libro Conceptos de Ingeniería de Software


"La razón primaria para mantener las funciones pequeñas es que ayuda a manejar y comprender mejor un problema de programación."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"La programación defensiva es útil como un accesorio para las otras técnicas orientadas al mejoramiento de la calidad... La mejor forma de codificación defensiva es no insertar errores en primera instancia..."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


"La mejor forma de escribir un programa libre de errores es mantener todas las defensas en alto en todo momento. Al menos de este modo sabrás cuándo hay un problema en tu programa."

Jerry Jongerius, de su libro Writing Bug Free C Code
(Escribiendo Código en C Libre de Errores)


"Parte del trabajo de un programador es educar a los jefes y colegas sobre el proceso de desarrollo de software, incluyendo la importancia de la adecuada preparación antes de que la programación comience."

Steve McConnell, de su libro Code Complete - 2nd. Ed.
(Código Completo - 2da. Ed.)


Última actualización: 24/04/2007

TECOMSA - 2893029/8363823

¿Necesitas ayuda
con tu proyecto de
C/C++, Pascal o COBOL?

Pulsa aquí


Compiladores & IDEs
Versiones alternativas y compatibles para gran número de lenguajes de programación ¡GRATIS!
FreeByte
Compilers
TheFreeCountry
Upseros

Software y Utilidades
Tablas ASCII: Básica y Extendida (37Kb)

Glosario Informático (984Kb) Diccionario en formato de ayuda estilo Windows.
DFD 1.0 (555Kb) Editor e intérprete interactivo de diagramas de flujo. Permite imprimir, ejecutar y depurar los diagramas que crea.




   

Página Principal: http://www.galeon.com/neoprogramadores -- email: neoprogramadores@galeon.com

Todos los recursos referenciados en este sitio son gratuitos y/o están públicamente disponibles en Internet. Si su uso o acceso viola el copyright de sus autores o propietarios legales, deslindamos cualquier responsabilidad sobre la web donde están alojados. Dichos recursos se referencian aquí con fines estrictamente educativos, y se ofrecen tal cual son, sin ninguna garantía implícita o explícita.

Copyleft ©2005-2010 NeoProgramadores. Comentarios y sugerencias al autor/webmaster.