E todas essas regras de codificação?

Sempre apoiei a idéia de ter regras de codificação para desenvolvedores em uma empresa ou em um projeto específico. Especialmente se a empresa tiver tamanho maior que 10. Quanto maior a empresa, maior a necessidade. Sei que muitas pessoas vão discordar, mas vi projetos que não os têm e o código parece um desastre total.

O verdadeiro problema disso é como fazer com que aqueles que não gostam de usar colchetes nas instruções if ou usem a mesma cadeia de conexões em todos os lugares do código ou o que seja, usem as regras de codificação sem fazê-las se oporem. a ideia?

Envolva-os na solução de um problema e não na luta contra as regras. Pessoalmente, prefiro a idéia de "guias de estilo", "padrões de codificação" ou algo semelhante, na esperança de impedir a reação "regras = más".

Mas mesmo que isso aconteça - costumo pensar que as regras estão em vigor por um motivo, e a maneira de levar as pessoas obstinadas a se virar é fazê-las perceber que, seguindo as diretrizes, elas estão ajudando a tornar o código mais fácil de implementar. leia para todos.

Às vezes, a pressão dos colegas é a melhor solução para isso.

No meu trabalho, usamos as três soluções a seguir:

1) Adote um verificador de estilo de código, como o excelente Checkstyle (para Java) ou StyleCop (para C #). Essas são ferramentas de fácil configuração que podem destacar automaticamente desvios de estilo / regra de codificação. Dá a todos um terceiro neutro para determinar o que é e o que não é aceitável.

2) Adote um modelo de código de reformatação de salvamento automático (aqui está um exemplo usando o Eclipse) (e outro para o Visual Studio) que formatará automaticamente seu código ao salvar. Isso é ótimo para permitir que alguém codifique da maneira que desejar, mas tenha todo o código formatado da mesma maneira em salvar / confirmar. Eu realmente gosto deste e nosso código nunca foi tão consistente.

3) Revisões de código. Espero que você esteja fazendo isso de qualquer maneira, mas uma coisa que eles devem destacar é onde as regras / estilos de codificação estão violando as convenções.

Além do exposto, é importante que todos estejam no mesmo barco e concordem com os estilos / regras para os quais estão trabalhando. Deixe claro que você não obterá o acordo de todos em tudo, mas peça um compromisso da equipe para se manter fiel ao que a equipe decide. Ocasionalmente, revise os estilos / regras escolhidos para dar conta da experiência do mundo real usando-os e a rotatividade da equipe.

O verdadeiro problema disso é como fazer com que aqueles que não gostam de usar colchetes nas instruções if ou usem a mesma cadeia de conexões em qualquer lugar do código, ou qualquer outra coisa,

Eles estão sendo "obstinados" por não usar colchetes ou isso é uma solicitação "obstinada"?

Escolha suas batalhas. Duvido que este seja um dos que vale a pena escolher. Eu não gostaria de trabalhar em qualquer lugar que esperava em qualquer lugar próximo desse nível de detalhe em "código de primeiro check-in". Este é um indicador de bandeira vermelha que a equipe não entende de refatoração.

OO 101 : "Refatorar quando o produto fizer o que precisa". Não antes.

É muito difícil ficar no ombro de todos os desenvolvedores em grandes equipes, certificando-se de que eles colocam chaves onde você acha que deveriam ir - confie em mim;).

Se algo que você realmente sente está dificultando o seu desenvolvimento, precisará de um "gatekeeper". Não permita que as pessoas façam check-in sem uma revisão de código, por exemplo. Peça ao arquiteto técnico ou ao líder da equipe que revise o código e o rejeite até que "corrija" o estilo do código. Em breve, eles se cansarão disso e se ajustarão às regras, possivelmente, apenas enquanto estiverem sendo verificados.

Obviamente, algumas empresas tiram privilégios de check-in completamente de programadores juniores. Quando eles finalmente aprendem as regras de codificação das empresas, obtêm o privilégio.

Eu acho que você está falando sobre problemas de níveis muito diferentes:

como fazer aqueles que não gostam de usar colchetes nas declarações if,

Isso é principalmente um problema de estilo / legibilidade, a menos que haja um problema explícito de precedência do operador. Este último não deve ser muito comum e, de qualquer maneira, é testável por unidade, portanto, fácil de corrigir. O primeiro pode facilmente regredir para uma Guerra Santa, com pouco a ganhar, mas graves consequências negativas para o moral das equipes. Portanto, tenha cuidado - apenas use regras testadas e aceitas por pelo menos algumas equipes / comunidades e que comprovadamente funcionem.

ou use a mesma cadeia de conexões em qualquer lugar do código,

Se você quer dizer constantes mágicas, esse é realmente um problema de manutenção (além de potencialmente de segurança) e, como tal, IMHO qualquer desenvolvedor experiente entenderá e aceitará que é uma coisa ruim.

ou o que seja, para usar as regras de codificação sem fazê-las se opor à idéia?

Você não pode forçar as pessoas a concordar com as regras de codificação - sua única chance é chegar a um entendimento e aceitação comuns dos membros da equipe por meio de discussão e debate (às vezes feroz) . Você precisa usar argumentos lógicos e convincentes , mostrando o valor por trás de cada regra e explicando como a seguir ela pagará pelo inconveniente de ajustar hábitos arraigados. Por outro lado, esforce-se para tornar a transição o mais fácil possível , introduzindo, por exemplo, a formatação automática de código no check-in, de acordo com as regras aceitas.

Ainda assim, às vezes você só precisa aceitar que as pessoas tenham opiniões diferentes , portanto, as regras de codificação que todos podem aceitar serão tolerantes em certos aspectos. Aceite isso e foque nas áreas em que você pode melhorar as coisas com menos esforço.

Envolva-os no estabelecimento de regras. Isso geralmente ajuda a incentivar as pessoas a segui-las.

É para isso que serve a revisão de código. Os revisores de código não devem deixar o código passar que não atenda aos padrões. Certifique-se de não relaxar as regras para correções urgentes. Ter que refazer algumas vezes sob pressão para fazê-lo corrigirá aqueles que relutam em fazer seu trabalho corretamente na primeira vez.

A mesma cadeia de conexão em todos os lugares? A solução é refatorar até remover toda a duplicação. Os codificadores de copiar e colar devem ir para a prisão do programador. (Não ria! Steve Ballmer é o diretor.)

Mas o verdadeiro problema aqui é o seu verbo "make" . Você não pode fazer os programadores fazerem nada e, se o fizer, estará desperdiçando a característica mais valiosa: o profundo envolvimento intelectual resultante do trabalho em algo que lhe interessa.

Do jeito que eu resolveria isso:

1. Insista para que a equipe tenha um padrão de codificação comum. Pode ter 5 linhas, mas todos precisam concordar.
2. Toda vez que você percebe um argumento, insista em que ele o monte e o coloque no padrão de codificação. Se você perceber que as pessoas reformatam as coisas de um lado para outro, trate isso como um argumento.
3. Sempre que um item padrão for acordado, verifique se há uma ferramenta que limpe toda a base de código de uma só vez.
4. A cada dois meses, analise o padrão de codificação e veja quais ainda são verdadeiros e relevantes. O padrão apenas documenta o que as pessoas estão fazendo. E não faz sentido manter itens no padrão que se tornaram óbvios.

A programação é um esporte de equipe ou um trabalho artístico coletivo. O que as pessoas concordam não importa tanto quanto elas concordam e são boas em chegar a novos acordos conforme necessário.