Minha equipe deve usar algum padrão de codificação comum e bem considerado como base para o seu próprio?


9

A equipe de P&D em que participei decidiu adotar um padrão de codificação. Recentemente, formamos e temos muito pouco código e tempo comum de codificação para basear nosso documento de normas / convenções no que foi desenvolvido organicamente em nossa equipe e em bons exemplos de nosso próprio código etc.

Agora, cada um de nós tem alguma experiência em locais de trabalho anteriores - embora nenhum de nós esteja no estado de dizer "vamos adotar este documento aqui abrangente que eu acho adequado para o tipo de trabalho que fazemos aqui" (*). Além disso, alguns de nós (inclusive eu) só temos experiência em locais sem padrão oficial de codificação ou escrevendo em idiomas diferentes em um ambiente diferente (ambiente de produção de alta pressão semanal, em oposição a um trabalho de desenvolvimento mais orientado à pesquisa)

Portanto, uma das opções em que estive pensando é pegar um documento relativamente conhecido e bem considerado, cortando o que não interessamos / importando e fazendo algumas modificações com base em nossas preferências.

Isto é uma prática comum? Você acredita que essa é uma boa ideia? Nesse caso, qual seria um padrão de codificação de linha de base razoável (não me diga qual é o melhor, não quero iniciar um conflito religioso aqui; apenas aponte o que seria abrangente ou 'neutro' o suficiente para se basear .)

Notas:

  • Esperamos trabalhar com C, C ++, OpenCL, CUDA, Python.
  • Somos uma equipe de 4 pessoas + gerente, que deverá crescer para cerca de 5-6 dentro de um ano ou mais.
  • Em nossa empresa, as equipes são quase totalmente autônomas e geralmente não interagem (nem mesmo usando o código uma da outra - o trabalho é em projetos totalmente diferentes); então - não há considerações em toda a empresa a serem feitas.
  • Com relação às ferramentas, no momento o que sabemos é que vamos usar o Eclipse , portanto, seu formatador de código será pelo menos uma ferramenta. Ctrl + Shift + F tem sido meu amigo
  • Quando escrevo Java, adotei a prática de aderir o mais estritamente possível ao Java eficaz de Bloch . Agora, esse não é um padrão de codificação, mas você pode chamar alguns tijolos, cimento e argamassa para um padrão de codificação. Eu estava pensando em incluir algo assim como parte do 'mix' (lembrando que não fazemos Java).
  • Quero dizer padrões de codificação no sentido mais amplo da palavra, por exemplo, adotar sugestões feitas nas respostas a esta pergunta P.SE .
  • Encontrei uma grande lista de documentos de padrões de codificação em C ++ ; talvez eu deva usar essa nossa linha de base.
  • (*) Isso não é bem verdade, mas não quero complicar essa pergunta com muitos detalhes.

9
O uso de um padrão de codificação criado externamente ajuda a reduzir guerras sagradas sobre estilos de codificação específicos.
Gort the Robot

4
Qual orientação você usa realmente não importa. O que importa é que você use um e que todos concordem em usá-lo . Essa última parte é mais fácil de fazer se você escolher uma sã.
Joachim Sauer

3
As convenções de nomenclatura são superestimadas. Se você possui um módulo em que as funções são CamelCase e outro em que elas são snake_case, não é grande coisa se você concorda em pelo menos seguir a convenção já em vigor para cada componente. Portanto, se a guerra santa esquentar demais, pare e deixe inconsistente.
Jan Hudec

11
Eu tenho muito pouca experiência Eclipse, mas padrão de código (não estilo) Enforcer para Eclipse pode ser útil
Dan Pichelman

11
Então, sua escolha é usar um padrão existente ou gastar tempo e dinheiro para criar um? Não vejo escolha aqui. Vá com a opção gratuita.
Ramhound 12/09

Respostas:


9

Dito de outra forma, você está perguntando se deve iniciar rapidamente os padrões de codificação da sua equipe emprestando padrões externos encontrados. Não parece que alguém da equipe tenha opiniões super fortes (ainda) sobre quais devem ser esses padrões.

Inequivocamente, a resposta é sim.

Um padrão de origem externa é superior a nada. Veja as respostas em " https://softwareengineering.stackexchange.com/q/84203/53019 " para ver algumas das vantagens de ter um padrão. A consistência e a base para mudar são críticas do seu ponto de vista.

Veja também " Como lidar com os padrões de codificação no trabalho (eu não sou o chefe) ", pois entra em algumas dinâmicas da equipe que sua equipe precisa considerar ao selecionar quais padrões devem ser. A equipe precisa possuir seu (s) padrão (s) de codificação, para que todos cumpram de bom grado as restrições impostas à forma como cada pessoa codifica.

Você vinculou a esta pergunta, mas vale a pena apontar a resposta principal e seu foco em entender por que os requisitos estão em vigor. Se você usar um padrão externo, será difícil para sua equipe entender a base por trás de todos esses requisitos. Mas se você aceitar que eles estão lá simplesmente porque sua equipe precisava de algo para começar, será fácil mudar esse padrão externo para algo que funcione melhor para sua equipe.

A existência de qualquer padrão permite que você preencha as regras de formatação que você usará com seu IDE (Eclipse no seu caso). " Vantagens e desvantagens da reformatação forçada de código " traz benefícios a todos da equipe por terem essa consistência com o código em que estão trabalhando e oferece a capacidade de reformatar trechos que você pode emprestar de outros projetos. Um bônus adicional ao usar um padrão externo é que ele já pode estar pré-preenchido na parte de formatação de código do seu IDE.

Alguém da equipe provavelmente reclamará de uma parte específica do padrão e o culpará pelo fato de você ter usado um padrão externo como base. Eles leram:
- Eu odeio um dos nossos padrões de codificação e isso me deixa louco, como processá-lo?
- Como você supera seus próprios preconceitos de codificação quando recebe código legado?
e então percebem que provavelmente teriam reclamado de algo dentro do padrão, não importa de onde ele veio. No número de equipes em que trabalhei, ainda não vi um padrão que todos a) gostem universalmente eb) concordem com todas as partes do padrão. Consulte alguns dos links iniciais para ver como lidar com essas preocupações.


Adendo, você perguntou sobre "qual" você deve usar. Especificamente, não vou responder isso, já que qualquer resposta é potencialmente provocada por guerras de chamas alimentadas por opiniões. No entanto, você pode olhar para o seu IDE (Eclipse) e ver quais opções ele fornece como configuração padrão. Também pesquisaria um pouco e veria se existem projetos que se encaixam no seu IDE e forneceria opções adicionais de padrões para você escolher. Certo ou errado, esses padrões já estão preenchidos para você e podem economizar um pouco de trabalho para sua equipe configurá-lo para todos.


6

Eu começaria com python. O Python possui diretrizes de codificação que quase todo programador python existente a seguir segue. Eles fazem parte da documentação oficial chamada PEP8 .

O C / C ++ é uma bagunça enorme por razões históricas, mas como o python não é, recomendo que você siga a convenção de nomenclatura do python no C / C ++ também por questões de consistência.

Agora, para C ++, é realmente mais importante concordar com expressões comuns e garantir que todos entendam o estilo C ++ moderno e razoável do que qualquer guerra nas convenções de nomenclatura. Você deve começar com os padrões de codificação C ++ e, a partir dos recursos on-line, leia as Perguntas frequentes sobre C ++ .


Na verdade, eu vou acreditar que vamos ter diferentes convenções de nomenclatura para cada um de C, C ++ e Python - pelo menos, as coisas WRT como capitalização, uso de sublinhados etc. MyTypeNameé indiscutivelmente melhor C ++ do que my_type_name_t, e o oposto vale para C. Mas obrigado por as referências.
einpoklum

Para C ++, você pode usar o padrão usado pelo STL e boost. Nem todo mundo gosta, mas como você certamente usará alguns contêineres stl, será consistente com isso.
Laurent Bourgault-Roy

@einpoklum: para não-tipos, toda a biblioteca padrão C, C ++ e Python usam "snake_case"; não há diferença lá. A única diferença é se você deseja usar "MixedCase" para tipos ou também "snake_case". As bibliotecas C e C ++ usam "snake_case", mas, caso contrário, "MixedCase" é muito comum.
Jan Hudec 12/09

@einpoklum Use o padrão definido pela biblioteca padrão para C ++.
Miles Rout

3

Você não pode nem discutir esse tópico sem fazer a distinção entre um padrão de codificação e um padrão de estilo de codificação .

Um padrão de codificação é um conjunto de regras que define quais mecanismos de linguagem você tem permissão para usar, quais não tem permissão para usar e como usá-los. Em outras palavras, você define um subconjunto do idioma usado e / ou um superconjunto, se o padrão de codificação abordar determinadas extensões não padrão.

Um padrão de estilo de codificação se preocupa apenas com questões cosméticas: onde colocar chaves e espaços, como nomear identificadores, como colocar comentários etc.

Essas duas coisas diferentes podem estar localizadas no mesmo documento. No entanto, o mais sério dos padrões de codificação não se preocupa com estilo - os que eu recomendo abaixo não. Provavelmente porque o estilo de codificação é muito subjetivo e, portanto, causa muito atrito quando as opiniões colidem.

Para C / C ++, os padrões de codificação com a melhor reputação são os da MISRA . Eles são projetados principalmente para aplicativos de segurança / missão crítica, mas como a chave para tornar os programas mais seguros é remover e evitar bugs, os padrões MISRA se aplicam a qualquer ramo de programação em que os bugs não sejam desejados.

Os padrões do CERT também são bastante conhecidos e mais tendenciosos em relação à programação de desktop e segurança de software (em vez de segurança). O CERT possui padrões para C, C ++, Java e Perl, e os padrões são gratuitos.

Eu começaria olhando para MISRA e CERT, em vez de algum padrão aleatório de garagem encontrado na web.


11
Eu nunca ouvi falar do MISRA antes e não vejo que seus constituintes sejam atores excessivamente significativos. Você pode explicar a reputação deles? Quanto aos documentos do CERT, você pode esclarecer se esses são padrões para programas seguros especificamente ou padrões mais gerais?
einpoklum

@einpoklum Para começar, o MISRA-C é usado por praticamente todos os fabricantes de automóveis do mundo. Está se tornando um padrão "de fato" para programação C em toda a indústria de sistemas embarcados, onde é mais conhecido. Ainda assim, não há realmente nada no documento MISRA que impeça que ele seja usado em qualquer forma de programa C. Tanto o MISRA quanto o CERT são bastante gerais; eles visam, finalmente, reduzir o número de bugs, práticas inadequadas e vulnerabilidades em um programa. Esses padrões também incentivam a análise de código estático.

1

Usar um padrão existente como base para o seu próprio país tem várias vantagens. Seu código provavelmente será mais semelhante ao código externo, facilitando a leitura / integração do código. Além disso, se você escolher um bom padrão, ele terá sido examinado por especialistas que tiveram boas razões para decidir sobre suas regras específicas. Desde que ninguém em sua equipe esteja particularmente vinculado a um padrão, há poucas razões para não usar um padrão existente como base para o seu.

Se você não tiver certeza de quais padrões de codificação usar, existem algumas primeiras escolhas ideais óbvias. Em nenhuma ordem específica:
1. Qualquer padrão já suportado pelo seu IDE. Provavelmente isso é configurável.
2. Qualquer padrão usado / recomendado pelo autor do seu compilador.
3. Qualquer que seja o padrão usado / recomendado pelo autor da sua estrutura principal (se houver).
4. Qualquer que seja o padrão usado / recomendado pelo (s) autor (es) / designer (s) da sua linguagem de programação.
5. Qualquer que seja o padrão usado / recomendado por uma empresa muito grande.

Eu recomendo que alguém com conhecimento técnico leia sobre qualquer padrão que você esteja usando como base para seu próprio padrão. Um bom padrão geralmente possui uma justificativa para cada regra, o que o ajudará a modificar o padrão para melhor atender às suas necessidades.


0

Um padrão geralmente ajuda na comunicação e manutenção. Na minha opinião, ele deve estar sujeito a alguns benefícios, especialmente em equipes pequenas, e deve evoluir. Chamá-los de diretrizes pode ajudar :-)

Dê uma olhada nas diretrizes do Google para obter inspiração.


5
É muito subjetivo quais diretrizes de codificação escolher para C / C ++. E se existe um que eu não escolheria, é do Google. Eles proíbem muitas coisas geralmente consideradas boas no estilo C ++ moderno por outras como impulso.
Jan Hudec

11
Como sua resposta aborda as preocupações do OP sobre o uso de um padrão externo? A sugestão de uma mudança de nome para os padrões de codificação não ajuda nos principais problemas que eles precisam resolver.

11
@JanHudec Eu concordo. Uma das coisas que ele proíbe é o uso de exceções.
BЈовић

-3

NÃO, eu não me incomodaria - acho que o único benefício seria se sua equipe se mudasse para um local em que esses padrões também fossem usados, o que não é o que você deseja que aconteça :)

Os padrões existem apenas para incentivar uma colaboração mais fácil; portanto, se você souber que uma macro #define está sempre em maiúscula, quando vir um identificador em maiúsculas no código, terá uma boa idéia de que é uma macro. Da mesma forma, outras convenções de nomenclatura ou de estilo lembrarão com o que você está lidando.

Acho que padrões como local e nome do arquivo são mais úteis1 do que os códigos (afinal, o código tem todas as formas e tamanhos, e você ainda precisa lê-lo), embora não saiba que o readme.txt está em / bin / doc / debug / release / documents é uma verdadeira dor de cabeça (como é um caminho tão ruim, mas isso é outra história).

Eu recomendo que você crie seus próprios padrões à medida que avança. Dessa forma, você não apenas obtém os que mais gosta, mas também os que são definitivamente adequados para você, sua equipe e o trabalho que realiza. Se você decidir que realmente não se importa com a aparência de um loop while, ou se as instruções de caso devem ser recuadas de uma certa maneira, então você é bom. Se você decidir que os operadores ++ são banidos, também é bom. Toda sua própria escolha.

Você precisaria facilitar a localização e a atualização, um wiki, talvez, ou uma página da web gerada automaticamente a partir de uma descrição de texto; caso contrário, vá em frente. Os padrões têm uma atitude mítica de algumas pessoas que estão mais interessadas em seguir fanaticamente o padrão do que em escrever um bom código, não são como eles - crie seu próprio padrão que o ajude onde você precisar.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.