Dado que os programadores são autores e escrevem código para expressar pensamentos e conceitos abstratos, e um bom código deve ser lido por outros programadores sem dificuldades e mal-entendidos, um programador deve ter aulas de redação para escrever um código melhor?

Abstrair conceitos e problemas / entidades do mundo real é uma parte importante da escrita de um bom código, e um bom domínio da linguagem usada para codificação deve permitir que o programador expresse seus pensamentos mais facilmente ou de uma maneira melhor. Além disso, ao tentar escrever ou reescrever algum código para torná-lo melhor, muito tempo pode ser gasto na decisão dos nomes de funções, variáveis ​​ou estruturas de dados.

Eu acho que isso também pode ajudar a evitar a criação de código com mais de um significado, geralmente causa de mal-entendidos entre diferentes programadores. O código deve sempre expressar claramente sua função sem ambiguidade.

1. Aulas de redação? Na verdade não.

Escrever código fonte é diferente o suficiente de escrever um livro.

Embora ambos busquem os mesmos objetivos: sendo o mais inequívoco possível e fáceis de entender, estão fazendo isso de uma maneira muito diferente, e as coisas que um escritor deve aprender não são as mesmas que um desenvolvedor de software deve aprender.

Exemplo 1: figuras de linguagem

As figuras de linguagem são valiosas ao escrever romances, poesias etc., pois aumentam a expressividade da escrita.

Qual foi a última vez que você viu um oxímoro ou litotes no código-fonte ? Ajudaria tê-los ou seria extremamente prejudicial para qualquer desenvolvedor que precisará manter esse código-fonte mais tarde?

Exemplo 2: vocabulário

Vocabulário rico é muito apreciado na literatura. O vocabulário de William Shakespeare, por exemplo, é de vinte mil a vinte e cinco mil palavras. Um vocabulário mais rico torna mais interessante a leitura de um romance ou poema.

Quando você escreve o código-fonte, espera que seja lido por pessoas que não falam inglês muito bem . Mostrar quão bem você conhece o inglês seria extremamente prejudicial para o seu código. Se você conhece uma palavra sofisticada que significa exatamente o que precisa, mas sabe que muitas pessoas não sabem o significado dessa palavra, deve encontrar um sinônimo menos expressivo ou um conjunto de palavras que expliquem o significado. Um vocabulário de alguns milhares de palavras geralmente é suficiente para um determinado projeto.

Observe um aspecto importante: embora o Google Translate possa ser de grande ajuda para um falante não-nativo, há dois problemas com qualquer tradutor:

• Um par de idiomas não tem necessariamente uma correspondência de 1: 1 entre as palavras. Algumas palavras não têm tradução em outros idiomas, ou várias palavras podem se traduzir em uma única palavra em um idioma estrangeiro. Por exemplo, em russo, há uma quantidade enorme de palavras direcionadas a estados específicos de neve e clima frio, e traduzi-las em francês ou espanhol é geralmente impossível sem perder sua especificidade.

• Às vezes, uma palavra tem vários significados e o significado é deduzido do contexto. O Google Translate, apesar de sua alta qualidade, geralmente não pode indicar o significado de nenhuma das situações mais básicas.

Exemplo 3: expressões

As expressões também tornam a prosa mais rica. Um autor espera que o leitor tenha uma certa quantidade de cultura geral e aproveita essa oportunidade para tornar o texto mais expressivo.

Da mesma forma que no exemplo anterior, essas expressões podem ser muito problemáticas quando lidas por pessoas que não são falantes nativos. Mas se o vocabulário geral geralmente pode ser traduzido, as expressões são muito mais problemáticas.

Por exemplo, o inglês não é meu primeiro idioma e, diariamente, encontro expressões, inclusive aqui no StackExchange, que não conheço. Eu tento adivinhar o significado deles, e às vezes estou certo. Mas às vezes eu estou errado, e pesquisar essas expressões no Google não ajuda.

Um usuário em seu comentário me lembrou um exemplo que me fez sofrer por um longo tempo quando comecei a programar: a agulha do PHP e palheiro . Eu não tinha conhecimento da figura correspondente do discurso, portanto, toda vez que estava lendo a documentação, fiquei pensando sobre o que é isso. Desnecessário dizer que os C # sequence.Contains(element)ou os excelentes Python element in sequencesão uma alternativa muito melhor. Bem, pelo menos, os desenvolvedores que não sabem hebraico também tiveram que sofrer de PHP , mas essa é uma história diferente.

Exemplo 4: referências culturais

Referências culturais. Na literatura, é tentador incluir elementos de uma determinada cultura, e isso também torna o livro mais rico e, às vezes, mais interessante de ler.

No entanto, o código é endereçado a desenvolvedores de todo o mundo. Portanto, o que é uma referência óbvia para um desenvolvedor italiano pode não ser tão óbvio para um russo, e o que todo garoto ou garota indiana conhece pode não ser necessariamente conhecido por um programador americano.

O mesmo usuário que falou sobre a agulha e o palheiro também deu um excelente exemplo dessa referência cultural: o Graal. Quem não sabe o que é Graal? Bem, quero dizer, é "Graal" em francês, "Grial" em espanhol e ... "Kutsal Kâse" em turco, mas ainda assim. No entanto, quantos desenvolvedores americanos ou europeus conhecem a história medieval da China ou da Índia? Por que alguém presumiria que todo programador chinês e indiano precisa conhecer a referência do Santo Graal?

2. Lições para escrever código fonte expressivo? Certo.

• Qualquer desenvolvedor deve aprender a escrever código fonte expressivo.

• Qualquer desenvolvedor deve explicar por que o comentário está em:

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

  é ruim, mesmo aparte do fato de estar totalmente errado.

• Qualquer desenvolvedor deve entender a refatoração básica e como isso ajuda a tornar o código fonte mais expressivo.

• Qualquer desenvolvedor deve lembrar que 20% do tempo é gasto desenvolvendo código e 80% do tempo mantendo-o. Para alguns projetos, é mais como 5% - 95%.

• etc.

Em essência, a programação está próxima da documentação técnica. Uma pessoa que escreve uma folha de especificações para um parafuso precisa ter aulas de redação? Na verdade não. O mesmo se aplica aos desenvolvedores. Qualquer pessoa deve escrever sem cometer erros de ortografia em todas as palavras, e qualquer pessoa deve poder comunicar suas idéias com clareza suficiente. Além disso, não tenho certeza de como as aulas de redação seriam mais úteis do que, digamos, um curso de ciência da computação ou segurança de TI ou qualquer outra coisa.

A expressividade do código fonte pode ser aprendida por outros meios. superM mencionou um deles em sua resposta : ler um bom código. Eu posso mencionar alguns outros:

• Lendo livros como Beautiful Code ou Code Complete,

• Solicitando que um desenvolvedor mais experiente revise seu código,

• Compreender padrões e como e quando usá-los.

um programador deve ter aulas de redação para escrever um código melhor?

Não. Um programador deve ter aulas de redação para aprender a escrever uma prosa melhor. Um programador deve ter aulas de programação para aprender a escrever um código melhor. Apesar de algumas semelhanças, escrever prosa e escrever código são bem diferentes.

Isso não quer dizer que os programadores não devam ter aulas de redação. Eles deviam! Algumas razões:

• Escrever é uma habilidade essencial para qualquer pessoa educada. Você parecerá mais inteligente se conseguir escrever bem.

• Apesar de seus melhores esforços, os programadores frequentemente precisam se comunicar com outros seres humanos, geralmente usando a palavra escrita.

• Você aprende habilidades além da escrita nas aulas de redação, e essas são geralmente úteis para os programadores. Por exemplo, você aprenderá a discutir o trabalho de outras pessoas sem ferir seus sentimentos, e aprenderá a aceitar críticas de outras pessoas sem levar para o lado pessoal.

Meu código depende cada vez mais da criação de um vocabulário compartilhado entre os negócios e as equipes técnicas. Eu diria que melhorar suas habilidades de escrita pode ajudar a reduzir a ambiguidade e mal-entendidos nesses esforços, mas não é provável que ajude a expressividade do seu código.

A noção literária de expressividade não é a mesma que a noção de expressividade de programação. Em muitos casos, a ambiguidade na linguagem pode ser usada como um dispositivo literário, mesmo na não ficção, de uma forma que aumenta a expressividade, porque desencadeia várias associações culturais, linguísticas e simbólicas no leitor, intencionais e não intencionais. Esse tipo de expressividade não é desejável na programação; abstração é mais valiosa que ambiguidade. Na programação, a abstração aumenta a flexibilidade, talvez com algum custo de carga cognitiva. A abstração na forma literária pode ter o oposto do efeito que tem na programação: quanto mais abstrata sua escrita, maior a probabilidade de o leitor ter a percepção de que você não está dizendo nada. Todos os símbolos e associações que resultam da fala concreta têm valor,

No entanto, um programador não é uma máquina. Os seres humanos se beneficiam de maneiras muitas vezes inesperadas do crescimento intelectual e emocional. Melhorar sua escrita pode resultar em maior empatia do cliente, porque você se força a enfrentar os desafios da comunicação; talvez você sinta esse cliente que diz o que quer, depois o entrega e ele percebe que não é o que eles precisam. Talvez você apenas aprenda a se concentrar no que não foi dito.

Talvez aprender a jogar argila em uma roda de oleiro o ajude a começar a ver paralelos entre artesanato e desenvolvimento de software. Estudar a maneira como os arquitetos da construção se comunicam pode levar a uma apreciação mais forte da construção de um vocabulário de padrões de design em programação. O estudo da biologia pode levar a idéias fascinantes sobre como as formigas e as abelhas encontram e se comunicam sobre as fontes de alimentos e como esses mecanismos simples podem ser traduzidos em algoritmos de busca de caminhos.

Aprender coisas fora do seu domínio principal vale a pena porque pessoas curiosas são melhores desenvolvedores do que pessoas que não são.

Pelo que vale, eu era quase um especialista em literatura; Acabei mudando para Estudos da Ásia Oriental, porque estava mais interessado nas aulas que ministrava naquele departamento. Há uma chance de eu não estar na indústria se não tivesse estudado Estudos do Leste Asiático, porque o efeito colateral de estudar japonês me tornou mais valioso na época, quando uma empresa de software me contratou em parte devido a habilidades linguísticas. Eu ainda tinha que criar um portfólio mais profundo de habilidades técnicas, mas os efeitos colaterais não intencionais de aprender qualquer coisa podem torná-lo um profissional de software melhor e mais relevante.

Quando os projetos de programação falham, geralmente ocorre devido à falha na comunicação, geralmente em torno dos requisitos. Embora uma compreensão medíocre do inglês possa ser suficiente para escrever código, ser um bom comunicador é essencial para escrever o código certo. Nesta era da comunicação baseada em texto e de trabalho remoto, a escrita em inglês é uma habilidade de comunicação muito importante.

Dito isto, sua pergunta é escrita de uma maneira muito clara e concisa - melhor do que a maioria dos programadores com quem trabalhei. Não tendo visto seu código, sugiro que você se concentre em se expressar na linguagem de codificação de sua escolha. Para Java, recomendo o livro de Joshua Bloch, "Effective Java".

Como escritores são ensinados lendo clássicos do mundo, os programadores são educados lendo boas códigos. Mas há um pequeno problema. Embora existam gigantes reconhecidos na literatura, existem poucos na programação. E se houver, eles podem "falar" um idioma diferente. (Não tenho certeza de que seja razoável aconselhar a leitura do código-fonte Minix por Tanenbaum)

Existem muitas maneiras populares de tornar o código mais legível (=> manutenciável), como escrever comentários, dar nomes significativos etc. Além disso, muitas empresas estabelecem suas regras para escrever código, e isso facilita tudo.

De qualquer forma, como muitos escritores excelentes, os programadores nunca estão felizes com seu próprio código. Portanto, saber quando parar é tão importante quanto escrever código de qualidade.

Eu sempre acho que parar depois de cada pedaço de código que você escreve e lê-lo novamente, imaginando que você nunca viu isso antes, me leva muito longe com isso.

Melhor ainda é pedir a um amigo que esteja familiarizado com a programação que leia seu código sem dizer o que ele faz.

Eu não acho que isso vai ajudar; a escrita criativa é sobre tramas e desenvolvimento e diálogo de personagens, não sobre expressar conceitos técnicos com clareza. A escrita técnica pode ajudar, mas duvido - são apenas tipos muito diferentes de escrita!

e observe que o código "legível" é subjetivo e, principalmente, uma questão de estilo sintático e expressões comuns (que variam entre idiomas e até entre equipes)

escolher bons nomes para variáveis ​​e classes e métodos, no entanto, é importante. Todo desenvolvedor se torna, até certo ponto, um especialista no assunto em certos aspectos do domínio em desenvolvimento; portanto, o uso correto da terminologia do domínio é fundamental.

revisões por pares podem ajudá-lo a criar vocabulário e confiança

Certamente há uma grande diferença entre escrever código e escrever em prosa.

Na prosa, as frases são conectadas (ou separadas) pelo tempo (da maneira que elas se seguem para alcançar um fim ou significado), mas no código (eficiente) você pode (re) carregar partes da 'história' de tabelas com repetições ações / respostas. Portanto, a interação com o leitor (em prosa) ou usuário (de código) é totalmente diferente.

De outra maneira, escrever prosa 'legal' e escrever código 'legal' são semelhantes: aprender a escrever (código ou prosa) é um processo que envolve muitos erros (ou pensar / testar melhorias ou reformular) para obtê-lo ' elegante'.

Eu acho que o sistema periódico químico de elementos é elegante, por causa da maneira muito compacta que descreve algumas propriedades fundamentais dos materiais básicos que usamos, um pouco como código eficiente, mas certamente não é prosa. Uma piada tem muitas qualidades em prosa (levando você a um certo humor, mantendo-o e depois mudando, quando inesperado), mas essa é uma prática terrível de codificação.

Mas ambos os tipos de escrita pedem habilidade.

inglês básico e gramática são suficientes para um programador do meu ponto de vista. Mas qualquer coisa que interrompa uma rotina de programação monótona será sempre rejuvenescedora e, portanto, as lições de redação serão relaxantes para os programadores.