Se eu encontrar um erro de digitação não crítico no código (digamos, um apóstrofo errado em uma declaração de impressão (erro)), vale a pena fazer uma confirmação para resolver esse erro ou simplesmente deixá-lo em paz?
Especificamente, estou curioso sobre pesar a perda de memória do log de confirmação em relação ao valor de resolver esses erros de digitação não críticos. Estou inclinado a resolvê-los. Estou sendo pedante?
Meu sentimento pessoal é que a melhoria da qualidade vale o menor inconveniente de uma entrada de registro de confirmação adicional, mesmo para pequenas melhorias. Afinal, pequenas melhorias contam muito quando você considera o efeito de janela quebrada .
Você pode querer prefixá-lo com uma tag TRIVIAL: ou marcá-lo como trivial se o seu VCS o suportar.
Você não está sendo pedante, e é melhor resolvê-los individualmente. Quanto mais atômica for uma mudança, melhor - você não quer que uma correção de bug falho seja misturada com 500 mudanças de comentários / erros de digitação.
vale sempre a pena aumentar a capacidade de manutenção do seu software.
Apenas vá em frente.
... e se você não for o líder da equipe, verifique com ele / ela .
Concordo com os outros que você deveria pelo menos escrever algo para torná-lo distinto dos commits relacionados a "feature", se for apenas para corrigir um erro de digitação isolado.
Uma prática comum é ter algumas tarefas que nunca morrem em seu rastreador de problemas para rastrear mudanças eternas e intermináveis. Por exemplo, não é incomum ter uma tarefa para:
Apenas seja cauteloso para que eles não sejam usados como IDs de tarefas descartáveis para praticamente qualquer coisa quando as pessoas ficam com preguiça de criar tickets documentados corretamente. Especialmente se você rejeitar commits que não estão vinculados a um ID (o que é uma coisa boa, mas grandes tarefas como essas serão ainda mais atraentes para desenvolvedores preguiçosos).
Os erros de digitação devem ser adicionados como um commit. Corrigir palavras com erros ortográficos ou erros gramaticais aumentará a legibilidade do seu código.
O uso de uma mensagem de confirmação como "Corrigir erro de digitação" ou "Corrigir erro de digitação no arquivo.c" ajudará você a distinguir essas confirmações de outras principais confirmações de código.
Sim, você deve fazer isso, especialmente no início de um projeto.
Por quê? Dois pontos:
Você provavelmente não saberá se um erro de digitação é "crítico" ou não até que seja tarde demais. Algumas correções provavelmente não são consertadas porque todos acham que não será um grande problema. Até que seja.
Corrigir um erro de digitação antecipadamente e deliberadamente será muito mais fácil do que consertá-lo depois de várias centenas de linhas de chamadas de código / função terem sido feitas com ele. Novamente, hacks temporários podem se tornar semipermanentes surpreendentemente rapidamente. É por isso que tenho que lidar com objetos que possuem os métodos "CollapseAll" e "ColapseAll".
Para erros gramaticais que podem ser vistos por um usuário final, então sim, por todos os meios vale a pena fazer o commit, pois é inteiramente possível que um usuário ou QA possa aparecer e relatar o erro e ele precisaria ser monitorados. Se já estiver corrigido, poderá acelerar o tempo necessário para resolver o problema.
Se é um erro gramatical nos comentários em torno do código, eu não faria nada a respeito, a menos que seja parte de alterações no código real, caso em que você está atualizando a documentação do código.
Se você está preocupado em destruir o log de commit, então está fazendo algo errado. :-) Frequent commits são uma coisa boa! Eu cometo erros de digitação o tempo todo. Coloque-os na base de código o mais rápido possível e acelere o ciclo de desenvolvimento!
Eu voto sim. Verifique-os. Eu trabalhei para uma empresa que odiava as pessoas verificando as coisas. Eu quero dizer quase qualquer coisa. As revisões do código eram extensas e então, se você registrasse uma mudança que apenas corrigiu um erro de digitação, você se queixou. Você pode imaginar o estado do código. Na verdade, o código não era horrível, mas escorria como melado em vez de fluir como vinho.
O seu processo de gerenciamento de mudanças permite isso?
No meu ambiente, todo commit que eu faço deve ser vinculado a uma requisição de mudança que tenha sido solicitada pelos usuários corporativos ou por uma mudança obrigatória no nível do sistema, completa com os processos de testes do usuário final correspondentes. Um simples erro de digitação como você está descrevendo provavelmente não seria registrado como um desses (eu encontrei erros ortográficos e erros gramaticais em um dos meus aplicativos que existiam por mais de 4 anos sem que ninguém percebesse), então se / quando os auditores veio chamando eu teria um momento muito difícil de me explicar.
Eu salvaria uma mudança como você está descrevendo (e na verdade tem uma, na verdade - um nome de método é mal escrito e eu acabei de descobrir) por um tempo quando eu tenho uma mudança "real" que precisa ser feito também e colocar "vários erros corrigidos" no log.
Se você está preocupado com um histórico de commits limpos, considere fazer o seu trabalho principal em ramificações de recursos . Se acontecer de você trabalhar com um VCS distribuído , você pode editar facilmente seu histórico de commit antes de enviá-lo para o branch principal. Se você está no SVN, tente o Git - ele pode interagir bidirecionalmente com o Subversion, e você também pode editar o histórico antes realmente se comprometendo com o Subversion.
Se você não quiser ou não puder editar o histórico de confirmação, não há razão funcional para fazer uma confirmação inicial ou atômica para um erro de digitação menor que não afete os testes automáticos ou a compilação . Nesses casos, na minha opinião, manter o histórico de commits limpo deve ser mais importante do que fazer commits realmente atômicos. Misturar um ou dois erros de digitação com uma modificação "regular" não prejudicará nenhum processo de revisão em potencial. No entanto, você pode querer agrupar várias correções triviais em um commit, talvez quando "limpar" após uma sessão de codificação maior.
Note que bugs funcionais ainda devem ser confirmados o mais rápido possível em um commit atômico.
O tom geral das respostas aqui parece sugerir uma estratégia de "comprometer tudo rápido" mesmo para pequenos erros de digitação. Eu tenho a tendência de discordar e receber discussões.
Tags version-control grammar