Tópicos em alta
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Concordo absolutamente, e acho que as ferramentas LLM podem ser uma função forçada para adotar algumas das práticas das melhores equipes / organizações em equipes menores que podem não ter sido capazes de justificá-las antes.

20 horas atrás
Não são apenas testes de unidade - existem muitas outras práticas de engenharia de software de primeira linha que aceleram a produtividade com agentes de codificação
Testes automatizados, documentação abrangente, bons hábitos de controle de versão, uma cultura de revisão de código, implantação rápida em ambientes de teste...
Acho que você seria louco se tivesse várias centenas de engenheiros sem um linter. Se você tiver apenas dois ou quatro, no entanto, talvez nunca alcance a energia de ativação para isso, e tenha brigas improdutivas sobre o estilo de codificação.
Mas adicione Claude Code e a) você quer que o linter
b) configurar esse linter agora é cinco minutos de elevação marginal versus "Uma pessoa desce para uma tarefa clássica de integrá-lo a 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 rígidos do que aqueles que uma linguagem pode permitir. Por exemplo, você pode adotar uma regra da casa de que construções legais específicas não são permitidas
Por exemplo, existe uma expressão jurídica muito concisa em muitos idiomas 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, em uma base ajustada ao risco, eles não são um recurso aceitável para usar.
Como um exemplo de uma coisa que você pode regular sensatamente via linter sobre a qual você não quer ter discussões repetidas com Claude Code: em Rails, something_id significa uma chave estrangeira para a tabela de algo.
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 usadas 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 arbitrariamente específico do projeto embutido nelas.
Um argumento repetido que um assalariado japonês foi forçado a ter há muito tempo, com (colegas) falantes não nativos fazendo um aplicativo da web da universidade: você NÃO DEVE usar "assunto".
Por que não? Como as universidades japonesas dividem as disciplinas acadêmicas em disciplinas (kyouka; um assunto como "matemática") e assunto (kamoku; um assunto como "álgebra linear"), e como o subassunto é terrível de ler em código, eles foram referidos pelos japoneses romanizados como sempre inequívocos.
20,92K
Melhores
Classificação
Favoritos