Como lidar com os padrões de codificação no trabalho (eu não sou o chefe)

Eu trabalho em uma equipe pequena, cerca de 10 desenvolvedores. Não temos nenhum padrão de codificação. Há certas coisas que se tornaram a norma, mas algumas maneiras de fazer as coisas são completamente díspares. Meu grande problema é o recuo. Alguns usam guias, outros usam espaços, outros usam um número diferente de espaços, o que cria um enorme problema. Costumo ter conflitos quando mesclo porque alguém usou seu IDE para formatar automaticamente e usa um caractere diferente para recuar do que eu. Eu não me importo com o que usamos, só quero que todos usemos o mesmo.

Caso contrário, vou abrir um arquivo e algumas linhas têm colchetes na mesma linha que a condição, enquanto outras as têm na próxima linha. Mais uma vez, não me importo com qual, desde que sejam todos iguais.

Trouxe a questão dos padrões ao meu gerente direto, individualmente e em reuniões de grupo, e ele não está muito preocupado com isso (existem vários outros que compartilham a mesma opinião que eu). Eu levantei minha preocupação específica com os caracteres de indentação e ele pensou que uma solução melhor seria "criar algum tipo de script que pudesse converter tudo isso quando pressionamos / retiramos do repositório". Suspeito que ele não queira mudar e essa solução parece excessivamente complicada e propensa a problemas de manutenção no futuro (isso também aborda apenas uma manifestação de um problema maior).

Algum de vocês já passou por uma situação semelhante no trabalho? Se sim, como você lidou com isso? Quais seriam alguns bons pontos para ajudar a vender meu chefe nos padrões? Seria uma boa idéia iniciar um movimento de base para criar padrões de codificação, entre os interessados, Estou sendo muito especial, devo deixar para lá?

Obrigado a todos por seu tempo.

Nota: Obrigado a todos pelo ótimo feedback até agora! Para ser claro, não quero ditar um estilo para governá-los todos. Estou disposto a admitir minha maneira preferida de fazer algo em favor do que melhor se adapte a todos. Quero consistência e quero que isso seja uma democracia. Quero que seja uma decisão de grupo em que todos concordem. É verdade que nem todos conseguirão o que querem, mas espero que todos sejam maduros o suficiente para comprometer a melhoria do grupo.

Nota 2: Algumas pessoas estão se envolvendo nos dois exemplos que dei acima. Estou mais atrás do cerne da questão. Ele se manifesta com muitos exemplos: convenções de nomenclatura, grandes funções que devem ser desmembradas, algo deve ser executado em um utilitário ou serviço, algo deve ser constante ou injetado, todos devemos usar versões diferentes de uma dependência ou a mesma, A interface deve ser usada para este caso, como os testes de unidade devem ser configurados, o que deve ser testado, (específico para Java), devemos usar anotações ou configurações externas. Eu poderia continuar.

Um colega de trabalho e eu tivemos um problema semelhante em nossa equipe quando entramos pela primeira vez (entrei para a equipe primeiro, ele entrou cerca de um ano depois). Não havia padrões de código reais. Somos uma loja da MS e nem mesmo os padrões de codificação da MS foram usados. Decidimos liderar pelo exemplo. Sentamos juntos e redigimos um documento que tinha todos os nossos padrões: padrões IDE, padrões de nomes, tudo o que pudemos pensar. Então ele e eu concordamos em seguir o padrão explicitamente. Enviei um e-mail para a equipe (de nós dois) e notifiquei-os de que havíamos encontrado uma falta e iríamos abordar a falta com nosso documento. Convidamos críticas, idéias, comentários, opiniões. Recebemos muito pouco na forma de feedback e apenas um pequeno empurrão para trás. Ele e eu imediatamente começamos a usar os padrões, e quando trouxemos desenvolvedores juniores para nossos projetos, os apresentamos ao padrão e eles começaram a usá-lo. Temos algumas pistas que relutaram no começo, mas começaram lentamente a usar o padrão para muitas coisas.

Descobrimos que muitos dos desenvolvedores juniores haviam reconhecido o mesmo problema, mas estavam esperando por alguém para avançar e tomar a decisão. Uma vez que havia um plano a seguir, muitos estavam ansiosos para adotá-lo. As porcas difíceis de quebrar são as que se recusam a codificar por qualquer outro meio, e geralmente se codificam para fora de cena a longo prazo.

Se você deseja padrões, abra o caminho. Crie uma lista sugerida de padrões que você acha que beneficiariam sua equipe. Envie-o a colegas e leads para obter feedback. Tenho certeza de que outras pessoas da sua equipe têm idéias semelhantes, mas provavelmente não têm o bom senso de fazer algo a respeito. Como Gandhi disse: "Você deve ser a mudança que deseja ver no mundo".

Os padrões não devem ser algo definido e imposto por um gerente. A equipe como um todo deve concordar com os padrões. Se eles não puderem concordar com um conjunto comum de padrões, conseguir que um gerente imponha padrões a eles falhará.

Você e os outros que concordam com você devem dar o exemplo. Comece a usar os mesmos padrões de codificação, publique-os e promova-os para o restante da equipe e peça feedback sobre como melhorá-los.

Aqui está a parte importante ao tentar promover padrões: verifique se o foco não está em encontrar a melhor maneira de fazer as coisas, mas em encontrar uma maneira consistente de fazer as coisas. Por mais que algumas pessoas possam discordar, não existe um estilo de colchete verdadeiro, nem um estilo de comentário verdadeiro etc. O que torna o código mais fácil de ler (e, portanto, mais fácil de manter) é um estilo consistente, não importa qual seja.

Você pode mostrar alguma evidência do tempo desperdiçado devido aos problemas que isso está causando?

Se você está gastando um tempo significativo trabalhando com esses problemas ou está causando bugs que levam tempo para serem corrigidos, esse é um custo que você pode reduzir drasticamente adotando padrões de codificação.

Portanto, mantenha um registro dos problemas que encontrar e o tempo necessário para resolvê-los - tanto para você quanto para (onde você os conhece) seus colegas.

Então, quando você tiver uma quantidade razoável de dados, apresente-a aos seus colegas. Eles devem ver o benefício de adotar um padrão. Caso contrário, mostre os dados para o seu chefe e o chefe dele. Mostre que, ao ter padrões de codificação, você pode economizar o dinheiro da sua empresa e eles devem apoiá-lo na sua adoção.

Em sua situação particular, acho que a solução do seu chefe é boa. Ninguém precisa mudar o que eles têm feito por toda a carreira, e tudo bem, porque os bits do estilo de código que o compilador ignora não importam, desde que o código seja legível. Se todos fizessem um autoformato ao seu estilo no check-out e um autoformato ao estilo padrão ao fazer o check-in, tudo ficaria bem. (Infelizmente, sugeri que, onde eu trabalhasse, fosse contra o argumento de que o codificador não estaria mais escrevendo o mesmo código exato que o servidor de integração contínua vê.)

Eu acho que os padrões de codificação são bons quando aplicados a locais onde faz uma diferença real na qualidade do código: por exemplo, métodos pequenos, classes que têm uma responsabilidade claramente definida, comentários úteis e precisos para os bits mais difíceis etc. Infelizmente, esses aspectos são mais difíceis de verificar automaticamente, mas isso é fundamental para o desenvolvimento de software. Tudo o que você realmente pode fazer é ensinar boas práticas aos outros e aprender a ler código com a chave na linha errada.

Com relação aos padrões de codificação: subirei com quase todo mundo dizendo que os padrões de codificação são uma "coisa boa" (versus nenhum padrão).

No entanto, não se empolgue. Eu trabalhei em alguns projetos que ditavam um estilo de indentação específico, até o número de caracteres (e quando os projetos chegam tão longe, eles inevitavelmente escolhem algo estúpido como o 8 recuo do espaço). Não se preocupe com as pequenas coisas.

Uma solução simples: ofereça aos desenvolvedores um conjunto limitado de opções para chave e recuo, mas dite que o estilo e a indentação da chave devem ser consistentes em um módulo. (Você deseja que foo.h e foo.cpp sigam o mesmo estilo, não é?) Os mantenedores devem se adaptar ao estilo existente; eles não podem reescrever um módulo para se adequar ao seu estilo caprichoso. Vários estilos dentro de um módulo são apenas confusos e são um sinal de negligência. Quando vejo essa bobagem, fico me perguntando o que mais há de errado.

Você também pode querer pensar em banir guias para recuo no conteúdo salvo de um arquivo . A maioria dos IDEs / editores faz um trabalho razoável ao converter guias de entrada do usuário em espaços, e a maioria tem opções para tornar essa tradução automática. Muitos fazem um trabalho de baixa qualidade quando o arquivo já contém guias, particularmente um conjunto misto de guias e espaços.

Tudo isso dito, acho que você pode ter um problema mais profundo em seu projeto. Você mencionou problemas com a fusão. Se você precisar fazer muita fusão, pode ser um sinal de um particionamento ruim do projeto. Assim como muitos cozinheiros estragam o caldo, muitos programadores que operam no mesmo arquivo estragam o projeto. Por que Joe, Susie e você estão tocando em foo.cpp?

Essa é uma das áreas em que algumas pesquisas são feitas. Basicamente, a principal questão é se você está fazendo análises de código. As revisões de código são sem dúvida o meio mais eficiente para melhorar a qualidade do código. (Fonte: Software Engineering Institute, CMU). É certamente mais eficiente que um testador extra.

Agora, as revisões de código se beneficiam de um padrão de codificação comum, pois isso facilita a leitura do código de outras pessoas. Isso fornece um argumento de duas etapas para introduzir padrões de codificação: no final, torna mais barato produzir um bom código.

Como já existem "vários outros" que estão com você, sugiro uma reunião improvisada. Convide todos os desenvolvedores, demore um pouco e descubra o que as coisas estão incomodando você e seus colegas no dia-a-dia. Não tente encontrar soluções específicas a princípio, apenas descubra o que precisa mudar na maneira como você está escrevendo código no momento.

Então, veja se todos podem concordar com alguns conceitos básicos. A sugestão de usar o mesmo estilo em cada módulo que o @David Hammen trouxe é um bom começo, e acho que a maioria dos desenvolvedores poderia concordar prontamente.

Se, depois de entender isso, você achar que pode concordar com algum estilo básico para escrever um novo código, isso é uma boa adição. Concentre-se nas coisas que realmente afetam a capacidade de manutenção; os problemas de nomeação estariam no topo da minha lista pessoal, porque se você tiver meia dúzia de estilos de nomeação diferentes em um único produto de qualquer complexidade notável, isso se tornará uma dor de cabeça muito rapidamente, mas, novamente, concentre-se no que você e sua equipe consideram importante . Rascunhe um pequeno documento que todos possam concordar em seguir (mesmo que eles próprios tenham um estilo de animal de estimação diferente) e envie-o por correio para todos da equipe. Torne-o um documento "vivo", atualize-o com o tempo, mas certifique-se de não torná-lo muito rígido e específico.

A menos que seu chefe esteja envolvido na escrita de código, ele não deve se preocupar muito com o estilo exato que é adotado (desde que se concentre na legibilidade e manutenção), mas ele deve poder ver os benefícios de todos na equipe seguindo um estilo comum. ao escrever código.

Há algumas coisas que são dolorosas. O mais doloroso é um IDE que reformata automaticamente o código, combinado com desenvolvedores que configuram seus IDEs de maneiras diferentes. Toda vez que você compara o código, você tem centenas de alterações depois que alguém com configurações diferentes edita o código. Isso é inaceitável. Aqui você precisa bater a cabeça de todos juntos, concordar com um conjunto de configurações e rejeitar quaisquer check-ins de qualquer pessoa usando configurações diferentes. Se eu alterar uma única linha de código, os diffs deverão mostrar uma única linha de código alterada, e não centenas.

Todo o resto é inofensivo ou existem maneiras melhores de fazer coisas que os outros possam convencer. Aqui a regra deve ser: não mexa no código de outras pessoas, a menos que você realmente o melhore. E uma mistura dos estilos A e B é sempre pior que os estilos A ou B.

Certifique-se de seguir as melhores práticas. O que é diferente por idioma. Mas lá você não precisa de padrões (que podem ter sido escritos por alguém bem-intencionado, mas não realmente qualificado), mas todos devem tentar dar bons exemplos.

Definitivamente, evite lutas pelo poder. Não há nada pior do que um pouco de Hitler em sua equipe tentando forçar todos a sua vontade. Infelizmente, esse é o cara que será voluntário para escrever seus padrões de codificação :-(

Todos os exemplos que você deu são basicamente sobre espaço em branco e formatação. Se esse é o maior problema, eu meio que concordo com o seu gerente: não é nada demais.

Onde os padrões são realmente muito úteis é nomear coisas e reduzir a complexidade. Como nomear identificadores, classes, onde colocá-los, etc. Manter os nomes consistentes é extremamente importante, especialmente em um projeto grande. As regras para reduzir a complexidade incluem manter as funções sob um certo número de linhas (dividi-las em funções menores) ou manter as listas de parâmetros abaixo de um certo número de argumentos (talvez você deva agrupá-las em um objeto e distribuí-las).

Se um desenvolvedor específico da sua equipe escreve um código que é mais difícil de entender / depurar, pois inclui muitos trechos longos de código com nomes de variáveis ​​de letra única, esse é um bom motivo para adotar alguns padrões, e não algo que possa ser corrigido. um roteiro. É bom ressaltar (com tato) como algo que os padrões podem melhorar.

Outro motivo pelo qual seu gerente pode não vê-lo como um problema é que você não lê o código um do outro com muita frequência. Isso pode acontecer quando todo mundo tem sua própria área do código e não se aventura muito fora dele. Isso funciona muito bem até que alguém saia da organização, o que pode acontecer por vários motivos bons ou ruins. Os padrões que ajudam a legibilidade tornarão mais fácil para um novo desenvolvedor assumir a manutenção de um pedaço de código.

conflitos quando mesclo porque alguém usou seu IDE para formatar automaticamente e usa um caractere diferente para recuar do que eu

Parece que este é seu problema, não a formatação, mas a reformatação. Esse é um grande problema para os SCMs e o conselho é simples: não faça isso. Assim, da próxima vez que alguém re-formatar todos os espaços em guias ou refatorar os colchetes para o estilo preferido deles, será necessário tapa-los. Faça-os fazer a mesclagem; permaneça sobre eles, parecendo desaprovar a perda de tempo que a falta de consideração causou.

A alternativa é colocar um formatador de pré-confirmação, que sempre formata todo o código no estilo padrão antes do check-in. Se você tem uma equipe de desenvolvedores que reformata o formato normalmente, essa é uma boa opção - o SCM sempre verá o mesmo formato, portanto os deltas serão pequenos e agradáveis ​​de mesclar.

Quando alguém sugere um novo padrão de codificação onde eu trabalho, nós votamos nele. Se obtiver uma votação majoritária, será aceito ou rejeitado. Se você não fizer isso, não conseguirá aceitar seus padrões e eles não serão usados, mesmo que estejam documentados.

No seu problema específico, sua melhor aposta provavelmente estará começando com a sugestão de Joel e liderada pelo exemplo. Reúna 1 ou 2 programadores que se preocupam com isso, chegue a um acordo e você terá força para impor sobre os preguiçosos.

Agora, para a questão genérica, acho melhor simplesmente modular . Cada pessoa obtém um arquivo diferente; se você precisar dar manutenção a um arquivo, manterá intactos os padrões de codificação, mesmo que sejam diferentes dos outros. Precisa escrever no mesmo arquivo? Crie um arquivo de subconjunto e inclua-o.

Não tente isso!

Liderar pelo exemplo contrário. Tente tornar o seu formato de código o mais horrível possível e verifique várias alterações horrivelmente formatadas no código bonito de outras pessoas. Quando a reação (inevitável) ocorrer, diga que o que você está fazendo é bom porque não há um padrão de codificação.

Se você não for linchado por seus colegas de trabalho (!!), poderá acabar com um padrão de codificação.

Obviamente, esta é uma estratégia de alto risco ... :-)