Pode haver muita uniformidade nos padrões de codificação?

12

Existe uniformidade demais? Onde trabalho, é claro que temos padrões, incluindo convenções de nomes, arquiteturas, estruturas para alavancar etc. No entanto, ultimamente, tem havido muitas críticas às coisas que eu consideraria mais estilo.

Por exemplo, escrevendo ifinstruções em várias linhas versus uma linha, usando o ??operador coalescente n # c em vez de == null, digamos , quantidades de espaçamento para recuos etc.

Parece-me que isso começa a ser mais uma escolha de estilo pessoal e não precisa ser uniforme em uma equipe ou empresa. O que uma pessoa pensa que lê com mais clareza o que outra pessoa pode não entender. Existe algum valor para essa uniformidade "extra"?

programming-practices team coding-standards Gratzy
fonte
2
Oi Gratzy, Programmers.SE não é um painel de discussão ; estamos aqui para resolver problemas reais que você pode estar enfrentando. Você tem um problema real que está tentando resolver? Em caso afirmativo, você pode reformular sua pergunta para manter as respostas construtivas e fora das armadilhas de se tornar uma discussão?
1
@ Gratzy, de outra forma, dada a situação que você enfrenta pessoalmente, quais seriam os critérios para uma resposta correta?
2
@ Mark Trapp, de acordo com as perguntas frequentes, estes são os critérios para uma pergunta - Espera-se que todas as questões subjetivas sejam construtivas. Como definimos isso? Questões subjetivas construtivas ... 1. inspiram respostas que explicam "por que" e "como". 2. tendem a ter respostas longas, e não curtas. 3. tenha um tom construtivo, justo e imparcial. 4. convide a compartilhar experiências sobre opiniões. 5. insistem em que a opinião seja apoiada por fatos e referências. 6. são mais do que diversão social irracional. Eu acredito que a minha pergunta cobre a primeira 4 no mínimo
Gratzy
2
@Gratzy também da FAQ: "Você só deve fazer perguntas práticas e respondíveis com base nos problemas reais que você enfrenta. Perguntas abertas e tagarelas diminuem a utilidade do nosso site e tiram outras perguntas da primeira página".
2
@ Mark Trapp Eu já afirmei critérios para uma resposta aceitável e sim, como eu disse, este é um problema real e, francamente, pelo interesse na pergunta e nas respostas que eu diria que outros concordam.
Gratzy

Respostas:

16

Uniformidade não é um problema (é bom), mas rigidez ou inflexibilidade podem ser. Se, na luta pela uniformidade, você se torna dogmático, o dano que está causando à equipe pode ser maior do que o bem que advém da (possivelmente) uniformidade resultante.

É melhor definir o estilo básico para as coisas mais importantes (padrões de nomeação e uso de maiúsculas, recuo, colocação de novas linhas e colchetes, etc.), definir recomendações para coisas menos importantes (se formato de declaração, outro espaço em branco entre parênteses, etc.) e não se preocupe com o resto.

Nicole
fonte
1
Eu estive lá
+1, disse o que eu quis dizer, mas melhor!
FrustratedWithFormsDesigner
@ Pierre é por isso que você é freelancer agora? :)
Nicole
na verdade não, mas já conheci muitas pessoas obsessivas sobre diretrizes. É assustador como pode ser extremo. Eu acho que você definiu o limite muito bem.
7

Quando potencialmente dezenas de pessoas estão trabalhando em um projeto ao longo dos anos de sua vida útil, às vezes fica confuso quando você precisa pular estilos. Imagine ler um livro em que capítulos diferentes são escritos por autores diferentes, que apenas mantêm um estilo de escrita. É possível, mas é irritante.

Atualmente, a maioria dos IDEs pode aplicar estilos, portanto, se necessário, você pode distribuir (como parte do código-fonte do projeto) um arquivo de preferências IDE que especifique o estilo de codificação escolhido e que todos o instalem e o usem para formatar o código que estão escrevendo . Aposto que existem maneiras de reformatar / estilizar o código no check-in (embora eu ainda não tenha investigado isso).

FrustratedWithFormsDesigner
fonte
Sim, você provavelmente poderia colocar um script de formiga lá em algum lugar.
Michael K
1
IntelliJ, pelo menos, tem uma opção para reformatar o código antes do check-in.
Nicole
3

Um caso de excesso de uniformidade que eu vi é ter um único padrão que se aplica a todas as linguagens de programação, independentemente da adequação:

  • Desencorajando gotoaté mesmo em linguagens como C, sem try... catch.
  • Usando InitialCapsnomes (como no MFC e C # da Microsoft) em JavaScript, onde está a biblioteca padrão initialLowerCase.
dan04
fonte
2

Eu não acho que exista muita uniformidade. No entanto, muitas vezes considero muita ESPECIFICIDADE nos padrões de codificação. Os benefícios de todos que colocam a chave de abertura em uma linha separada são duvidosos na melhor das hipóteses e não superam o tempo gasto discutindo sobre isso ou corrigindo problemas estéticos no código.

JohnFx
fonte
2
@Tungano Eu não poderia concordar mais. O paradoxo dos padrões de codificação é que vale a pena ter, mas não vale a pena discutir.
Charles E. Grant
3
Não vejo como forçar um estilo em particular na garganta de um programador vai ajudá-lo a evitar esses argumentos. Na verdade, eu argumentaria que fazer um programador se adaptar a um estilo que ele não gosta Encoraja esses argumentos, ou pelo menos ressentimento.
precisa saber é o seguinte
1
@JohnFx, porque a maioria dos programadores perceberá que a consistência do estilo contribui muito mais para a qualidade e a manutenção do código do que qualquer escolha específica de estilo. Na minha experiência, você pode fazer uma contagem rápida da equipe, ver o que as pessoas gostam e não gostam e chegar rapidamente a um consenso. Ocasionalmente, alguém terá um bugaboo peculiar e você os acomodará, depois eles renderão o bugaboo de outra pessoa. Se eu me pego discutindo por cinco minutos com a equipe sobre por que o estojo de camelo é ruim, simplesmente desisto e me rendo como prova de minha flexibilidade pessoal.
Charles E. Grant
1
Eu diria que a maioria dos programadores PENSA que a consistência do estilo faz uma contribuição tão grande, mas realmente não. Parece que deveria, é irritante olhar para o código que não combina com o seu estilo de animal de estimação, e passar por um bloco de código "limpando-o" para pequenos problemas cosméticos é uma boa maneira de procrastinar. Olha, eu costumava estar naquele movimento também até perceber que estava me concentrando no revestimento de ouro e não na entrega.
precisa saber é
1
Eu trabalho com código da nossa equipe alemã, alguns projetos de OSS e algum código antigo que temos, bem como nosso material atual. Alguns são C, outros C ++, outros C #. Então, eu tenho que trabalhar com vários estilos de código diferentes o tempo todo. Quando você faz isso, percebe como são mesquinhas as diretrizes de estilo exigidas nos padrões. Se eu posso mudar de um projeto para outro, posso lidar com alguém colocando o {} em lugares diferentes. É por isso que acho que o único padrão que vale a pena é aquele com 1 regra: "consistência dentro de cada projeto".
Gbjbaanb
2

Eu teria 2 argumentos para a uniformidade:

  • Promoção da propriedade coletiva. Que alguém possa editar o código de outra pessoa sem temer que o "bebê" de alguém esteja prestes a ser prejudicado pela mudança. Uma espécie de mentalidade "Estamos todos juntos nisso".

  • Facilidade de adicionar a ele. Se algo já foi feito em outro lugar, isso pode ser utilizado e reutilizado. Certas convenções podem ajudar a facilitar a leitura ou a alteração das coisas, por isso, esse é outro benefício para minha mente.

JB King
fonte