Dado que los programadores son autores y escriben código para expresar pensamientos y conceptos abstractos, y que otros programadores deben leer un buen código sin dificultades ni malentendidos, ¿debería un programador tomar lecciones de escritura para escribir un código mejor?

Resumir conceptos y problemas / entidades del mundo real es una parte importante de la escritura de un buen código, y un buen dominio del lenguaje utilizado para la codificación debería permitir al programador expresar sus pensamientos más fácilmente o de una mejor manera. Además, al intentar escribir o reescribir algún código para mejorarlo, se puede dedicar mucho tiempo a decidir los nombres de las funciones, variables o estructuras de datos.

Creo que esto también podría ayudar a evitar escribir código con más de un significado, a menudo causa de malentendidos entre diferentes programadores. El código siempre debe expresar claramente su función sin ambigüedades.

1. ¿Lecciones de escritura? Realmente no.

Escribir el código fuente es lo suficientemente diferente de escribir un libro.

Si bien ambos persiguen los mismos objetivos: ser tan ambiguos como sea posible y fáciles de entender, lo están haciendo de una manera muy diferente, y las cosas que un escritor debe aprender no son lo mismo que un desarrollador de software debería aprender.

Ejemplo 1: figuras retóricas

Las figuras retóricas son valiosas al escribir novelas, poesía, etc., ya que aumentan la expresividad de la escritura.

¿Cuál es la última vez que has visto un oxímoron o un litotes en el código fuente ? ¿Sería útil tenerlos, o preferiría ser extremadamente perjudicial para cualquier desarrollador que tendrá que mantener dicho código fuente más adelante?

Ejemplo 2: vocabulario

El vocabulario rico es muy apreciado en la literatura. El vocabulario de William Shakespeare, por ejemplo, es de veinte mil a veinticinco mil palabras. Un vocabulario más rico hace que sea más interesante leer una novela o un poema.

Cuando escribe el código fuente, espera que sea leído por personas que no hablan inglés muy bien . Mostrar qué tan bien sabes inglés sería extremadamente dañino para tu código. Si conoce una palabra elegante que significa exactamente lo que necesita pero sabe que muchas personas no saben el significado de esta palabra, debería encontrar un sinónimo menos expresivo o un conjunto de palabras que expliquen el significado. Un vocabulario de unos pocos miles de palabras suele ser suficiente para un proyecto determinado.

Tenga en cuenta un aspecto importante: aunque Google Translate podría ser de gran ayuda para un hablante no nativo, hay dos problemas con cualquier traductor:

• Un par de idiomas no necesariamente tienen una coincidencia 1: 1 entre las palabras. Algunas palabras no tienen traducción en otros idiomas, o varias palabras podrían traducirse en una sola palabra en un idioma extranjero. Por ejemplo, en ruso, hay una gran cantidad de palabras que apuntan a estados específicos de nieve y clima frío, y traducirlas en francés o español generalmente es imposible sin perder su especificidad.

• Una palabra a veces tiene múltiples significados, y el significado se deduce del contexto. El Traductor de Google, a pesar de su alta calidad, generalmente no puede indicar el significado de ninguna de las situaciones más básicas.

Ejemplo 3: expresiones

Las expresiones enriquecen la prosa también. Un autor espera que un lector tenga una cantidad determinada de cultura general, y aprovecha esta oportunidad para hacer que el texto sea más expresivo.

De manera similar al ejemplo anterior, tales expresiones podrían ser muy problemáticas cuando las leen personas que no son hablantes nativos. Pero si el vocabulario general generalmente se puede traducir, las expresiones son mucho más problemáticas.

Por ejemplo, el inglés no es mi lengua materna y, a diario, encuentro expresiones, incluso aquí en StackExchange, que no sé. Trato de adivinar su significado, y a veces tengo razón. Pero a veces me equivoco, y buscar esas expresiones en Google no ayuda.

Un usuario en su comentario me recordó un ejemplo que me hizo sufrir durante mucho tiempo cuando recién comencé a programar: la aguja y el pajar de PHP . No tenía conocimiento de la forma de hablar correspondiente, así que cada vez que leía la documentación, me preguntaba de qué se trata todo esto. No hace falta decir que los C # sequence.Contains(element)o el excelente Python element in sequenceson una alternativa mucho mejor. Bueno, al menos, los desarrolladores que no saben hebreo también tuvieron que sufrir PHP , pero esta es una historia diferente.

Ejemplo 4: referencias culturales

Referencias culturales. En la literatura, es tentador incluir elementos de una cultura determinada, y esto también hace que el libro sea más rico y, a veces, más interesante de leer.

Sin embargo, el código está dirigido a desarrolladores de todo el mundo. Por lo tanto, lo que es una referencia obvia para un desarrollador italiano puede no ser tan obvio para un desarrollador ruso, y lo que todo niño o niña indio sabe no necesariamente debe ser conocido por un programador estadounidense.

El mismo usuario que habló sobre la aguja y el pajar también dio un excelente ejemplo de referencia cultural: el Grial. ¿Quién no sabe qué es Grial? Bueno, quiero decir, es "Graal" en francés, "Grial" en español y ... "Kutsal Kâse" en turco, pero aún así. Sin embargo, ¿cuánto conocen los desarrolladores estadounidenses o europeos la historia medieval de China o India? ¿Por qué alguien asumiría que todo programador chino e indio tiene que conocer la referencia del Santo Grial?

2. ¿Lecciones para escribir código fuente expresivo? Seguro.

• Cualquier desarrollador debe aprender a escribir código fuente expresivo.

• Cualquier desarrollador debe explicar por qué el comentario en:

  int j = i + 1; // Creating i and adding 1 to it.
  

  es malo, incluso dejando de lado el hecho de que está totalmente mal.

• Cualquier desarrollador debe poder comprender la refactorización básica y cómo ayuda a hacer que el código fuente sea más expresivo.

• Cualquier desarrollador debe recordar que el 20% del tiempo se dedica a desarrollar código y el 80% del tiempo a mantenerlo. Para algunos proyectos, es más como 5% - 95%.

• etc.

En esencia, la programación está cerca de la documentación técnica. ¿Una persona que escribe una hoja de especificaciones para un perno necesita tomar lecciones de escritura? Realmente no. Lo mismo se aplica para los desarrolladores. Cualquiera debería escribir sin cometer errores ortográficos en cada palabra, y cualquiera debería poder comunicar sus ideas con suficiente claridad. Aparte de eso, no estoy seguro de cómo escribir lecciones sería más útil que, digamos, un curso de informática o seguridad informática o lo que sea.

La expresividad del código fuente se puede aprender por otros medios. SuperM mencionó uno de ellos en su respuesta : leer un buen código. Puedo mencionar algunos otros:

• Leyendo libros como Beautiful Code o Code Complete,

• Solicitando a un desarrollador más experimentado que revise su código,

• Comprender los patrones y cómo y cuándo usarlos.

¿Debería un programador tomar lecciones de escritura para escribir mejor código?

No. Un programador debería tomar lecciones de escritura para aprender a escribir mejor en prosa. Un programador debe tomar lecciones de programación para aprender a escribir un mejor código. A pesar de algunas similitudes, escribir prosa y escribir código son bastante diferentes.

Eso no quiere decir que los programadores no deberían tomar clases de escritura. ¡Ellos deberían! Algunos motivos:

• La escritura es una habilidad esencial para cualquier persona educada. Pareces más inteligente si puedes escribir bien.

• A pesar de sus mejores esfuerzos, los programadores con frecuencia necesitan comunicarse con otros humanos, a menudo usando la palabra escrita.

• Aprendes habilidades más allá de la escritura en clases de escritura, y esas suelen ser útiles para los programadores. Por ejemplo, aprenderá a hablar sobre el trabajo de otras personas sin herir sus sentimientos, y aprenderá a aceptar las críticas de los demás sin tomarlas personalmente.

Mi código depende cada vez más de crear un vocabulario compartido entre la empresa y los equipos técnicos. Diría que mejorar sus habilidades de escritura puede ayudarlo a reducir la ambigüedad y los malentendidos en estos esfuerzos, pero que no es probable que ayude a la expresividad de su código.

La noción literaria de expresividad no es lo mismo que la noción de programación de expresividad. En muchos casos, la ambigüedad en el lenguaje puede usarse como un recurso literario, incluso en la no ficción, en una forma que aumenta la expresividad, ya que desencadenará diversas asociaciones culturales, lingüísticas y simbólicas en el lector, tanto intencionadas como no intencionadas. Este tipo de expresividad no es deseable en la programación; La abstracción es más valiosa que la ambigüedad. En programación, la abstracción aumenta la flexibilidad con quizás algún costo de carga cognitiva. La abstracción en forma literaria puede tener el efecto opuesto al que tiene en la programación: cuanto más abstracta sea su escritura, más probable será que el lector tenga la percepción de que no está diciendo nada. Todos esos símbolos y asociaciones que resultan del discurso concreto tienen valor,

Sin embargo, un programador no es una máquina. Los seres humanos se benefician de maneras a menudo inesperadas del crecimiento intelectual y emocional. Mejorar su escritura puede resultar en una mayor empatía con el cliente porque se obliga a luchar con desafíos de comunicación; quizás sientas por ese cliente que dice lo que quiere, luego lo entregas y se dan cuenta de que no es lo que necesitan. Quizás aprendas a concentrarte en lo que no se dice.

Tal vez aprender a tirar arcilla en una rueda de alfarería lo ayudará a comenzar a ver paralelismos entre la artesanía y el desarrollo de software. Estudiar la forma en que los arquitectos de la construcción se comunican podría llevarlo a tener una mayor apreciación por construir un vocabulario de patrones de diseño en la programación. Estudiar biología podría llevarlo a obtener fascinantes ideas sobre cómo las hormigas y las abejas encuentran y se comunican sobre las fuentes de alimentos y cómo esos mecanismos simples podrían traducirse en algoritmos de búsqueda de caminos.

Vale la pena aprender cosas fuera de su dominio principal porque las personas curiosas son mejores desarrolladores que las que no lo son.

Por lo que vale, era casi un especialista en literatura; Terminé cambiándome a Estudios de Asia Oriental porque estaba más interesado en las clases que estaba tomando en ese departamento. Existe la posibilidad de que no estaría en la industria si no hubiera estudiado Estudios de Asia Oriental, porque el efecto secundario de estudiar japonés me hizo más valioso en ese momento, cuando una compañía de software me contrató en parte debido a las habilidades lingüísticas. Todavía tenía que construir una cartera más profunda de habilidades técnicas, pero los efectos secundarios no deseados de aprender cualquier cosa pueden convertirlo en un profesional de software mejor y más relevante.

Cuando los proyectos de programación fallan, generalmente se debe a una comunicación fallida, generalmente en torno a los requisitos. Aunque una comprensión mediocre del inglés puede ser suficiente para escribir código, ser un buen comunicador es esencial para escribir el código correcto. En esta era de comunicación remota basada en texto, la escritura en inglés es una habilidad de comunicación muy importante.

Dicho esto, su pregunta está escrita de una manera muy clara y concisa, mejor que la mayoría de los programadores con los que he trabajado. Al no haber visto su código, le sugiero que se concentre en expresarse en el lenguaje de codificación que elija. Para Java, recomiendo el libro de Joshua Bloch, "Java efectivo".

Al igual que los escritores aprenden leyendo los clásicos del mundo, los programadores se educan leyendo un buen código. Pero hay un pequeño problema. Si bien hay gigantes reconocidos en la literatura, hay pocos de ellos en la programación. Y si los hay, podrían "hablar" un idioma diferente. (Ni siquiera estoy seguro de que sea razonable recomendar leer el código fuente de Minix por Tanenbaum)

Hay muchas formas populares de hacer que el código sea más legible (=> mantenible), como escribir comentarios, dar nombres significativos, etc. Además, muchas compañías establecen sus reglas de escritura de código, y esto hace que todo sea mucho más fácil.

De todos modos, como muchos escritores excelentes, los programadores nunca están contentos con su propio código. Por lo tanto, saber cuándo detenerse es tan importante como escribir código de calidad.

Siempre encuentro que parar simplemente después de cada bit de código que escribes y leerlo nuevamente, imaginando que nunca lo has visto antes, me ayuda mucho con esto.

Aún mejor es pedirle a un amigo que esté familiarizado con la programación que lea su código sin decirle lo que hace.

No creo que eso ayude; la escritura creativa se trata de tramas y desarrollo de personajes y diálogo, no se trata de expresar conceptos técnicos con claridad. La escritura técnica puede ayudar, pero lo dudo, ¡son tipos de escritura muy diferentes!

y tenga en cuenta que el código "legible" es subjetivo, y principalmente una cuestión de estilo sintáctico y modismos comunes (que varían entre idiomas e incluso entre equipos)

elegir buenos nombres para variables y clases y métodos, sin embargo, es importante. Cada desarrollador se convierte, hasta cierto punto, en un experto en la materia en ciertos aspectos del dominio en desarrollo, por lo que el uso correcto de la terminología del dominio es fundamental.

Las evaluaciones por pares pueden ayudarlo a desarrollar vocabulario y confianza

Ciertamente hay una gran diferencia entre escribir código y escribir prosa.

En prosa, las oraciones están conectadas (o separadas) por el tiempo (la forma en que se siguen entre sí para llegar a un final o significado) pero en el código (eficiente) puede (re) cargar partes de la 'historia' desde tablas con repetibles acciones / respuestas. Entonces, la interacción con el lector (en prosa) o el usuario (de código) es totalmente diferente.

De otra manera, escribir prosa "agradable" y escribir código "agradable" son similares: aprender a escribir (código o prosa) es un proceso que implica cometer muchos errores (o pensar / probar sobre mejoras o reformular) para obtenerlo " elegante'.

Creo que el sistema químico periódico de elementos es elegante, debido a la forma muy compacta que describe algunas propiedades fundamentales de los materiales básicos que utilizamos, un poco como un código eficiente, pero ciertamente no es prosa. Un chiste tiene muchas cualidades de prosa (te pone en un cierto estado de ánimo, mantiene ese estado de ánimo y luego lo cambia, cuando es inesperado), pero esa es una práctica de codificación horrible.

Pero ambos tipos de escritura piden artesanía.

Inglés básico y gramática es suficiente para un programador desde mi punto de vista. Pero cualquier cosa que rompa una rutina de programación monótona siempre será rejuvenecedora, por lo que las lecciones de escritura serán relajantes para los programadores.