67

Se eu encontrar um erro de digitação não crítico no código (digamos, um apóstrofo errante em uma declaração de impressão (erro)), vale a pena fazer uma confirmação para resolver esse erro, ou ele simplesmente deve ser deixado em paz?

Especificamente, estou curioso sobre a ponderação da junção do log de confirmação com o valor de resolver esses erros não críticos. Estou inclinado a resolvê-los. Estou sendo pedante?

version-control grammar

— Christopher Berman
fonte

40

Se um commit trivial agiliza alguma coisa, você precisa investir em um VCS melhor, em ferramentas melhores de filtragem de logs ou em práticas recomendadas para anotar gravidades diferentes de correção.

— Rex Kerr

@ root45 Embora se você olhar para os resultados, eles são todos um tipo de gramática diferente do que esta pergunta está perguntando.

— Izkata 10/07/12

130

Meu sentimento pessoal é que melhorar a qualidade vale o pequeno inconveniente de uma entrada de log de confirmação adicional, mesmo para pequenas melhorias. Afinal, pequenas melhorias contam muito quando você considera o efeito da janela quebrada .

Você pode prefixá-lo com uma TRIVIAL:tag ou marcá-lo como trivial se o seu VCS suportar.

— thiton
fonte

72

Só quero acrescentar a isso que eu prefiro que coisas como essa sejam comprometidas separadamente do que agrupadas com outra coisa. O problema com o agrupamento é que muito ruído pode distrair um revisor de código das alterações relevantes. +1

— Andy

9

+1 por mencionar o efeito de janela quebrada. Pequenas coisas importam. Se tudo estiver realmente limpo, as pessoas pensarão duas vezes antes de cometer códigos escritos ou não testados de forma descuidada.

— Roy Tinker

25

Além disso, se você o agrupar com um recurso, retroceda o recurso que você perde a alteração. Cometa uma coisa de cada vez.

— CTRL-ALT-DELOR

4

Eu estaria realmente interessado em quais VCSs permitem marcar comentários como triviais. Eu trabalhei com SVN, Hg e Git, e também não notei nada disso.

— Xion

3

@ E esse ruído não é a pior parte ... se alguém mais tarde decidir, por exemplo, reverter esse commit porque não deseja esse recurso, de repente você também perderá uma pequena melhoria que fazia parte do commit (s).

— Rfactor

49

Você não está sendo pedante, e é melhor resolvê-los individualmente. Quanto mais atômica for uma mudança, melhor - você não deseja que uma correção de bug seja misturada com 500 alterações de comentário / erro de digitação.

— jmoreno
fonte

9

+1 Cada revisão deve estar relacionada apenas a uma correção específica. Torna-se um NIGHTMARE fazer o backport de correções se cada revisão também tiver um monte de erros aleatórios corrigidos entre alterações reais.

— Grant

28

No caso geral: Sim

É sempre vale a pena para melhorar a manutenção do seu software.

Apenas vá em frente.

Se você está prestes a enviar uma liberação ...

... e se você não é o líder da equipe, verifique com ele .

Em relação ao conteúdo do log de confirmação ...

Concordo com os outros que você deve escrever pelo menos algo que o diferencie dos commits relacionados ao "recurso", se for apenas para corrigir um erro de digitação isolado.

Uma prática comum é ter algumas tarefas que nunca morrem no rastreador de problemas para rastrear mudanças eternas e sem fim. Por exemplo, não é incomum ter uma tarefa para:

grandes limpezas inofensivas automatizadas (varreduras de espaços em branco),
gramática e erros de caça de erros de digitação,
construir modificações no sistema,
etc ...

Apenas tome cuidado 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 corretamente documentados. Especialmente se você rejeitar confirmações que não estão vinculadas a um ID (o que é uma coisa boa, mas tarefas grandes como essas serão ainda mais atraentes para desenvolvedores preguiçosos).

— haylem
fonte

7

Verificando com seu líder de equipe uma correção de erro de digitação? Se eu fosse o líder da equipe que está estressado com o próximo lançamento, não gostaria de ser incomodado com essas trivialidades.

— Joh

2

@Joh: não é possível que você necessariamente quebre a compilação, mas pode haver outros trabalhos de compilação, ou um já pode estar marcado e pronto para uso, e seus controles de auditoria (dependendo do seu setor) podem forçá-lo a amarrar esse comprometimento inofensivo para tarefas e requisitos; portanto, se surgir do nada, isso pode ser apenas um pouco de dor de cabeça; que você pode salvar facilmente por apenas alguns dias após o lançamento do lançamento. Mas, em geral, eu concordo com você, e diria até que uma empresa que trabalha assim está fazendo errado. Mas não é você quem vai consertar isso, então corra por eles se você não for mais velho.

— haylem 11/07/12

2

@Joh: basicamente, se o líder da minha equipe vir uma nova compilação subitamente subindo no sistema de compilação quando ele estiver prestes a iniciar uma nova compilação (ou já a iniciou), então posso garantir que seus níveis de estresse aumentarão usando esta abordagem bem ...

— haylem 11/07/12

7

Erros de digitação devem ser adicionados como uma confirmação. A correção de palavras com erros ortográficos ou erros gramaticais aumentará a legibilidade do seu código.

O uso de uma mensagem de confirmação como "Erro de digitação fixo" ou "Erro de digitação fixo no arquivo.c" ajudará você a distinguir essas confirmações das demais confirmações importantes de código.

— Trevor
fonte

7

Sim, você deve absolutamente fazer isso, principalmente 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 corrigidas, porque todo mundo pensa que não será grande coisa. Até que seja.
Corrigir um erro de digitação desde o início e deliberadamente será muito mais fácil do que corrigi-lo após várias centenas de linhas de chamadas de código / função terem sido feitas com ele. Novamente, hacks temporários podem se tornar semi-permanentes surpreendentemente rapidamente. É por isso que eu tenho que lidar com objetos que possuem os métodos "CollapseAll" AND "ColapseAll".

— joshin4colours
fonte

2

Sim - de todas as respostas corretas, eu gosto mais desta por mencionar que depende do "quando".

— Wonko the Sane

4

Para erros gramaticais que podem ser vistos por um usuário final, sim, por todos os meios, vale a pena fazer a confirmação, pois é perfeitamente possível que um usuário ou controle de qualidade possa aparecer e relatar o erro, e ele precisaria ser rastreado. Se já estiver corrigido, poderá acelerar o tempo necessário para resolver o problema.

Porém, se houver um erro gramatical nos comentários ao redor do código, eu não faria nada a menos que faça parte de alterações no código real e, nesse caso, você esteja atualizando a documentação do código.

— rjzii
fonte

3

Se você está preocupado em criar o log de confirmação, está fazendo outra coisa errada. :-) Confirmações frequentes são uma coisa boa! Cometo correções de erros de digitação o tempo todo. Entre na base de código o mais rápido possível e acelere o ciclo de desenvolvimento!

— Brian Knoblauch
fonte

2

I commit typo fixes all the timeOMI que é preocupante, tente encontrar programadores com melhor inglês?

— Lie Ryan

Você pega o que pode conseguir hoje em dia. Encontrar programadores que possam escrever código viável é um problema sério!

— 11139 Brian Knoblauch

2

Eu voto sim. Verifique-os. Eu trabalhei para uma empresa que odiava pessoas verificando coisas. Quero dizer quase tudo. As revisões de código eram extensas e, portanto, se você efetuou o check-in de uma alteração que apenas corrigia um erro de digitação no qual você se queixava. Você pode imaginar o estado do código. Na verdade, o código não era terrível, mas escorria como melaço ao invés de fluir como vinho.

— Ian
fonte

0

Seu processo de gerenciamento de mudanças permite isso?

No meu ambiente, toda confirmação que eu faço deve estar vinculada a uma solicitação de mudança solicitada pelos usuários de negócios ou uma alteração obrigatória no nível do sistema, concluída com os processos de teste do usuário final correspondentes. Um erro de digitação simples que você está descrevendo provavelmente não seria registrado como um desses (encontrei erros de digitação e gramaticais em um dos meus aplicativos que existem há mais de quatro anos sem que ninguém perceba), então se / quando os auditores vierem ligar seria muito difícil me explicar.

Eu salvaria uma alteração como você está descrevendo (e, na verdade, tenho uma, na verdade - o nome do método está incorreto e eu a descobri) por um tempo em que eu tenho uma alteração "real" que precisa ser feito também e colocar "corrigidos vários erros de digitação" no log.

— alroc
fonte

+1 Em alguns ambientes, isso é verdade. Por favor, não diminua o voto apenas porque isso não é verdade onde você trabalha.

— 12138 MarkJJ

-1, seu processo de gerenciamento de mudanças parece uma tarefa difícil . Eu entenderia (e até prefiro ) que todo commit deve estar relacionado à solicitação de mudança - essa parte do seu processo parece bem. Mas OMG parece que solicitações iniciadas pelo desenvolvedor (como refatorar / corrigir erros de digitação ) são proibidas, o que gera uma grande bandeira vermelha para mim. É o tipo de assume os usuários de negócios / auditores sempre sabe melhor do que os desenvolvedores - se isso seria sempre perto de verdade, então eles escrever o código-se

— mosquito

Se o desenvolvedor puder convencer as pessoas que aprovam o avanço com as alterações que valem a pena fazer, elas podem avançar. Mas se eu encontrar um erro de digitação simples no nome de um método ou encontrar algum código copiado / colado que deva ser refatorado para um método, não posso fazer a alteração sem autorização. Não se trata simplesmente de "fazer a coisa certa com o código" - o teste de aceitação deve ser realizado, e os desenvolvedores não estão em uma posição em que possam dizer às pessoas de negócios "Eu fiz essa alteração, você nunca notará o que eu mas você precisa passar por um ciclo de teste ".

— Alroc 17/07/12

@alroc que "se puder convencer" apenas oculta um processo contraproducente sob uma superfície com aparência razoável. A exigência de convencer os negócios / auditoria sobre grandes mudanças, sobre pontos de verificação / lançamentos de marcos acordados, etc, faz sentido, OK. Passar algumas horas / dias para justificar um esforço que leva uma semana de desenvolvimento e controle de qualidade, é tedioso, mas justo, OK. Mas forçar isso para cada método de correção ou extração ortográfica único ... dá-me uma pausa - isso não passa de controle inserido insensatamente no estágio errado e na hora errada

— gnat

Deixe-me tentar explicar isso novamente. Se eu puder corrigir um erro de digitação ou extrair um método enquanto estiver trabalhando em outra alteração aprovada, posso inseri-lo sem precisar vender ninguém. Mas não posso fazer uma alteração que não seja visível ao usuário e que não tenha um impacto positivo direto nos negócios / usuários sem vender os poderes que estão nele primeiro.

— Alroc

-1

Use o DVCS para editar o histórico

Se você está preocupado com um histórico de consolidação limpo, considere fazer seu trabalho principal nas ramificações de recursos . Se você trabalha com um VCS distribuído , pode editar facilmente seu histórico de consolidação antes de enviá-lo para a ramificação principal. Se você estiver no SVN, tente o Git - ele pode interagir bidirecionalmente com o Subversion, e você também pode editar o histórico antes de realmente se comprometer com o Subversion.

Mantenha o bom senso de outra maneira

Se você não deseja ou não pode editar o histórico de consolidação, não há motivo funcional para realizar uma consolidação atômica ou atômica para um erro de digitação menor que não afeta os testes ou compilação automáticos . Nesses casos, na minha opinião, manter o histórico de confirmação limpo deve ser mais importante do que realizar confirmações realmente atômicas. A mistura de uma ou duas correções de erros de digitação com uma modificação "regular" não prejudicará qualquer processo de revisão em potencial. No entanto, você pode querer agrupar várias correções triviais em uma confirmação, talvez ao "limpar" após uma sessão de codificação maior.

Observe que os erros funcionais ainda devem ser confirmados o mais rápido possível em uma confirmação atômica.

O tom geral das respostas aqui parece sugerir uma estratégia de "comprometer tudo rápido", mesmo para erros menores. Costumo discordar e dar boas-vindas à discussão.

— krlmlr
fonte

Vale a pena fazer um commit apenas para resolver erros não críticos?

No caso geral: Sim

Se você está prestes a enviar uma liberação ...

Em relação ao conteúdo do log de confirmação ...

Use o DVCS para editar o histórico

Mantenha o bom senso de outra maneira