Você segue a convenção de nomenclatura do programador original?

Question

Se você assumir um projeto de alguém para fazer alterações simples que você siga sua convenção de nomeação? Acabei de receber um projeto onde o programador anterior usado Hungarian Notation em todos os lugares. Nosso principal produto tem um padrão de nomenclatura, mas nós tivemos um monte de gente que relatórios personalizados ao longo dos anos e fazer o que sentia.

Eu não tenho tempo para mudar todos os nomes de variáveis ??já no código embora.

Estou inclinado para readablity apenas para continuar com a sua convenção de nomeação.

Answer 1

Sim, eu faço. Ela torna mais fácil a seguir pelas pessoas que herdam-lo depois. Eu tento e limpar o código um pouco para torná-lo mais legível se é realmente difícil de entender.

Answer 2

Eu concordo sugerem que deixando o código como o autor escreveu é bom enquanto que o código é internamente consistente. Se o código é difícil de seguir por causa da inconsistência, você tem uma responsabilidade para com o futuro mantenedor (provavelmente você) para torná-lo mais claro.

Se você gastar 40 horas para descobrir o que a função faz, porque ele usa variáveis ??mal nomeadas, etc., você deve refactor / renomeação para maior clareza / add comentário / fazer o que for apropriado para a situação.

Dito isto, se o único problema é que o estilo principalmente consistente que o autor utilizado é diferente do padrão da empresa ou o que você está acostumado, eu acho que você está perdendo seu tempo renomeando tudo. Além disso, você pode perder uma fonte de conhecimento se o autor original ainda está disponível para perguntas, porque ele não reconhecerá o código mais.

Answer 3

Se você não está mudando o código existente para o seu padrão, então eu diria que ficar com as convenções originais enquanto você está mudando esses arquivos. Mistura de dois estilos de código no mesmo arquivo está destruindo qualquer benefício que um estilo de código consistente teria, e o próximo cara teria que perguntar-se constantemente "que escreveu esta função, o que é que vai ser chamado - FooBar () ou FooBar ( )? "

Este tipo de coisa fica ainda mais complicado quando você está importando bibliotecas 3o partido - você não quer reescrevê-los, mas seu estilo de código pode não coincidir com o seu. Então, no final, você vai acabar com várias convenções de nomenclatura diferentes, e é melhor para desenhar linhas claras entre "o nosso código" e "seu código".

Answer 4

Muitas vezes, fazer uma mudança por atacado para uma base de código apenas para estar em conformidade com o guia de estilo é apenas uma maneira de introduzir novos bugs com pouco valor acrescentado.

Isto significa que ou você deve:

1. Atualize o código que você está trabalhando em conformidade com a diretriz de como você trabalha nele.

2. Use as convenções do código para futuras auxiliar os esforços de manutenção.

Eu recomendo 2., mas Hungarian Notation faz sangrar meus olhos: p.

Answer 5

Se você está mantendo o código que outros escreveram e que outras pessoas estão indo para manter atrás de você, você deve isso a todos os envolvidos para não fazer alterações gratuitas. Quando eles vão para o sistema de controle de código fonte para ver o que mudou, eles devem ver o que era necessário para corrigir o problema em que estava trabalhando, e não um milhão de diffs porque você fez um monte de pesquisas e substitui globais ou reformatado o código para caber sua convenção favorito cinta correspondente.

Claro que, se o código original realmente é uma porcaria, todas as apostas estão fora.

Answer 6

Geralmente, sim, eu iria para a convenção e legibilidade sobre os padrões neste cenário. Ninguém gosta que a resposta, mas é a coisa certa a fazer para manter o maintainable código longo prazo.

Quando o código de leitura de um bom programador, ele deve ser capaz de analisar os nomes de variáveis ??e manter o controle de vários em sua cabeça - desde que a sua consistente, pelo menos dentro do arquivo de origem. Mas se você quebrar essa consistência, ele provavelmente vai forçar o programador a leitura do código de sofrer alguma dissonância cognitiva, que passaria então a torná-lo um pouco mais difícil de acompanhar. Não é um assassino - bons programadores vão passar por isso, mas eles vão amaldiçoar seu nome e, provavelmente, colocar você em TheDailyWTF .

Answer 7

Eu certamente continuar a usar a mesma convenção de nomenclatura, como ele vai manter o código consistente (mesmo se ele é sempre feio) e mais legível do que mistura convenções de nomenclatura de variáveis. Os cérebros humanos parecem ser bastante bom em reconhecimento de padrões e você realmente não quer jogar o cérebro uma bola curva por gratuitamente quebrando o dito padrão.

Dito isso, eu sou nada, mas alguns de Hungarian Notation, mas se é isso que você tem que trabalhar com ...

Answer 8

Se o arquivo ou projeto já está escrito usando um estilo consistente, então você deve tentar seguir esse estilo, mesmo se estiver em conflito / contradiz seu estilo existente. Um dos principais objetivos de um estilo de código é a consistência, então se você introduzir um estilo diferente no código que já está consistente (em si) você solta essa coerência.

Se o código é mal escrito e requer algum nível de limpeza, a fim de entendê-lo, em seguida, limpar o estilo torna-se uma opção mais relevante, mas você só deve fazê-lo se for absolutamente necessário (especialmente se não houver testes de unidade) como você executar a possibilidade de introduzir alterações significativas inesperadas.

Answer 9

Absolutamente, sim. O único caso em que eu não acredito que é preferível seguir convenção de nomenclatura do programador original é quando o programador original (ou devs subsequentes que tenha modificado o código desde então) não seguir qualquer convenção de nomenclatura consistente.

Answer 10

Sim. Eu escrevi isto em um doc padrões. Eu criei a minha empresa atual:

substitui o código existente todas as outras normas e práticas (sejam elas normas toda a indústria ou os encontrados neste documento). Na maioria dos casos, você deve Chameleon seu código para coincidir com o código existente nos mesmos arquivos, por duas razões:

1. Para evitar ter vários estilos distintos / padrões dentro de um único módulo / arquivo (que contradizem o propósito de normas e manutenção cesto).
2. O esforço de refatoração de código existente é propenso a ser desnecessariamente mais caro (demorado e propício para a introdução de novos bugs).

Answer 11

Pessoalmente sempre que eu assumir um projeto que tem um esquema de nomenclatura de variáveis ??diferentes que tendem a manter o mesmo esquema que estava sendo usado pelo programador anterior. A única coisa que faço diferente é para quaisquer novas variáveis ??acrescento, eu coloquei um sublinhado antes do nome da variável. Dessa forma eu posso ver rapidamente os meus variáveis ??e meu código sem ter que ir para a história fonte e comparar as versões. Mas quando se trata de me herdar código simplesmente ilegível ou comentários que normalmente irá passar por eles e limpá-los da melhor forma possível, sem re-escrever a coisa toda (Chegou a isso). Organização é a chave para ter um código extensível!

Answer 12

se eu posso ler o código, I (tentativa) para tomar as mesmas convenções se não é de qualquer maneira legível eu preciso refatorar e mudando assim (dependendo do que seu gosto) considerável

Answer 13

Depende. Se eu estou construindo um novo aplicativo e roubar o código de um aplicativo legado com nomenclatura de variáveis ??porcaria, eu vou refazer uma vez que eu colocá-lo em meu aplicativo.

Answer 14

Sim .. Há litte que é mais frustrante em seguida, caminhando para uma aplicação que tem dois estilos drasticly diferentes. Um projeto que eu reciently trabalhou em duas maneiras diferentes de arquivos de manipular, duas maneiras diferentes de implementar telas, duas estruturas FUNDIMENTAL diferentes. O segundo codificador mesmo foi tão longe para fazer o novo características parte de uma dll que é chamado a partir do código principal. Maintence era um pesadelo e eu tive que aprender ambos paradigmas e esperança quando eu estava em uma seção que eu estava trabalhando com a direita.

Answer 15

Quando em Roma, faça como os romanos.

(exceto para nomes de variáveis ??de índice, por exemplo "iArrayIndex ++". Parar tolerar que idiotice.)

Answer 16

Eu penso em fazer uma correção de bug como um procedimento cirúrgico. Entrar, perturbar o menos possível, corrigi-lo, sair, licença como poucos vestígios do seu estar lá quanto possível.

Answer 17

eu faço, mas, infelizmente, lá onde vários desenvolvedores antes de mim que não viveu a esta regra, então eu tenho várias convenções de nomenclatura para escolher.

Mas às vezes ficamos o tempo para acertar as coisas assim, no final, será agradável e limpo.

Answer 18

Se o código já tem um estilo consistente, incluindo nomeação, vou tentar segui-lo. Se os programadores anteriores não foram consistentes, então eu me sinto livre para aplicar o padrão da empresa, ou os meus padrões pessoais se não houver qualquer padrão empresa.

Em ambos os casos eu tento marcar as mudanças que eu fiz enquadrando-os com os comentários. Eu sei que com os sistemas de hoje CVS isso muitas vezes não é feito, mas eu ainda prefiro fazê-lo.

Answer 19

Infelizmente, na maioria das vezes a resposta é sim. Na maioria das vezes, o código não seguir boas convenções por isso é difícil de seguir o precedente. Mas para facilitar a leitura, às vezes é necessário ir com o fluxo.

No entanto , se é uma pequena o suficiente de um aplicativo que eu posso refatorar um monte de código existente para "cheirar" melhor, então eu vou fazê-lo. Ou, se isso é parte de uma grande re-escrever, eu vou também começar a codificação com os padrões de programação atuais. Mas este não é geralmente o caso.

Answer 20

Se há um padrão no aplicativo existente, eu acho que é melhor para segui-lo. Se não existe um padrão (tabulações e espaços mistos, suspensórios em todos os lugares ... oh o horror), então eu faço o que eu sinto é melhor e geralmente executar o código existente através de uma ferramenta de formatação (como Vim). Eu sempre vou manter o estilo de capitalização, etc do código existente se existe um estilo coerente.

A minha única excepção a esta regra é que eu não vou usar notação húngara a menos que alguém tem uma arma na minha cabeça. Eu não vou ter tempo para renomear o material existente, mas qualquer coisa que eu adicionar novo não vai ter qualquer verrugas húngaro sobre ele.