Nomear bem é pensar bem: o poder da linguagem precisa

{ "resumo": "## Nomear é comunicar e pensar\n\nKoleman Nix argumenta que nomear é uma das habilidades mais fundamentais da engenharia de software - e do trabalho intelectual em geral. Linguagem clara quase sempre implica pensamento claro; linguagem vaga costuma indicar falta de clareza interna. Cada nome - variável local, função, campo, endpoint, tabela, coluna, o próprio produto - é um ato de comunicação com colegas, com o eu futuro e com modelos de linguagem, que leem os nomes como entrada para a semântica do código.\n\n## Slop e interpolação em LLMs\n\nAo apontar um modelo para um código novo, focado e bem escrito, os resultados iniciais costumam ser excelentes. Com o tempo, o mesmo modelo no mesmo código parece pior - mas o que acontece, segundo o autor, não é a queda do modelo, e sim a degradação do código e dos termos que compõem seu contexto, "slop-fried" como um JPG (termo de Victor Taelin). Nix prefere pensar nisso como "expansão com perda" ou interpolação: a partir de um plano claro, o modelo interpola algo sólido; mas interpolar repetidamente das próprias interpolações leva a território ficcional. A sustentabilidade de trabalhar com modelos num código depende, portanto, da disposição de reduzir e lapidar a terminologia - o que coincide com lapidar a complexidade do sistema.\n\n## Compressão semântica, não bit a bit\n\nNix relê o princípio DRY: um fato deve ser expresso em exatamente um lugar. Isso é um cabeçalho de compressão, uma tabela de fatos comuns - mas a compressão relevante é semântica, não idêntica em bits. Dois constantes globais que valem 64 mas significam coisas distintas devem ser duas globals: o que se abstrai são os fatos (tamanho máximo de nome, profundidade padrão de fila), não o número 64.\n\n## Contra a consistência como regra\n\nEngenheiros menos experientes pedem regras de nomeação, como se consistência fosse virtude em si - o mesmo apelo de dietas com nome ou planos de treino endossados, e a mesma lógica de "produtos" como Clean Code, orientação a objetos ou programação funcional pura. Nix vê nisso uma recusa de lidar com os fundamentos. A resposta é engajar profundamente: ler o código como um colega faria e ruminar sobre a variável - é sempre opcional? a ausência é um erro? é um fallback? são overrides, que naturalmente se sobrepõem a uma base? O que deve ser consistente é o processo de nomear, que considera essência e simetria (como src e dst se espelhando). Regras como "nunca abrevie" são o tipo errado de conselho.\n\n## Empatia intelectual e exemplos\n\nNomear bem é um ato de empatia intelectual: nomes nascidos da necessidade imediata são egoístas. Um exemplo: uma função to-pixels que na verdade só arredonda um float para inteiro - sua essência não tem nada a ver com pixels; a narrativa deve ficar na chamada. Da mesma forma, created_at é bom padrão para objetos sintéticos do sistema, mas uma certidão de nascimento de 1995 recebida em 2023 pede uploaded_at e record_date distintos, para que o conjunto de colunas conte uma história clara. A forma do valor também importa: um Option[Map] que expressa ausência duas vezes pode ser ruído, e a pergunta sobre o nome vira pergunta sobre o modelo. Outro caso: mergeTargetValuesIntoSourceTemplate, que implementava manualmente a união de maps (template ++ values) - nomeada após a necessidade, escondeu a generalidade da operação.\n\n## Nomes como fio a puxar\n\nA maior parte do texto de um código é o uso dos próprios nomes. Um nome desconfortável geralmente não é rótulo ruim sobre conceito claro, mas rótulo improvisado sobre conceito vago - como um documentDate que a tela de revisão lê como data do documento, a ingestão preenche com a data de chegada e uma regra de validade usa para rejeitar extratos, checando o significado errado. Corrigir depois exige migração, backfill e risco. Puxar um nome ruim leva a emendas na lógica e, muitas vezes, a correções reais de comportamento. Nomes também servem como sinal de design: dificuldade de nomear algo cujo design já deveria estar pronto indica problema; um bom nome que surge naturalmente é sinal de qualidade.\n\n## Conclusão\n\nComo nomear? Com pensamento, tratando cada nome como oportunidade de comunicação; de forma holística, pesando o máximo de insumos; após a essência, não após a necessidade; e como se importasse.", "hook": "Para Koleman Nix, nomes em código são comunicação com colegas, com o eu futuro e com modelos de linguagem - e nomes ruins costumam esconder conceitos vagos, não rótulos infelizes. Ele mostra como um documentDate mal definido pode fazer um sistema rejeitar o documento errado, e por que pedir regras fixas de nomeação é uma forma de evitar o trabalho difícil.", "entities": ["Koleman Nix"], "themes": ["engenharia-de-software"], "story_key": "nomear-bem-e-pensar-bem", "reasoning": { "story_key": "Tese central do ensaio: nomear bem é pensar bem; nomear é pensamento e comunicação, não regra mecânica.", "themes": { "engenharia-de-software": "Craft clássico de software: nomeação, DRY, design de sistemas e legibilidade, sem IA como assunto central." }, "entities": { "Koleman Nix": "Autor e sujeito do ensaio, fonte de todas as teses e exemplos." }, "excluded": { "LLMs": "Menção secundária ao contexto de código; o assunto é nomeação e craft, não modelos.", "Victor Taelin": "Apenas crédito de um termo emprestado, menção secundária." } } }