Como programador, ¿cuál es tu lema favorito?

Limpio y correcto, pero correcto sobre todo lo demás.

Originalmente no se me ocurrió esto, pero esto es lo que les decimos a los miembros del equipo durante la revisión del código cuando se atascan tratando de crear un diseño que se pueda extender para adaptarse a todos los casos de uso posibles * wink *. Nadie más va a usar su servicio en este momento, pero necesitamos lanzar esta función hoy. Así que concéntrese en lo correcto ahora, refactorice agresivamente más tarde, y solo si es necesario.

Además, puede limpiar el código correcto para empezar. Pero tiene poco uso para el código que es perfectamente idiomático pero que está haciendo todo mal en primer lugar.

Nunca se hace hasta que sea rápido, receptivo y correcto. Pero si no puedes ser rápido, al menos sé receptivo. Si aún no puede responder, ¡al menos sea correcto!

Ahora se me ocurrió esto, pero tengo el fuerte presentimiento de que lo deduje de algo más que leí en las redes sociales. La razón aquí es que su producto / proyecto debe ir más allá de las pruebas de corrección de casos de uso, sino también las pruebas de carga; cualquier cosa debajo de eso debe considerarse como un trabajo en progreso.

Ser rápido generalmente significaría que su arquitectura está diseñada adecuadamente, generalmente con bucles delimitados y las medidas de almacenamiento en caché adecuadas, entre otros. Espera, ¿qué es lo que realmente necesitas para ejecutar un algoritmo [matemático] O (n ^ 3) [/ matemático] y no tienes tiempo para calcular previamente las respuestas almacenadas en caché? Al menos haz que responda ; no deje a sus usuarios mirando a la nada mientras se ejecuta su algoritmo cúbico. Comuníqueles muy claramente que se está trabajando detrás de escena y que tienen que esperar. ¿Qué significa que todos sus clientes están atrapados en IE6 para que sus trucos de respuesta de UI web sofisticados y sofisticados no funcionen? Pobre alma, al menos asegúrate de que tu implementación sea correcta . Solo imagine la frustración de un usuario esperando 10 minutos para obtener resultados obviamente incorrectos. No eres rápido ni receptivo, al menos haz que la espera valga la pena.

(Aunque en serio, ¿un algoritmo [matemático] O (n ^ 3) [/ matemático] en producción? Debería comprometerse como el infierno antes de adjuntar su nombre a algo así. Deje en claro a todos los involucrados lo que están aceptando). Y asegúrese de que su acuerdo esté documentado adecuadamente, por escrito. Luego haga una copia de seguridad de dicha documentación. Luego, antes del lanzamiento, asegúrese de que experimenten en persona lo lento que podría ser todo).

A2A diré esto

“La depuración está buscando y debería ser agradable”

Demasiadas veces, las personas toman los errores como castigo, cuando en realidad deberían tomarlo como un momento de enseñanza. Necesariamente, los errores ocurren por circunstancias inesperadas que pueden ser triviales, pero también pueden serlo por razones más profundas. Mirar su código fuente tratando de averiguarlo generalmente es un ejercicio de frustración. Su código solo le devolverá sus ideas preconcebidas, por lo que es el último lugar donde buscar.

En cambio, uno debe mirar por qué ocurre el error, en qué circunstancias buscar todas las señales de que algo sale mal e intentar analizarlo. Un error clásico es tratar de hacer que el error se ajuste a tus ideas preconcebidas. Su jefe no sabe lo que hizo X, por lo que asigna automáticamente la responsabilidad a X. O algo que acaba de hacer Y tiene que ser responsable. Hay un momento maravilloso en la Primaria (serie de televisión), donde un policía le dice a Sherlock que tiene sus trucos para encontrar al culpable. Su respuesta es que no tiene trucos, sino que busca pruebas sin preconceptos. Esta debería ser tu actitud.

Mucho progreso proviene de la depuración. Tenía un programa C que salió mal y no pude localizarlo mediante declaraciones impresas porque el error ocurrió antes. Me dijeron que Valgrind encontró el problema y descubrí muchos otros problemas con esto. Abrió toda una clase de herramientas y una comprensión más profunda de la memoria y el progreso.

A veces, la depuración se siente como la arqueología de los detritos de un programador perdido hace mucho tiempo. A veces, la depuración te lleva a descubrir nuevas matemáticas. Mi mentor me dijo en ese momento que cada politopo de Delaunay reticular tenía una base afín pero sospechaba que no era cierto. Puse un algoritmo para encontrarlos cuando sea necesario en un programa de enumeración. En algún momento el algo entró en bucle infinito. Allí estaba, un politopo de celosía de Delaunay sin base afín, lo que condujo a una publicación: [matemáticas / 0512193] Cómo calcular el rango de un politopo de Delaunay.

Finalmente, después de resolver su error, adquiere nuevos conocimientos. Debe integrarlo para que nunca vuelva a suceder. Si más adelante en su vida profesional se encuentra con el mismo error y sigue todos los pasos de valgrind, gdb, imprimir declaración, etc. solo para encontrar el mismo error o el mismo tipo, entonces su viaje ha sido en vano. Aquí es donde entra el desánimo, pero no tiene por qué ser así.

Definitivamente no es “KISS”, puedo decirte eso.

Como justificación de diseño, la mención de KISS, o “Mantenlo simple, estúpido”, como tantos lemas igualmente trillados, es una copia. También es muy popular. Probablemente el más popular. ¿Y por qué no? Es fácil de decir, recordar y comprender (a un nivel superficial), por lo que, por supuesto, las personas se aferran a él como si fuera la respuesta a todo. Pero si KISS es un “principio” tan conocido, entonces ¿por qué continuamos construyendo sistemas que son tan difíciles de mantener?

Porque KISS no significa nada. Lo que una persona piensa es muy simple, otra persona piensa que es confuso como el infierno. La persona A piensa que menos clases más grandes es “simple”; la persona B piensa más, las clases más pequeñas son “simples”. La persona C ve la recursividad como simple; la persona D prefiere la iteración. La persona E desprecia incluso la sugerencia de herencia; la persona F ve su mérito ocasional. La persona G “simplifica” su código aplicando un patrón de diseño familiar; la persona H, que no sabe nada de patrones de diseño, examina el trabajo de su colega y grita: “¡Qué es todo ese sinsentido! ¡Hazlo simple, estúpido!

… como si estuviera diciendo algo nuevo y profundo. (Él no es.)

Eso sí, por favor, aprecio la intención de estos lemas, a saber, servir como recordatorios sutiles de ideas subyacentes importantes pero mucho más complejas. Sin embargo, me advierto a mí mismo y a los demás que evitemos confundir su sucinta formulación con evidencia de aplicabilidad universal o, lo que es peor, confundir las consignas con las ideas.

Pero para ser justos con la pregunta, y a pesar de mi desprecio general por los lemas (o, más exactamente, por su abuso), ofreceré este como un favorito personal:

Cada elección implica compensaciones.

Al tomar una decisión de diseño, es mejor no recurrir a clichés para su justificación, sino identificar explícitamente los costos y beneficios implicados (tanto a corto como a largo plazo) junto con sus respectivas probabilidades, y compararlos con entre sí a la luz del contexto específico.

Oh, muchos …

• Se necesita el mismo tiempo para hacer algo de la manera correcta que de la manera incorrecta. Simplemente pasas el tiempo en diferentes lugares.
• Todo es hablar hasta que se envíe.
• El arma más destructiva de la administración es un artículo de Harvard Business Review medio comprendido . Estoy pensando, por ejemplo, en el que dice: “Todas las cosas son iguales, enviar antes significa ganar más dinero”. Muchos gerentes no leen la parte “todas las cosas son iguales” e insisten en enviar un código roto a sus clientes más importantes.
• Mantenga las cosas lo más simple posible, pero no más simple . El principio KISS solo va muy lejos. El juicio importa.
• El objeto más peligroso del universo es una unidad flash no etiquetada.
• La programación del desarrollo de software predice el futuro.
• No hay código como no hay código . Es decir, una solución que no implica ningún código es a menudo la mejor solución.

Sigo los de Dijkstra. Apelan al pequeño programador y aprendiz apasionado que hay en mí. En ningún orden particular:

1. Intento ser lo más que pueda. De lo contrario, la próxima vez que lea, no entenderé una palabra.

“La simplicidad es un requisito previo para la fiabilidad”.

2. Bueno, eso tiene sentido.

“La informática no tiene más que ver con las computadoras que la astronomía con los telescopios”.

3. Nada es perfecto.

“¡Las pruebas de programa se pueden usar para mostrar la presencia de errores, pero nunca para mostrar su ausencia!”

4. ¿Podemos decir lo mismo para los conductores con menos automóviles?

“La cuestión de si una computadora puede pensar no es más interesante que la cuestión de si un submarino puede nadar”.

5. Eso es muy cierto.

“La elegancia no es un lujo prescindible, sino un factor que decide entre el éxito y el fracaso”.

6. Por último, pero no menos importante. El que se aplica no solo al programador sino probablemente a todo.

“Perfeccionarse es tanto desaprender como aprender”.

A2A. No creo que pueda condensarlo en un solo lema, pero intentaré y luego enumeraré mis “Mandamientos de programación”. Aquí está mi mejor esfuerzo:

Programe un idioma para su problema.

Eso resume cómo programo y también cómo pienso acerca de la programación: debe construir un conjunto de herramientas en su lenguaje, superponiendo un nivel cada vez más abstracto, hasta llegar a un punto de abstracción donde pueda expresar su problema a la computadora clara y sencillamente Aquí hay otras reglas importantes que siempre sigo, en orden de precedencia:

• Use el método de abstracción más simple que pueda resolver el problema.
• No escriba para su reutilización: factorice el código en una unidad reutilizable solo después de que ocurran al menos tres instancias. De lo contrario, se supera el código diseñado, contradiciendo la regla 1.
• La funcionalidad relacionada va de la mano.
• Eliminar el código suele ser más productivo que agregarlo.
• Su programa crece con su comprensión del problema. Nunca puede comprender completamente un problema antes de comenzar.
• Los datos deben ser pasivos. No debe actuar sobre sí mismo. Otras cosas deberían actuar en consecuencia.
• Evite la programación desorientada por objetos.
• La mutabilidad, aunque a veces es necesaria, debe evitarse hasta que la alternativa sea al menos 10 veces más larga.
• Cuanto menos detallado sea el lenguaje de implementación o programación, más fácil será mantenerlo en la cabeza y mejor podrá depurarlo.
• Un buen sistema de tipos te ayuda a expresar tus pensamientos. Un mal sistema de tipos limita los pensamientos que puedes expresar.
• Mida la verbosidad mediante construcciones sintácticas (normalmente AST), no recuento de líneas o caracteres.
• Los objetos no están prohibidos.
• Refactorice a menudo, pero solo cuando lo necesite.
• La mala documentación es peor que ninguna, y la documentación siempre es “mala” hasta que el programa finaliza.
• No interrumpa su flujo: busque un editor que haga lo mejor que pueda por usted y un compilador que le diga lo más que pueda.
• Los IDE, aunque a menudo son útiles, en general no ayudan en lo lentos, obstinados y frágiles que son.

Mantenlo simple, estúpido (o beso).

Simple sí. Mi consejo favorito: “Si necesita el mismo código dos veces, escriba una función; si vas a usarlo una vez, considera escribir una función de todos modos, si agrega claridad “.

Por lo general, la manipulación compleja de datos significa grandes bloques de código. Crear trozos

1. Hacer el código principal más corto
2. Hacer el código principal más fácil de leer y mantener
3. Si alguna vez necesita uno de esos fragmentos de código, ya estarán allí listos (o casi listos) para usar.

“Las características engendran características”.

Todo el software crecerá en complejidad hasta que muera y sea reemplazado por un nuevo software que crezca en complejidad.

Mientras haya software y demandas de cosas nuevas, los sistemas de software siempre se expandirán y nunca se contraerán en características o complejidad.

Software Gravity y The Katamari Damacy Effect harán que cualquier programa de software exitoso o popular se convierta en un desastre imposible de mantener. Los programas impopulares y sin éxito mueren o crecen en funciones a un ritmo mucho más lento.

Como resultado, todos los sistemas de software importantes están plagados para siempre de mal diseño, código heredado y cajas negras que no se deben tocar, pero que se deben mantener potencialmente durante décadas.

Luchar contra esta corriente es en gran medida imposible.

-Brian

PD: También podrías disfrutar de mi otro escrito.

“¡Piensa dos veces, codifica una vez!”

Porque si lo haces. Ahorrará mucho dolor de cabeza y tiempo de su vida. Solo piense en el objetivo: está tratando de alcanzar el objetivo. Ahora, piense en la forma más eficiente de alcanzar su objetivo. Esto es lo que significa.

Porque, la codificación debe tomar solo el 20% de su tiempo, el 80% restante debe usarse para buscar una mejor idea, formas de llegar a ella. Siempre use la regla 80-20 en su vida. Hace las cosas mucho mas faciles. 🙂

Si no uso esta regla, no podré hacer cosas en mi vida como:

1. Estudiar / aprender,
2. Trabajando en la industria,
3. Crear programas para mi sitio web: TheBATeam,
4. Escribiendo un artículo sobre ellos,
5. Haciendo un video tutorial sobre ese programa en Youtube,
6. Editando el tutorial para corregir errores durante la grabación,
7. Subiendo el tutorial,
8. Subiendo el programa a mediafire,
9. Unirse al video, Enlace del programa, artículo todos juntos en el sitio web.
10. Y, trabaje a tiempo parcial para escribir un artículo en otro sitio web por mi propio dinero.

Entonces, el tiempo se convierte en un factor importante en mi vida. Como, las 24 horas son limitadas y mis objetivos no lo son. Entonces, estoy manejando las cosas según la cita. 🙂 Por lo tanto, pasar más tiempo en la codificación puede generar más errores, y encontrarlos y solucionarlos lleva más tiempo. Entonces, simplificando las cosas: pienso en el código incluso antes de codificarlo. Lo que hace las cosas fáciles y sin problemas.

¡Espero que esto sea de ayuda! 🙂 Gracias por tu tiempo.

Oh, tengo algunas.

1. Hablar es barato. Muéstrame el código ~ Linus Torvalds
2. Una falacia común es asumir que los autores de códigos incomprensibles podrán expresarse claramente en los comentarios ~ Kevlin Henney
3. La programación es como el sexo. Un error y tienes que soportarlo por el resto de tu vida ~ Michael Sinz
4. Antes de que el software pueda ser reutilizable, primero debe ser utilizable ~ Ralph Johnson
5. Un buen software, como el vino, lleva tiempo ~ Joel Spolsky
6. Un buen código es su propia mejor documentación ~ Steve McConnell
7. Las computadoras son buenas para seguir las instrucciones, pero no para leer tu mente ~ Donald Knuth
8. Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos pueden entender ~ Martin Fowler
9. Medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de aviones por peso ~ Bill Gates
10. No comentes el código incorrecto. Reescribirlo ~ Brian Kernighan
11. Si la depuración es el proceso de eliminar errores, la programación debe ser el proceso de ponerlos en ~ Edsger Dijkstra
12. Primero, resuelve el problema. Luego, escribe el código ~ John Johnson

Fuentes:

Cotizaciones de programación

15 citas inteligentes para mejorar tus habilidades de programación

Más de 25 citas de programación

Cotizaciones de programación

Tengo dos.

“Lo imposible sucede. Planee para ello “.

y…

“El esfuerzo requerido para implementar una característica es inversamente proporcional a lo complejo que el cliente cree que es”.

Ambos son mis personales.

He sorprendido a más de un programador cuando ocurre lo que pensaban que era imposible. “¡Oh, ese objeto nunca puede ser nulo!” O “Esa base de datos siempre estará disponible”. Bufido.

En cualquier lugar donde haya algo crítico en el código, suponga que va a ir hacia el sur. Implemente un manejo robusto de errores. He ido tan lejos como para escribir mensajes de registro que digan “Esto debería ser imposible” y aún así suceden ocasionalmente.

El segundo proviene de una larga experiencia en el trato con personas no técnicas que saben lo suficiente sobre tecnología para hablar de un buen juego pero que, por lo demás, no tienen idea de los detalles. Saber qué es una base de datos no los califica para decirles a los programadores que tienen que usar una o cómo implementarla para una aplicación, por ejemplo.

Cuando solicitan alguna característica nueva y comienzan a hablar sobre todas las cosas que debe hacer, lo complicado que es, etc., es muy probable que usted, como desarrollador, vea el código afectado en su mente y sepa exactamente qué necesita cambiarse antes de que dejen de hablar. Veinte minutos después, en su escritorio, ha terminado y el cliente está asombrado.

El corolario es cuando le dan una solicitud de una oración como “Hacer que el navegador cargue e imprima el texto automáticamente como aparecería en papel”. Luego puedes explicar cortésmente que lo que busca es imposible. Cuando piensen que es simple, ¡abróchate el cinturón porque vas a dar un paseo y no te va a gustar el destino!

Tzu-li y Tzu-ssu se jactaban del tamaño de sus últimos programas. “Doscientas mil líneas”, dijo Tzu-li, “¡sin contar los comentarios!” Tzu-ssu respondió: “Pssh, la mía ya tiene casi un millón de líneas”. El Maestro Yuan-Ma dijo: “Mi mejor programa tiene quinientas líneas”. Al escuchar esto, Tzu-li y Tzu-ssu se iluminaron.

Maestro Yuan-Ma

El libro de la programación

Hay dos formas de construir un diseño de software: una es hacerla tan simple que obviamente no haya deficiencias, y la otra es hacerla tan complicada que no haya deficiencias obvias .

COCHE Hoare,

Conferencia del Premio ACM Turing 1980

Ambos hicieron referencia al maravilloso libro Eloquent JavaScript [1]. (se puede leer solo para las citas)

Notas al pie

[1] JavaScript elocuente

Mi favorito no es específico de la programación sino todas las cosas de la vida.

Soy un programador y emprendedor 100% autodidacta

He creado 4 negocios exitosos basados ​​en Internet a partir de los 13 años.

el más reciente de los cuales es Bases de datos de lugares

Se trata de la persistencia, donde otros dicen “eso probablemente no se puede hacer”, yo digo “déjame averiguar” se trata de intentarlo una y otra vez hasta que encuentres la solución y cuando no tengas idea de qué hacer, tómese un descanso, si aún no tiene una buena idea, simplemente haga una mala, lo descubrirá en el proceso siempre que esté involucrado en la acción y su actitud sea de determinación, enfoque y pasión, tu tendrás exito. La ciencia ha demostrado que creamos nuestra realidad, lo que creemos que es verdadero se manifiesta como verdadero, la física cuántica apoya esta teoría.

BESO

Mantenlo simple estúpido

La simplicidad es muy importante. Incluso si eres muy inteligente y puedes entender cosas complejas, otros no pueden y pueden tener que revisar o modificar tu código.

Las soluciones más simples siempre son mejores, pregunte si vale la pena el esfuerzo?

Además, incluso si es inteligente, es mejor mantener las cosas más simples porque todavía tiene una capacidad limitada.

mi negocio es Bases de datos de lugares

Somos una de las bases de datos de lugares de más alta calidad y más completas disponibles, con más de 152 millones de listados totales, en todos los países y territorios independientes en todo el mundo, con un total de más de 250 países / territorios.

puede analizar datos por ubicaciones y categorías y obtener un presupuesto instantáneo y la opción de compra instantánea de PayPal

• Siempre pase más tiempo diseñando que construyendo. Es mucho más fácil arreglar una falla en el flujo del proceso en una pizarra que después de haber construido todo.
• Mantenlo simple y estúpido. Si no puede explicárselo a un niño pequeño, entonces probablemente no tenga sentido. Este es particularmente útil cuando se trata con un cliente o administración.
• Siempre asuma que la siguiente persona que lee su código es un asesino en serie compulsivo de mal genio. De esa manera harás todo lo posible para mantenerlo feliz. Los comentarios y el buen formato mantienen felices a los asesinos.
• Es mejor mostrar que contar. Si tiene una idea, trabaje primero antes de compartirla. Se sorprenderá de cuántos arrojará a la carpeta “Ideas tontas”. De esa manera solo compartirás los buenos que pasan la investigación de antecedentes. (Este es personal y sé que no muchos están de acuerdo).

“El trabajo de los programadores es implementar una característica que coincida con las especificaciones y funcione de manera eficiente, pero con un costo mínimo de desarrollo y mantenimiento, utilizando un esfuerzo mínimo y en un tiempo mínimo” (y opcionalmente obtener el pago máximo por hacerlo).

Este es un principio que accidentalmente se me ocurrió, que parece cubrir muy bien la aplicación de la programación. En este caso, el costo incluye tanto el costo de mantenimiento de la hormiga de desarrollo, lo que significa que la regla no le permite ser descuidado y apresurado, pero al mismo tiempo, también lo desalienta de distraerse por “problemas sorprendentes” y hacer cosas como la optimización prematura. El principio automáticamente da como resultado el uso del principio KISS / YAGNI y te hace buscar el equilibrio.

Este principio fue una realización importante para mí, porque durante mucho tiempo no hizo clic, que se trata de costos. Desea limpiar su código porque minimiza el costo de mantenimiento. Lo quieres simple porque minimiza el costo de desarrollo. Desea terminar ayer porque minimiza el tiempo de desarrollo. Lo del “esfuerzo mínimo” reduce la posibilidad de “hacer cosas estúpidas con mucha energía”, lo que significa que se recomienda buscar soluciones creativas. Sin embargo, al mismo tiempo, su función debe cumplir con las especificaciones con las que está trabajando. Entonces, “Haz las cosas”.

Probablemente haya una forma más elegante de expresar este principio.

Aquí hay algunos si necesita inspiración.

• Si optimizas todo, siempre serás infeliz. -Donald Knuth
• Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones. -Linus Torvaldes
• Hay que ver un algoritmo para creerlo. -Donald Knuth
• Algoritmos + Estructuras de datos = Programas. -Nicholas Wirth
• La programación es una habilidad que se adquiere mejor con la práctica y el ejemplo en lugar de los libros. -Alan Turing

Aquí hay algunas reglas que siempre tengo en cuenta:

1. Mantente humilde: no estás aquí para mostrar tu nivel técnico al universo, solo eres un desarrollador designado para resolver las necesidades de tus clientes.
2. escuche a su cliente hasta que haya entendido completamente lo que necesita: él sabe lo que necesita, usted no
3. Anticípese razonablemente, abra su mente: verifique si los casos de uso que hoy son imposibles pueden ser posibles en el futuro, y diseñe en consecuencia
4. No seas estúpidamente perezoso, sino inteligentemente perezoso: lee la respuesta de Art Kagel anterior y aléjate del desorden
5. Piense en otras personas que pueden mantener sus desarrollos en el futuro: lo que es obvio para usted en un momento dado probablemente no lo sea para otros, o incluso para usted mismo después de un tiempo.
   Por lo tanto, escriba código limpio y rápidamente comprensible, no sea tímido y comente su código cuando sea necesario
6. Utilice un buen sistema de versiones de código fuente como git, subversion u otros: servirá como un sistema de respaldo de fuente + lo ayudará a mantener el control de la evolución sin romper sus cerebros
7. Acosar su código fuente: prueba, prueba, prueba y prueba! Sé honesto contigo mismo y arréglalo cuando sea necesario. Probablemente la prueba sea más importante que la codificación.

La declaración más profunda que leí en mi vida fue: “ El tonto no sabía que era imposible. Entonces lo hizo. ”

Eso me recuerda a las palabras que hizo famoso el CEO más famoso del mundo, Steve Jobs: “ Mantente hambriento. Mantente tonto “.

Como estamos hablando de tonterías y tontos, me recuerda una cita de Alan Perlis (el creador de ALGOL): “ No vale la pena conocer un lenguaje que no afecta la forma en que piensas sobre la programación. ”

Como estamos en la programación y toda la programación gira en torno a algoritmos, aquí hay una cita del Sr. Dijkstra (si ha estado interesado en la informática y la programación, ya ha oído hablar de este nombre): “Si la depuración es la forma de eliminar errores, la programación debe ser la forma de ponerlos “.

Es famoso por un algoritmo de enrutamiento. Hablando de redes, Sun tenía un dicho (frase clave) que establece lo importante que es comunicarse con los demás y mantener una buena vida social también. La línea era: ” La red es la computadora. ”

Llevo 10 años programando. Incluso entonces tengo dudas sobre si estoy haciendo las cosas bien o no. En caso de duda, a veces vuelvo al zen de Python. Aquí está:

Hermoso es mejor que feo.

Explícito es mejor que implícito.

Simple es mejor que complejo.

Complejo es mejor que complicado.

Plano es mejor que anidado.

Escaso es mejor que denso.

La legibilidad cuenta.

Los casos especiales no son lo suficientemente especiales como para romper las reglas.

Aunque la practicidad supera la pureza.

Los errores nunca deben pasar en silencio.

A menos que sea silenciado explícitamente.

Ante la ambigüedad, rechaza la tentación de adivinar.

Debe haber una, y preferiblemente solo una, forma obvia de hacerlo.

Aunque esa manera puede no ser obvia al principio a menos que seas holandés.

Ahora es mejor que nunca.

Aunque nunca es mejor que * ahora * ahora.

Si la implementación es difícil de explicar, es una mala idea.

Si la implementación es fácil de explicar, puede ser una buena idea.

Los espacios de nombres son una gran idea, ¡hagamos más de eso!

Sobre todo, nada supera al favorito:

“ El tonto no sabía que era imposible. Entonces lo hizo. ”

(^_^)

Los buenos programadores son programadores perezosos. ¿Por qué / cómo?

• Los programadores perezosos escriben y usan bibliotecas porque terminan escribiendo y probando menos código y si hay un error, es el problema de otra persona solucionarlo, o el peor de los casos es el mío porque escribí el código de la biblioteca.
• Los programadores perezosos documentan su código porque es demasiado problema tener que volver a leer el código seis meses después para que pueda comprender por qué hizo lo que hizo cuando tuvo que modificarlo.
• Los programadores perezosos empaquetan código común en funciones que pueden reutilizar para no tener que escribir tanto.
• Los programadores perezosos evitan algoritmos complejos cuando uno simple funcionará. Menos líneas de código para escribir y depurar.

Tienes la idea.