O que fazer se um colega de trabalho estiver editando seu código apenas para alterar a aparência?

O que você deve fazer se um colega de trabalho estiver editando seu código?

Sem o objetivo de adicionar funcionalidade ou corrigir bugs, apenas para alterar a aparência ...

Converse com eles sobre isso. Entre na conversa com a atitude de "Eles não estão fazendo isso para me irritar ou porque têm algum tipo de transtorno obsessivo-compulsivo; estão tentando melhorar meu código".

Porque você pode estar errado. Isso pode ser uma correção sutil de bug e você simplesmente não a localizou.

Ou pode ser que exista um padrão de codificação que você não conheça e que esteja violando, e eles apenas o estejam corrigindo.

Ou pode estar tentando incomodá-lo ou ter algum tipo de transtorno obsessivo-compulsivo. Se for esse o caso, peça-lhes que parem e, se isso não funcionar, converse com seu chefe.

Mas você nunca saberá a menos que peça.

Não sou tão casada com a aparência do meu código que me incomoda. :) Eu tento aprender com as mudanças. Meu colega de trabalho ajustou os nomes das variáveis? Escreva um loop mais eficiente? Tornar o código mais legível?

Se não consigo ver como as mudanças melhoraram o que já estava lá, geralmente pergunto ao colega de trabalho que fez as mudanças qual foi a motivação por trás delas. É possível que a vantagem não seja óbvia para mim. E se eu estiver certo e eles estiverem errados, talvez eu possa explicar por que escrevi da maneira que escrevi.

Se tudo mais falhar, reverta o check-in. ;)

Edit: Todas as apostas estão desativadas se o desejo de fazer alterações cosméticas introduzir um bug, no entanto.

OMI e você e sua equipe devem usar um padrão de codificação de qualquer maneira. Se for esse o caso, as perguntas se tornarão 'seu código original estava em conformidade com o padrão?' Se 'sim', seu colega não deve tocar no seu código, a menos que seja alterado funcionalmente. Se 'não', receio que seu colega tenha todo o direito de organizar seu código. Como líder de projeto, eu me pego fazendo isso o tempo todo.

Se você não estiver usando um padrão de codificação, todo o argumento do que constitui 'bom código' se tornará subjetivo demais. Por isso, você deve usar um padrão de codificação :)

Como um dos dessas pessoas (que ocasionalmente reformata o código de outras pessoas), a principal razão pela qual faço isso é a legibilidade. Algumas pessoas são extremamente desleixadas com o seu recuo ou misturando guias e espaços.

A principal coisa que eu tenho o hábito de mudar é reduzir as linhas longas, para que eu possa ler a coisa toda sem a rolagem horizontal. Vou dividir instruções complexas em instruções separadas ou reformatar chamadas / declarações de métodos para listar um parâmetro por linha, se tudo não couber confortavelmente em uma única linha. Também editarei comentários, para corrigir erros de inglês ou apenas para esclarecer as coisas.

Sim, eu poderia deixar isso em paz, mas prefiro reduzir o esforço mental necessário para ler o código.

O que você deve fazer sobre isso? Primeiro, considere que talvez essa pessoa esteja melhorando seu código. Além disso, você deve garantir algum consenso em sua equipe sobre como o código deve ser formatado. Se cada pessoa tem hábitos diferentes, isso atrasa a todos. Se eles não estão melhorando seu código e estão indo contra a corrente, você precisa confrontá-los sobre isso. Se isso não funcionar, pode ser necessário envolver outras pessoas.

Pergunte a eles por que eles estão fazendo isso; uma explicação válida pode diminuir sua frustração, mas você deve informar o quanto isso a incomoda. Quem sabe, talvez eles achem que estavam fazendo um favor para você e parem quando descobrirem que isso o ofende. Ou você pode estar lidando com alguém que está sofrendo verdadeiramente de uma condição médica.

Ele é permitido? As alterações melhoram o código? Se assim for, engula seu orgulho. Se você sentir que a qualidade do código está piorando, leve-a com o colega de trabalho e pergunte-lhe por que eles sentiram a necessidade de alterar seu código sem nenhum benefício óbvio. Se isso está sendo feito por despeito ou porque a pessoa, por engano, sente que é melhor que você, e você não pode resolver isso com ela, leve-o ao seu chefe.

IDEs como o Visual Studio têm uma opção chamada Format Documentque formatará o código de acordo com as regras que o usuário definiu no IDE. Pode ser que seu colega de trabalho esteja usando isso (automaticamente sem saber ou por aplicativo deliberado). Talvez o IDE deles use espaços em vez de tabulações, ou vice-versa, e estes estejam sendo aplicados automaticamente, mesmo sem saber? Mas você precisa conversar com eles para descobrir.

Aliás, muitas vezes vou reformatar o código dos colegas de trabalho se ele obviamente não estiver seguindo algum tipo de esquema de formatação (ou seja, está em todo lugar). É uma maneira esperançosamente sutil de fazê-los notar. (No entanto, eu não a reformataria se fosse legal, mas não do meu agrado).

Se ele está mudando para que atenda aos padrões de codificação da sua equipe, siga os padrões da próxima vez.

Se ele mudar de forma que não siga mais os padrões de codificação de sua equipe, informe-o sobre o que está fazendo de errado e peça que ele mude de volta.

... Sua equipe tem um conjunto de padrões de formatação de código que são usados ​​por todos, certo?

Ocasionalmente, reordenar o código escrito por colegas de trabalho bagunçados (ou corrigir erros de digitação nos comentários). Eles sabem que eu sou obsessivo em formatação e ordem de código e, portanto, eles me deixam fazer isso sem reclamar demais. Às vezes, eles também me dão refrigerantes ou biscoitos grátis.

Obviamente, este é um trabalho ocasional , pois quebrou a funcionalidade de "culpa" no SVN.

Essa também é uma maneira muito básica de fazer algum tipo de revisão de código (normalmente leio a maior parte do código confirmado por meus colegas de trabalho nos módulos em que estou trabalhando).

Convenções de código é a resposta. Você deveria ter um no trabalho. Caso contrário, comece agora (um bom ponto de partida é o guia de estilo do Google ). Quando existem regras escritas (ou pelo menos comumente conhecidas), a resposta à sua pergunta é trivial.

Eu sinto que você está achando ofensivo fazer isso ...? Por exemplo, eu mesmo corrigia esse código imediatamente

int myFunction( ) {

    int i ;
  return  0;

}

tornar-se

int myFunction() {
    int i;
    return 0;
}

então ... eu deveria ser punido por causa da minha ação? Na vida real, na verdade, tenho toneladas de logs SVN lidos 'Formatação'. ;-)

Use uma ferramenta de verificação de estilo

Comece a usar o StyleCop ou similar e aplique regras de estilo de código e também obrigue todos os desenvolvedores a usá-lo. Todo o código terá a mesma aparência, sem exceção. E se reúna com os intelectuais para discutir as regras mais apropriadas para sua organização. Embora as regras padrão já sejam muito semelhantes ao próprio código da estrutura .net.

É a maneira mais fácil de fazer isso. Eu me vi corrigindo o código de outra pessoa em um dos meus empregadores anteriores, porque esse outro cara estava escrevendo código com quantidades excessivas de linhas vazias e sem regras de recuo. O código era realmente ilegível para um desenvolvedor comum. Se o StyleCop existisse naquela época, muitos de nós ficariam realmente felizes.

esse é um pensamento que eu vi na internet falando sobre refatoração e talvez explique por que alguém tocaria seu código para torná-lo melhor:

Por quê?

Há duas razões principais para refatorar:

1. Para melhorar o código / design antes de criar o seu topo: é realmente difícil criar um bom código na primeira tentativa. A primeira tentativa de implementar qualquer design inicial nos mostrará que interpretamos mal ou esquecemos alguma lógica.

2. Adaptar-se às mudanças nos requisitos. A mudança acontece no desenvolvimento de software; ser responsivo à mudança é melhor ter uma boa base de código. Temos duas opções para os dois cenários: localizar o código ou refatorá-lo. A correção do código nos levará a um código não sustentável, e aumentará nossa dívida técnica; é sempre melhor refatorar.

Quando?

1. Quanto mais cedo melhor, mais fácil.

2. mais rápido e menos arriscado para refatorar um código refatorado recentemente, em vez de esperar para refatorar o código para estar quase completo.

O que?

1. Todo o código e todo o design são candidatos à refatoração.

2. Uma exceção por não refatorar algo pode ser um código de trabalho com baixa qualidade, mas, por estar próximo de um prazo, preferimos manter nossa dívida técnica em vez de arriscar a planificação.

Você apenas tem que deixá-lo fazer o seu melhor, se isso for ótimo para ambos e economizar seu tempo no futuro!

Felicidades