Loja DApp | Hub Web3 para eventos e jogos

Concordo absolutamente, e acho que as ferramentas LLM podem ser um fator impulsionador para a adoção de algumas das práticas das melhores equipas/organizações em equipas menores que talvez não tenham conseguido justificá-las antes.

Acho que seria loucura ter várias centenas de engenheiros sem um linter. Se você tiver apenas dois ou quatro, no entanto, talvez nunca consiga a energia de ativação para isso e tenha principalmente discussões improdutivas sobre o estilo de codificação. Mas adicione o Claude Code e a) você quer esse linter

b) configurar esse linter agora leva cinco minutos de esforço marginal em comparação com "Uma pessoa desce para uma tarefa clássica de tarpit de integrá-lo com todos os IDEs/etc."

Para a parte do meu público que não sabe: um linter é uma ferramenta automatizada que pode impor padrões de convenção de codificação que são mais rigorosos do que aqueles que uma linguagem pode permitir. Por exemplo, você pode adotar uma regra interna que determinadas construções legais não são permitidas.

Como exemplo, existe uma expressão legal muito concisa em muitas línguas chamada operador ternário. Os operadores ternários são notoriamente propensos a causar bugs, e uma equipe de engenharia pode decidir que, embora concisos, com base na avaliação de risco, não são uma característica aceitável a ser utilizada.

Como exemplo de algo que você pode regular sensatamente via linter e que não quer ter que discutir repetidamente com Claude Code: no Rails, something_id significa uma chave estrangeira para a tabela something. Claude esquece isso ocasionalmente, chamando muitas outras coisas de ids.

Você pode, se quiser, escrever uma regra de linter que será executada toda vez que o código for modificado e sinalizar para Claude e o resto do mundo: “Você nomeou uma variável box_id, mas _ids devem ser usados apenas para se referir a chaves de banco de dados. Considere box_code ou algum outro nome.”

Uma coisa boa sobre as regras de linter é que elas podem ter conhecimento específico do projeto incorporado nelas. Um argumento repetido que um salaryman japonês foi forçado a ter há muito tempo, com (colegas) falantes não nativos fazendo uma aplicação web universitária: NÃO se deve usar "subject."

Por que não? Porque as universidades japonesas dividem as disciplinas acadêmicas em 教科 (kyouka; uma disciplina como "matemática") e 科目 (kamoku; uma disciplina como "álgebra linear"), e como subdisciplina é horrível de ler em código, estas foram referidas em japonês romanizado para serem sempre inequívocas.