- Conventional Commits tenta dar significado às mensagens de commit com o formato
<type>[optional scope]: <description>, mas coloca o tipo de mudança na frente e deixa o escopo como opcional, empurrando para trás a informação realmente necessária para navegação
- Colaboradores, debuggers e equipes de resposta a incidentes procuram no log de commits a área do código afetada pela mudança, e como bugs podem surgir em qualquer tipo de alteração, o escopo (scope) é mais importante que o tipo
- Em
fix(compiler): prevent namespaced SVG <style> elements from being stripped, só a descrição já indica que se trata de uma correção de bug, e em refactor(core): Update webmcp support to use document.modelContext, um único commit pode abranger correção, refatoração e adição de funcionalidade, então o type é redundante e limitado
- A geração automática de CHANGELOG e a decisão de incremento de versão semântica têm leitores diferentes para log de commits e changelog, e os resultados podem divergir por causa de reversões, quebras acidentais de compatibilidade e correções posteriores dessas quebras
- Mensagens de commit com prefixo de escopo mostram primeiro o alvo da mudança, e condições de build e deploy também funcionam melhor quando se baseiam nos arquivos alterados via
git diff, e não no tipo do título
Prioridades erradas
- Conventional Commits tem como objetivo dar significado às mensagens de commit para ajudar desenvolvedores e usuários finais a entender as mudanças
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- A linha de título é composta por um
<type> como fix, feat, chore, docs, refactor, um scope opcional e uma descrição
- O defeito central é a estrutura priorizar o type, isto é, a natureza da mudança, em vez do scope, que é o alvo da mudança
- Uma estrutura em que o scope é opcional permite que a informação mais importante do commit fique ausente, e colocar o type no começo do título inverte a prioridade
Por que scope é mais importante que type
- Colaboradores leem o log de commits para encontrar mudanças desde a última contribuição, o fluxo geral do projeto e commits que podem entrar em conflito com o trabalho em andamento durante um pull ou rebase
- Quem está fazendo debug procura mudanças que mexeram na área relacionada ao componente onde o bug apareceu, e como bugs podem surgir em alterações de qualquer type, essa informação não ajuda
- Equipes de resposta a incidentes vasculham o log de commits perto do momento da falha para encontrar a área que causou o problema; se houver um commit com scope
auth no ponto em que erros na API de entrada aumentaram, ele vira um forte candidato à causa
- Para quem lê o log de commits, o importante não é que tipo de mudança foi feita, mas em que área ela mexeu
A redundância e os limites do type
Os limites da promessa de automação
- A ideia de gerar automaticamente um CHANGELOG a partir dos commits com ferramentas como git-cliff ou conventional-changelog esbarra no fato de que o log de commits e o changelog têm leitores diferentes
- O CHANGELOG é voltado para usuários e foca em entender diferenças funcionais e de negócio entre versões
- O log de commits é voltado para desenvolvedores e foca em entender como a base de código mudou ao longo do tempo e em acompanhar esse fluxo pela ótica do scope
- Em projetos com complexidade moderada ou maior, uma funcionalidade relevante costuma entrar por vários commits; para desenvolvedores, o processo de implementação é útil, mas para usuários finais importa apenas a funcionalidade pronta
- Commits de reversão (
revert) são importantes para desenvolvedores no fluxo do log, mas para o usuário final uma mudança revertida equivale a uma mudança que nunca foi feita
- Incrementar versão semântica com base no type do commit pode gerar problemas como subir major mesmo quando a quebra de compatibilidade foi revertida, subir minor/patch por engano porque a quebra só foi percebida depois, ou marcar como quebra algo que desapareceu ao ser combinado com commits posteriores
- Nessas situações, até dá para corrigir o histórico com rebase, mas o workflow pode impedir isso ou torná-lo frágil, além de reduzir a confiabilidade do fluxo transmitido pelo log de commits
- Se o processo de build ou deploy for disparado pelo type no título do commit, uma mensagem como
docs: fix typos pode driblar a automação mesmo inserindo uma vulnerabilidade no subsistema de autenticação
- É melhor definir condições de build e deploy identificando os arquivos alterados com
git diff do que usando o título do commit
Problemas de adoção e alternativas
- Conventional Commits incentiva cada projeto a definir seu próprio conjunto de types, mas muitos projetos simplesmente adotam os types padrão do commitlint, que podem não combinar bem com as características específicas de cada projeto
- A especificação de Conventional Commits tecnicamente define apenas
fix e feat; os demais types ficam a cargo de cada projeto
- Em ambientes corporativos, exigências de gestão de mudanças e auditoria às vezes obrigam a incluir o número do ticket em toda mensagem de commit; se o
<scope> for usado para isso, perde-se um metadado realmente útil
- Linux, FreeBSD, Git, Go, NixOS e Node.js usam mensagens de commit com prefixo de scope adaptado ao projeto
- No kernel Linux, o subsystem é um scope natural; no projeto Go, é o caminho do pacote; em arquiteturas de microsserviços, tende a ser o nome do microsserviço
- scopedcommits.com propõe voltar a um formato de mensagem de commit centrado em scope e separar a geração de CHANGELOG da gestão do log de commits
- As vantagens de Conventional Commits não se converteram em benefícios reais, e sua popularidade em projetos open source, somada à tendência de AIs de adotá-lo como padrão, está espalhando mensagens de commit com antipadrões misturados
2 comentários
Comentários do Hacker News
Programadores parecem sempre acabar discutindo e reclamando até de coisas triviais, como tabs versus espaços, sobre qual seria a configuração ideal
Isso não quer dizer que Conventional Commits seja a melhor solução, como se fosse uma revelação divina de como estruturar mensagens de commit, mas acho muito mais eficaz e importante ter uma estrutura definida e alinhar as expectativas sobre mensagens de commit
O autor dá grande destaque à ideia de que o escopo é mais importante que o tipo, mas não acho que a diferença entre
fix(compiler)ecompiler fixseja algo pelo qual valha a pena morrerHá muitas coisas na indústria de tecnologia que viraram padrão mesmo não sendo ideais; por exemplo, se fôssemos refazer JSON do zero, muita gente diria que ele deveria suportar comentários, formatos numéricos mais claros etc.
Ainda assim, virou padrão porque, em vários contextos, era melhor do que o que veio antes, e embora possa existir um formato melhor, um pouco diferente de Conventional Commits, ele não parece melhor a ponto de justificar criar outro modelo concorrente para estruturar mensagens de commit
Uma mensagem de commit pode ser excelente mesmo com uma estrutura solta, se comunicar bem a natureza da mudança; por outro lado, pode ser altamente estruturada e ainda assim confusa ou sem informação
Em geral concordo com o autor: Conventional Commits não resolve o problema central, que são mensagens de commit ruins
XML é bom o bastante e é padrão, SOAP é bom o bastante e é padrão
A ideia é que Conventional Commits é bom o bastante e padronizado o suficiente para não valer a pena considerar outra estrutura, mas esse “valer a pena” é subjetivo
Se você faz commits e lê PRs todos os dias, até o pequeno atrito criado pelo formato de Conventional Commits pode se acumular, e deixar outras opções disponíveis sem tratar isso como lei da natureza pode ajudar equipes que prefiram outra abordagem
De qualquer forma, a maioria das equipes nem gera changelog
Faz sentido dizer que o escopo é importante, mas isso não poderia ser inferido pelo conteúdo do commit?
Ao revisar um diff, olhar os caminhos alterados é uma verificação de sanidade importante, e um diff de “test” não deveria modificar código de autenticação de produção
Ainda assim, se for para mostrar isso no
--oneline, achofeat(auth):melhor do quefeat:Não concordo com a afirmação de que o público-alvo está errado
Um commit
featrealmente deveria explicar uma mudança sob a ótica do produto, e o ideal é organizar a pilha primeiro com mudanças úteis de refatoração sem significado próprio e depois colocar por cima a pequena mudança de nova funcionalidadeIsso também é o mais útil para colocar na descrição do diff, e contexto técnico como “por que o algoritmo X foi escolhido” deve ir em comentários ou em
DECISIONS.md, para não se perderEm empresas que se movem rápido, talvez só pessoas obsessivas cuidem desse tipo de detalhe tedioso no histórico de commits, mas em projetos open source acho muito mais importante esconder contexto nas mensagens de commit
Existe um motivo para haver formatos como Markdown e texto simples, e não apenas JSON
Já revisei commits demais com título
small fixque, na prática, estavam longe de ser uma correção pequenaA conclusão real é que os requisitos variam de projeto para projeto
Em mais de 30 anos usando controle de código-fonte, nunca tive um trabalho em que fosse útil colocar o componente na descrição de forma padronizada (no texto, isso é chamado de scope)
Só de ver onde os arquivos afetados estão na árvore de código já fica claro qual componente mudou, e
bug,fixefeaturetambém não agregam valor útilSe não fosse importante, não teria sido commitado
A única coisa que achei útil são os links ou IDs de solicitações de mudança relacionadas, algo que o texto nem aborda
O commit já contém informações sobre o que mudou; o que falta é o contexto de por que mudou
Mesmo em projetos pessoais, coloco uma referência do JIRA entre colchetes antes da descrição e, mesmo que seja algo que resolvi corrigir por acaso durante o desenvolvimento, crio um JIRA curto de uma linha para receber um ID e registrar ali o motivo
Capturar o “porquê” é todo o propósito dessa mensagem, e colar um link para algum recurso externo que pode desaparecer no futuro não é um bom substituto
Se for uma issue do GitHub, dá para voltar do commit para a discussão do PR, e esse PR deve ter a issue vinculada e outros apontadores
Claro que, ao migrarmos para issues do GitHub, praticamente abandonamos o JIRA, e alguns anos depois a instância foi desligada e apagada
Agora aquelas tags de JIRA não servem para nada
Por isso, acho que na verdade é preciso um forte acoplamento entre o rastreador de issues e o repositório git
O que realmente queremos é portabilidade, mas não sei como obtê-la sem esse forte acoplamento
Idealmente deveria existir um formato padrão aberto, mas, na prática, o GitHub é o gorila gigante que define o formato, e se clones como o GitLab conseguirem importar metadados de projetos do GitHub ou ao menos PRs, isso na prática já chega perto disso
De qualquer forma, não é uma boa política deixar um ponteiro fixo e imutável para um produto da Atlassian que talvez você nem use daqui a 5 anos
Eu preferiria aceitar uma política em que o commit git precise se sustentar completamente sozinho e toda a informação sobre o “porquê” da mudança seja incorporada na mensagem de commit ou em comentários no código-fonte
Ainda assim, acho que isso também falha, porque as pessoas escrevem de forma excessivamente curta nos commits git, perdem informação ao resumir a issue, e a conversa de ida e volta na discussão do PR é útil porque contém mais do que um resumo em uma só voz sobre o motivo da mudança
Agrupar primeiro os novos recursos e depois as correções de bugs torna a leitura um pouco mais fácil para usuários não técnicos
Mensagens de commit não são para gerar changelog, e sim para desenvolvedores do futuro
O principal momento em que esse desenvolvedor lê a mensagem de commit é quando não consegue entender por que aquele commit existe
É uma situação em que ele quer saber não o que foi alterado, mas qual é o propósito de uma determinada linha
Então ele roda
blame, vê o commit, o desenvolvedor original já saiu da empresa, o JIRA antigo talvez já tenha sumido, e a única pista é a mensagem de commithttps://dev.to/splix/the-why-behind-the-code-2bb1
Não daria para colocar o contexto no corpo do commit?
A palavra
chorede muita gente que usa Conventional Commits sempre me incomodouPessoalmente, também aqui eu já preferia os títulos de commit no estilo do kernel Linux, felizmente mencionados
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
A atitude implícita por
choreme causa muita rejeiçãoDá a sensação de que todo o resto teria de ser marcado como
funouindifferent, e esse tipo de julgamento emocional não tem lugar em mensagem de commitupkeepTem o mesmo sentido, mas sem a nuance depreciativa
Além disso, também finge que você sabe de antemão qual é o impacto geral do commit, quando na verdade não sabe
Com Conventional Commits, tanto os membros da equipe quanto os LLMs precisam gastar tempo e tokens inventando essa nomenclatura idiota
A principal reclamação que eu tinha sobre Conventional Commits era que o título do commit não incluía o número da issue
A documentação padrão nem menciona isso como algo opcional
Para mim, é quase a informação mais importante da mensagem de commit
Nem sei quantas vezes, nos últimos 15 anos, comparei a descrição da issue referenciada por um commit antigo para entender todo o contexto da mudança
Eu sentia que esse hábito era uma espécie de padrão, mas só depois de conhecer Conventional Commits aprendi que não era
Nunca entendi por que isso se tornou popular
Pessoalmente, prefiro colocar a issue como git trailer
fix thing in fooIssue: ABC-123O Git tem muitos recursos nativos para analisar e formatar esse tipo de trailer, então é fácil criar aliases personalizados de
git logpara ver inline ou analisar no CIse você já está passando os olhos por um changelog com limite de caracteres, não me interessa muito ver
XYZ-999999na mensagem principal do commité bom marcar com trailer, mas eu quero muito mais ver o que o commit fez do que o número da issue no Jira
só considero um problema quando exigem que a chave da issue fique obrigatoriamente no começo do título
também acho que isso prejudica a legibilidade
não entendo por que não pode simplesmente ser colocada em algum lugar depois daquela formatação variada do Conventional Commits
como a chave da issue deveria poder ser extraída com uma regex do tipo número após um prefixo alfanumérico, quase não há necessidade de esse “padrão” reservar um espaço separado para isso
pessoalmente, sem Conventional Commits, se o commit estiver relacionado à issue eu costumo colocar entre parênteses no fim
se a relação for mais forte, como corrigir a issue, também coloco um trailer
Fixesna mensageminteressante
até agora usamos algo como
fix(ABC-123): some message here, e isso vira link direitinho e também é renderizado muito bem nas notas de release automáticasisso não é um padrão, é uma convenção
basta definir dentro da equipe um padrão para incluir o ID do ticket na mensagem de commit
se você quer algo legível por máquina, use footer/trailer
não tenho nada de bom a dizer sobre Conventional Commits
o formato ocupa espaço na parte da mensagem que as pessoas mais leem, e categoria ou tipo têm pouca densidade de informação
dá para substituir isso por um verbo honesto em inglês no título, como uma frase, e uma frase comum se lê muito melhor do que três tipos de pontuação como
:,()e!até dá para tolerar algo como uma “área” no título, e isso inclusive existia antes dessa convenção
no trabalho fazemos webapps para usuários não técnicos, e changelogs para esses usuários podem muito bem ser escritos em norueguês
mensagens de commit não importam para o usuário, e exigir que todo commit seja bom o bastante para entrar no changelog final voltado ao usuário não é algo que vá acontecer para nós tão cedo
em vez disso, use footer/trailer
onde Conventional Commits realmente ajuda é em implantação contínua
dá para aplicar tags SemVer automaticamente e fazer deploy sempre que algo é mergeado em
main, porque as decisões necessárias para tagging e versionamento já foram tomadas pelo desenvolvedor ao escrever a mensagem de commitreconheço totalmente que isso não serve para projetos enormes como o kernel Linux
mas em 99% dos projetos, combinar Conventional Commits com SemVer representa uma grande melhora sobre o processo de release atual e facilita a automação
git tagsgit describemuitas vezes já basta para versionamento em implantação contínua, ev1.2.3-4-gabcdefdescreve o commit com precisão suficiente para o Git e é parecido o bastante com SemVer para ajustar expectativasisso vale especialmente quando novas
git tagssó são adicionadas com julgamento humano, por exemplo quando se decide que esta é uma mudança breaking e portanto agora deve ser marcada uma nova majorem números de versão no formato
git describe, a única discussão prática costuma ser se vale trocar o primeiro hífen por um sinal de mais para se alinhar melhor às expectativas de SemVer e, se houver valor em impor expectativas de SemVer, como ordenar versões corretamente no gerenciador de pacotes, isso pode ser convertido com uma regex simplesgit describefacilita a automação de CD, mas permite deixar a decisão do número da versão com humanos por meio da escolha degit tagou de GitHub Releases, em vez de adivinhar com palavras-chave mágicas no histórico de commitsno trabalho também impomos “tags” dependendo de quem se interessa pela mudança
aqui tag não quer dizer git tag, mas sim uma string no título do PR, e com base nessa “tag” geramos changelogs para cada equipe
se você quer versionar desse jeito esquisito, basta colocar uma frase mágica no corpo do commit
assim não fica limitado a uma única palavra
eu desgosto bastante desse estilo de título
expressões como “Stop something” parecem ser muito populares, mas são imperativas e passam uma sensação de “eu estou claramente certo”
não entendo por que não usar algo como “In favour of something” ou “A case against something”
você não precisa concordar com ela, mas exigir que a formulação seja suavizada é uma resposta fraca
considered harmful, mas ainda tem um leve tom tóxicoo ponto principal parece ser fazer alguma preferência pessoal arbitrária, como querer inverter a ordem de A e B, parecer maior do que realmente é
para muita gente isso é grosseiro, mas a economia da atenção recompensa esse tipo de coisa
edição: parece que mudaram o título para algo menos provocativo
boa decisão
não gosto muito de Conventional Commits, mas as pessoas deveriam simplesmente usar o que quiserem
existe um meme que influenciou parte desse gênero de títulos
Estranho
O principal motivo para usar esse estilo de mensagem de commit é a automação de CI/CD
Edit: não vi essa parte no texto na primeira leitura, mas ela foi abordada
Foi mal
Os tipos de commit vêm no começo porque informam ao workflow automatizado como tratar aquele commit
Por exemplo, se você faz CD, quando há vários commits
fix:isso só incrementa o número de patch do versionamento semânticoSe você faz commit com
feat:, a versão minor sobe, efeat!significa aumento de versão majorMesmo que você não use CD para releases, mensagens de commit semânticas também são usadas para automatizar a geração do changelog
Claro que normalmente você não deveria colocar as próprias mensagens de commit no changelog
Essas mensagens são voltadas para desenvolvedores, não para usuários
versionamento semântico quebra com reversões, e changelog automático erra o público-alvo
Hoje em dia uso CalVer em vez de SemVer, então isso não chega a ser um problema, mas gosto da ideia de incremento automático de versão inteligente
Ter
fixoufeatno título do commit não fornece informação útil para quem está passando os olhos pelo logA ideia é abolir Conventional Commits para que a IA consiga fazer commits com mais facilidade
Se inverter a ordem, minha principal irritação de fato se resolve
Afinal, o que é exatamente uma feature?
refactor(core): Update webmcp support to use document.modelContextComo o autor diz, as fronteiras entre correção, melhoria e arrumação geral são nebulosas, e separar cada mudança semântica em commits distintos acaba só criando trabalho que não beneficia ninguém, já que tudo pode ser squashado depois mesmo
Vejo Conventional Commits como um subproduto de tentar automatizar o SemVer, e não como algo que resolve diretamente outro problema
Acho que changelog não deveria ser automatizado de qualquer forma
Se você precisa de uma lista, basta olhar o
git logO changelog é uma oportunidade de comunicar a um público mais amplo o que realmente está acontecendo internamente
“O público do changelog é totalmente diferente do público do log de commits”
“O changelog é voltado para usuários”
Acho que esse barco já partiu
A maioria das empresas se contenta com “Bug Fixes & Performance Improvements”
Pelo menos, se não vão se esforçar, um changelog gerado é melhor do que não ter nenhum
uv:na frente dos commits visíveis para o usuárioAí toda semana eu procurava por eles e usava o texto como estava ou dava uma leve ajustada
Também colocava isso no menu Help/Release-notes do próprio produto
É meio engraçado mandarem eu parar de fazer algo que eu nem faço e nunca ouvi falar de alguém fazendo
Normalmente eu só colocava prefixos especiais em migrações de esquema de banco de dados ou outras coisas realmente importantes
Também parece dar nomes ruins para commits, e provavelmente também para nomes de símbolos
É questão de habilidade, então dá para simplesmente ignorar o fato de ele estar lamentando isso em público
Opiniões no Lobste.rs
Fico feliz de ver um texto que organiza de forma lógica uma crítica aos conventional commits, e não só como uma rejeição instintiva
Eu não tinha pensado muito a fundo sobre por que não gosto disso, e achei que talvez fosse por eu ter passado a associar com código gerado por LLM. Especialmente
chore:é o que eu mais detesto; espero que não reinventem a notação húngara. Isso nem deveria ter sido criado em primeiro lugarchore:nem existe mais no guia de estilo de commits do Angular e, talvez por terem percebido o quão vago era, acabou sendo absorvido porbuild:Mesmo na época em que existia no estilo do Angular, a descrição de
chore:sugeria usos bem específicos, mas em alguns projetos open source parece que colocam isso no clima, literalmente para tarefas que soam como coisas que deu preguiça de fazerEu não gosto de conventional commits, mas acho que a alternativa proposta deixa passar o motivo de o scope ser opcional
Em projetos pequenos, sem muitos módulos bem definidos, o conceito de “scope” não é muito útil. Uma prática útil que ambos deixam de fora é colocar números de issue ou ticket no título do commit, porque isso facilita entender o contexto adicional da mudança e ajuda especialmente na revisão de código. Dito isso, eu não gosto da ideia de tornar número de ticket obrigatório, porque isso só faz surgir tickets inúteis para mudanças triviais; mas, se a mudança trata de um bug ou tarefa específica, ela deveria estar ligada a esse bug ou tarefa
Ainda é melhor do que um “type” de commit redundante, que deveria ficar evidente só de olhar a linha de título
Se a mudança corresponde claramente a um ticket, use um commit com “número de ticket”; se não, use outro formato. Algumas mudanças se encaixam melhor no type do que no scope, e outras no contrário, então também dá para misturar scoped commits com conventional commits
Dá vontade de dizer: “não usem fonte monoespaçada em texto corrido”
Ainda assim, em geral concordo com a premissa do texto
Mesmo que as mensagens de commit não sejam grandes coisas, para ter noção do escopo das mudanças eu recomendo usar com frequência
git log --name-onlyougit log --statVer os nomes dos arquivos ajuda bastante a entender o que mudou sem precisar abrir cada commit individualmente
O formato de que eu realmente gosto é exigir estilo de conventional commit no título do PR
O título do PR pode ser editado pelo maintainer mesmo depois do merge, não exige reescrever o histórico de commits e, junto com ferramentas como release-drafter, permite automatizar changelogs significativos nas releases do GitHub. Isso oferece a granularidade apropriada para os stakeholders mencionados pelo autor — separando funcionalidade, correção e breaking changes — e também automatiza um semver razoável para o próximo rascunho de release no GitHub
A crítica do texto de que componentes como
parse-libnão deveriam ser opcionais está correta, e também concordo que forçar conventional commits desencoraja novas contribuições. Mas as alternativas também não parecem exatamente melhoresAinda assim, um identificador de breaking change como
fix!(parse-lib): Don't leave sparse holes when parsing JSON arraystraz bastante informação. Mostra que é uma correção de bug em um componente específico, que a correção inevitavelmente veio acompanhada de uma breaking change e carrega um significado como um incremento minor de semver. Isso dá para usar no título do PRAdmito que me empolguei demais com conventional commits como forma de incentivar disciplina nos commits, e no fim isso virou hábito
Hoje, às vezes, me parece limitador e arbitrário. Em alguns projetos, sem eu nem saber se aquilo era a convenção real, acabei me aproximando mais do estilo Linux/Go/Node; e, em monorepos com várias configurações, parecia mais natural escrever
[service]: [what changed]do que inventar um type à força. Daqui para frente, pretendo experimentar mais com meu estilo pessoal de commits com base no que parece útil, em vez de tentar me encaixar numa convenção rígida, e scoped commits parecem um bom ponto de partidachore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]Concordo com quase tudo, mas vejo de forma diferente a parte sobre “mostrar aos contribuidores um registro revisionista que reduz a confiabilidade da história contada pelo log de commits”. O autor parece estar falando principalmente de branches públicas, e nesse caso é um conselho razoável. Mas isso não deveria valer para branches privadas. Basta tornar o resultado final fácil de entender para quem vai revisar a mudança — ou seja, o maintainer ou eu mesmo daqui a 10 anos —, sem necessidade de deixar um fluxo de pensamento inconsistente ou, pior ainda, uma pilha de commits
address reviewA resposta para “por que scope é opcional?” é que, em projetos pequenos, simplesmente o projeto inteiro é o scope
Concordo que o “type” do commit não é tão útil assim, mas também não vejo muita diferença entre scoped commits e conventional commits. Scoped seria só um conventional sem o “type”, e a distinção entre fix·feat·refactor·chore também é aceitável
Se todo mundo só pega o padrão do commitlint e usa como está, talvez a questão não seja simplesmente fazer as pessoas lidarem melhor com isso?