Codificação como um tipo de escrita

May 10 2023

O que os desenvolvedores de software podem aprender com os autores de prosa

Há um lugar onde o rio Snake, em Wyoming, se curva para o norte, se alarga e diminui. Os alces navegam nos nenúfares, os pelicanos pescam, as lontras brincam.

Há um lugar onde o rio Snake, em Wyoming, se curva para o norte, se alarga e diminui. Os alces navegam nos nenúfares, os pelicanos pescam, as lontras brincam. Então o rio se curva sobre si mesmo e retoma sua jornada para o oeste em direção às montanhas.

Você verá o mesmo caminho circular se olhar para minha carreira até agora. Sou um desenvolvedor de software que virou professor de humanidades que voltou a ser desenvolvedor de software. Entre a engenharia e as humanidades existe uma distância bem conhecida, mas já a percorri o suficiente para saber que é mais curta do que as pessoas pensam. Ao longo do caminho, notei que alguns dos conselhos que os autores de prosa fornecem também podem ser valiosos para os autores de software, quase como se escrever código fosse uma forma de escrita.¹

Certa vez, precisei fazer uma pequena função que adiciona um item a um array, mas remove o item se ele já estiver lá. Assim:

toggle([], 1) // should return [1]
toggle([1], 1) // should return []

import _ from "lodash";
const toggle = (arr, item) => _.xor(arr, [item]);

Logo, porém, lembrei-me de algumas palavras de conselho: “Leia suas redações e, sempre que encontrar uma passagem que considere particularmente boa, elimine-a”. Essa é uma dica de Samuel Johnson, ensaísta do século XVIII.³ O formigamento da esperteza, percebi, era uma pista de que eu deveria simplificar minha função. Eu mudei para:

const toggle = (arr, item) =>
   arr.includes(item) ?
   arr.filter((x) => item !== x) :
   [...arr, item];

Na minha opinião: não.⁴ Embora mais complexa em certos aspectos, a nova função provavelmente ainda seria mais clara para o codificador médio e, portanto, mais fácil de manter. Uma linha de código pode ser sintaticamente simples, mas confusa, ou clara, mas sintaticamente complexa. Assim como uma linha de prosa. Pense na frase: “Por que você trouxe aquele livro que eu não quero que leia?”⁵ Ela tem uma sintaxe complicada, mas é muito mais inteligível do que, digamos, a frase sintaticamente simples, “ O myrmecobius absquatulou. Embora não fosse mais lacônico, minha nova função era mais fácil de ler.

Se ele conhecesse JavaScript, o próprio rei da prosa lacônica poderia ter desaprovado a versão mais concisa de toggle. “Hemingway” — o rei em questão — “não leva você ao dicionário”, disse certa vez F. Scott Fitzgerald com apreço.⁶ Se tivesse usado xor, minha função teria levado a maioria dos leitores à documentação. Sem ela, a função fica mais desdobrada, explícita e, por isso, mais autoexplicativa.⁷

O termo lacônico vem dos espartanos da antiguidade, que viviam em uma região chamada Lacônia e não desperdiçavam palavras. Certa vez, um inimigo escreveu para eles: “Se eu invadir a Lacônia, vou expulsá-los desta terra”. Eles responderam: “Se.”⁸

Um preceito sobre a escrita que admiro não vem de um romancista ou jornalista, mas de um designer de museu. Uma boa redação, de acordo com Edwin Schlossberg, “cria um contexto no qual outras pessoas podem pensar”.⁹ Isso os ajuda a imaginar, refletir e responder. Isso lhes dá espaço para fazê-lo - como uma exibição de museu. De maneira semelhante, um bom código abre espaço para os leitores, por assim dizer. Isso os ajuda a raciocinar.

Geralmente faz sentido, então, para um autor de código seguir padrões que o leitor médio já entende bem. Embora a maioria dos desenvolvedores de JavaScript esteja familiarizada com o ternário (o ponto de interrogação e os dois pontos) usado acima, muitos se sentem ainda mais confortáveis com um bloco if-else, como este:

const toggle = (arr, item) => {
   if (arr.includes(item)) {
      return arr.filter((x) => item !== x);
   } else {
      return [...arr, item];
   }
}

Os autores devem ter empatia por seus leitores, e você também deve ter empatia pelas pessoas que manterão, depurarão ou adaptarão seu código. Como você é o autor, porém, é normal ter problemas para se colocar no lugar de seus leitores. Experimente duas técnicas emprestadas dos melhores escritores.

Primeiro, Helen Sword sugere que você “visualize pessoas específicas olhando por cima do seu ombro enquanto escreve”. Afinal, “os escritores mais envolventes são quase invariavelmente aqueles que prestam mais atenção às pessoas reais – especialistas e não especialistas, colegas e estranhos – em cujos ouvidos suas próprias palavras ecoarão.”¹¹ Conselho sábio também para programadores.

Uma segunda técnica: deixe seu código de lado por um ou dois dias, se puder, e depois volte a ele. “Termine o conto, imprima-o, coloque-o em uma gaveta e escreva outras coisas”, Neil Gaiman disse certa vez a um aspirante a escritor. “Quando estiver pronto, pegue-o e leia-o, como se nunca o tivesse lido antes. Se há coisas com as quais você não está satisfeito como leitor, entre e conserte-as como escritor: isso é revisão.”¹² O antigo autor Quintiliano também recomendava que “deixássemos de lado o que escrevemos por um certo tempo”—

de modo que, quando retornarmos a ele após um intervalo, ele terá o ar de novidade e de obra de outrem; pois assim podemos nos impedir de considerar nossos escritos com todo o afeto que esbanjamos em uma criança recém-nascida. ¹³

Não é muito surpreendente que a orientação escrita possa ser adaptada para símbolos de um tipo diferente. Áreas de conhecimento muitas vezes se infiltram umas nas outras, ou como o romancista Charles Johnson diz lindamente:

Uma forma de expressão artística e intelectual nutre e alimenta as outras. O que quer que chamemos de criatividade e imaginação – esses dois grandes mistérios – pode ser para alguns criadores experimentados como “globais” em suas vidas, não localizados em uma única forma de expressão, mas sim se espalhando ou derramando de um gênero para outro, um artístico ou disciplina intelectual para outra, pois todas as humanidades (juntamente com as ciências) estão relacionadas, interligadas. ¹⁴

Experimentar sua própria codificação com as abordagens recomendadas aqui pode exigir uma mudança em sua rotina. Um desvio, para que você, como o rio, desacelere e fique mais reflexivo, mais generoso. Então pegue uma página do rio. Não segue um caminho linear.

A analogia da codificação-escrita tem suas limitações, com certeza. Por exemplo, as contradições são praticamente proibidas no código-fonte, e é na arte, particularmente na poesia, que elas obtêm sua justiça. Há um poema de Fernando Pessoa que gosto de ler em voz alta, embora não saiba português. Isso começa:

O poeta é um fingidor
Finge tão completamente
Que chega a fingir que é dor
A dor que deveras sente.

Poeta é aquele que finge.
Ele finge tão completamente o real
Ele até finge as terríveis dores
E sofrimentos que ele sente.¹⁵

Pessoa está nos convidando a deixar momentaneamente de lado as ideias convencionais de verdadeiro e falso. Ele afirma abertamente uma contradição: os poetas se escondem atrás de seus poemas e, ao fazê-lo, tornam-se visíveis através deles. Deixando a lógica booleana para trás, Pessoa inventa uma lógica própria. “Poeta é aquele que finge”: o que isso significa, senão “estou inventando tudo o que estou dizendo – é tudo falso, inclusive essas mesmas palavras”? Esta é uma afirmação auto-refutável, uma falsidade lógica. Mas se você olhar através das palavras para suas raízes etimológicas, “O poeta é um fingidor” significa “Um criador é um criador”. Uma verdade lógica. Como a dor simulada que ele menciona, a afirmação do poeta é falsa na superfície, verdadeira por baixo. Código e poesia oferecem estratégias complementares para lidar com um mundo muitas vezes ilógico: um fornece refúgio de contradições,

notas de rodapé

[1]: A analogia de codificação e escrita foi feita antes, embora de forma diferente, por Brian Kernighan e PJ Plauger , Donald Knuth , Richard Gabriel , James Devlin , Jeff Atwood e Rebecca Sutton Koeser , entre outros. Steve McConnell critica a analogia.

[2]: Aqui está um exemplo da função lodashda biblioteca xorem ação. No Boggle você procura palavras em uma grade de letras. Se você encontrar uma palavra que ninguém mais encontrou, você ganha pontos por ela. Suponha que você esteja fazendo uma versão do jogo em JavaScript. Você tem esses dados:

const wordsFoundByPlayerOne = ["apple", "peel"];
const wordsFoundByPlayerTwo = ["apple", "leap"];
const wordsFoundByPlayerThree = ["apple", "able"];

_.xor(
   wordsFoundByPlayerOne,
   wordsFoundByPlayerTwo,
   wordsFoundByPlayerThree
); // Output: ["peel", "leap", "able"]

[4]: Também podemos criar uma alternativa altamente legível com a ajuda de Set:

const toggle = (arr, item) => {
  const set = new Set(arr);
  if (set.has(item)) set.delete(item);
  else set.add(item);
  return Array.from(set);
}

[6]: Citado pelo técnico de redação Gary Gilson em um artigo de 2019 .

[7]: Por outro lado, o blogueiro Jeff Atwood promoveu a “ programação espartana ”.

[8]: Plutarch, On Talkativeness .

[9]: Citado pelo físico Konstantin Likharev em um livro de 2021 .

[10]: Em sua palestra de 2012 “Simplicity Matters”, Rich Hickey argumenta que os programadores não devem temer a dificuldade , em parte porque torna nosso trabalho interessante. Mas nosso trabalho será mais interessante se cair na zona de Cachinhos Dourados entre chato e cansativo - como é o caso das aulas escolares .

[11]: Helen Sword, Stylish Academic Writing (2012), p. 44. Para melhorar sua clareza, muitos escritores leem seus trabalhos em voz alta, ouvindo a si mesmos. O filósofo Jonathan Bennett escreve : “Gilbert Ryle uma vez me disse: 'O que não é bom para o ouvido não é bom para o olho', e isso mudou minha vida. Mais do que qualquer outra coisa, esse insight me mostrou como começar a sair da lixeira para a planície da prosa decente.” Kernighan e Plauger oferecem uma visão semelhante sobre programação: “Uma maneira útil de decidir se algum trecho de código está claro ou não é o 'teste do telefone'. Se alguém pudesse entender seu código quando lido em voz alta pelo telefone, seria claro o suficiente. Se não, então ele precisa ser reescrito” ( Elements of Programming Style , p. 21).