Eu odeio um dos nossos padrões de codificação e isso me deixa louco, como processá-lo? [fechadas]

Disclaimer : Não é tão exagerado como o título sugere, mas ainda me deixa desconfortável. Eu só vou expressar honestamente, então leve com um grão de sal. Apenas finja que estou falando sobre esse padrão de codificação com o qual você não gosta de trabalhar.

Edit : O fato de eu não gostar, não significa que não o uso ou imponho.

Decidi fazer esta pergunta com o espírito de como superar um padrão que você não gosta, para não obter ajuda sobre como argumentar melhor como ele pode ser alterado (embora sejam apreciados quaisquer comentários sobre esta última parte). Além disso, trabalho em uma grande empresa e é improvável uma mudança de algo que vive há tanto tempo e que importa tão pouco.

O padrão é o padrão de abertura-cacheado-cinta-em-linha dedicada:

somefunction()
{
    //...
}

Em vez do * claramente superior * (observe o tom de brincadeira / frustração):

somefunction() {
    //...
}

Meus argumentos pessoais contra o padrão:

• Incha código : linhas desnecessárias extras
• Mais difícil de digitar : embora provavelmente seja apenas eu lutando com o padrão, sei que um pressionamento de tecla extra não é tão ruim assim.
• Não é mais fácil de ler : começo a ler uma declaração de função, se instrução, ou qualquer outra instrução de empilhamento de escopo e já não preciso procurar uma chave de abertura. Blocos aninhados com esse padrão me deixam com raiva por algum motivo.
• Usado por pessoas que têm experiência com o Microsoft IDE : acho que deveria haver uma razão argumentada (ou mais) por trás de um padrão, e não apenas adotá-lo por paradigma.

Seus argumentos (e minha maneira de responder internamente a eles):

• Mais fácil de ler, porque você pode ver onde os blocos começam e terminam imediatamente : não consigo entender isso, de que serve o bloco se você não sabe do que ele pertence, então você deve ler ao contrário.
• Eu usei em um IDE da Microsoft e gostei : Uhh ... ok?
• Está no padrão : * encolhe *

Eu sou o único que luta com uma posição opinativa contra um padrão específico ?, como você superou isso ?, qual é a sua opinião sobre qual deveria ser esse padrão em particular (apenas por diversão)?

Se você quiser superar isso - houve uma citação de Torvalds:

Programadores ruins se preocupam com o código. Bons programadores se preocupam com estruturas de dados e seus relacionamentos.

Agora considere: onde ele coloca os programadores que se preocupam com algo tão pequeno como o estilo de reforço imposto pelo padrão de código? A sua base de código é tão primitiva que o suporte é o único problema que vale a pena discutir?

Algumas pessoas gostam do seu jeito e outras não. De qualquer maneira, alguém vai ficar irritado. É apenas a sua vez desta vez. Chupe e continue com o trabalho.

O padrão da equipe está documentado? Se for, há algum motivo no guia de estilo? Honestamente, eu tive que engolir isso várias vezes e fazer um trabalho real. Existem problemas piores, mas eu sinto que você ainda está irritado (a propósito, eu concordo com você no estilo).

O que me ajudou a superar isso:

1. Percebeu que existem benefícios reais para um único estilo (não importa qual seja). Ou pelo menos um monte de gente pensa assim .
2. Exatamente o que você acabou de fazer, escreva por que isso parece errado, para poder postar o argumento bem no futuro.
3. Use uma ferramenta de estilo, pelo amor de Deus , ele salvará sua sanidade. ReSharper , CodeMaid , StyleCop , JSLint , CheckStyle , etc. ... mesmo Visual Studio irá fazer isso por você .
4. Dê um pontapé neste projeto e esteja pronto para o próximo quando puder definir os padrões.

A superioridade de uma convenção sobre a outra é * claramente arbitrária * .

Os problemas de legibilidade que você enfrenta, ou seus colegas de equipe enfrentariam com seu padrão, são apenas uma resistência psicológica à mudança.

O argumento objetivo de legibilidade é a favor da * consistência * em toda a base de código.

Lembre-se de uma época em que você tinha certeza de que estava certo sobre alguma coisa e, durante um período de tempo, percebeu que estava errado, ou pelo menos que estava exagerando há tantos anos. Considere a possibilidade de estar errado novamente e dê ao novo padrão de codificação ou tempo de processo para convencê-lo.

Meus próprios padrões de raiva quando eu era relativamente novo em codificação (digamos cinco anos na minha carreira) eram se os identificadores de múltiplas palavras deveriam ser WrittenLikeThisou written_like_this. Eu nem vou dizer qual eu gostei, mas o ponto é que depois de algum tempo eu mudei de lado e depois de mais algum tempo eu não me importei.

A diferença padrão que você está descrevendo com o aparelho é amplamente arbitrária. Ambas as formas são igualmente boas e para uma empresa, desde que todos façam o mesmo, tudo é bom.

O "claramente superior" de que você está falando é o tipo de superior que as pessoas falam quando falam sobre coisas "às quais estão acostumadas".

Você vai se acostumar com isso em breve e daqui a um ano, o outro caminho será "claramente superior".

Em resumo: lide com isso.

Esse assunto em particular equivale a uma guerra religiosa entre aqueles que preferem um estilo ao outro. Muito poucas pessoas são ambivalentes ...

Em última análise, nem está certo nem errado.

Os guias de estilo e os padrões de codificação existem por várias razões - e um aspecto importante é garantir a uniformidade do layout, que visa reduzir o número de erros óbvios e melhorar a manutenção.

Eu sou o único que luta com uma posição opinativa contra um padrão específico?

A resposta curta é "Não", você não é o único. Mas há coisas mais importantes com que se preocupar. Mesmo nos padrões para os quais se insere, sempre haverá compromisso - testemunhe alguns dos aspectos que chegaram ao C99 e C12 que não fazem sentido para mim.

Até o MISRA-C (sobre o qual tenho influência direta) contém itens com os quais pessoalmente não concordo - mas posso entender por que os outros sentem a justificativa.

como você superou isso?

E é aí que reside a resposta - em vez de se concentrar no motivo pelo qual você não gosta pessoalmente, tente entender por que a pessoa / pessoas que concordaram fizeram isso.

As regras geralmente são introduzidas (em uma porta que está fechando depois que o cavalo trava), para resolver um problema anterior. E se a regra ainda não faz sentido, fale com o proprietário padrão e tente "educá-lo".

Eu acho que você só precisa seguir em frente. Vou tentar abordar suas anotações com minhas próprias opiniões:

• Código Bloats

  Uma linha de código extra não é um código inchado, a menos que você esteja escrevendo centenas de métodos em uma única classe, que adicionará centenas de linhas extras. Então, novamente, se você tiver centenas de métodos em uma única classe, terá outro problema.

• Mais difícil de digitar

  Não posso mais discordar de você, é preciso pressionar a tecla Enter para chegar à próxima linha. E é mais difícil digitar?

• Difícil de ler

  Eu sinto que cada linha de um pedaço de código deve ter uma função específica. Depois disso, você precisaria definir o nome do método em uma linha e, em seguida, as chaves de abrir e fechar em suas próprias linhas separadas.

• Usado por pessoas que têm experiência em MS IDE

  Uhh ... ok?

Em resumo, parece que você está dizendo sobre ser um desenvolvedor .Net em oposição a qualquer outro tipo de desenvolvedor, como se fosse inferior, porque eles usaram um IDE com o padrão deste padrão.

Eu sou o único que luta com uma posição opinativa contra um padrão específico?

Claro que não. Reuniões para determinar os padrões de codificação são horríveis! Eles se arrastam por horas e os participantes se tornam pessoalmente investidos em obter suas próprias idiossincrasias favoritas (e invariavelmente erradas, exceto as minhas) consagradas no padrão. No final, ninguém está feliz com o resultado. Se algo pode ser pior do que a reunião dos padrões de codificação, são as reuniões formais de revisão de código nos vários meses que seguem a determinação do padrão: algumas pessoas tentam adotar o padrão, enquanto outras (intencionalmente ou não) o ignoram e você obtém horas de feedback como: Nas linhas 132, 142, 145, 181, 195 e 221 do SillyFileConverter.cpp, você coloca a chave de abertura na mesma linha quando o padrão de codificação diz claramente que deve estar na linha a seguir !

como você superou isso?

À sua maneira, as reuniões ajudam. Mesmo se você simpatizar inteiramente com o cara que deixou a chave de abertura na mesma linha que a condicional, ou qualquer outra coisa, você ficará irritado com ele por desperdiçar seu tempo, não apenas sugando e seguindo o padrão estúpido. Se o cara é um cretino e faz a mesma coisa repetidamente, torna-se ainda mais irritante. Ficar chateado com esse comportamento torna muito mais fácil justificar a escrita em um estilo um pouco diferente do que você prefere - você certamente não quer ser esse cara , afinal.

Mesmo que você não seja submetido a análises intermináveis ​​de código formal, tente revisar seu próprio código especificamente para conformidade com o padrão. Não importa o que você pensa do padrão, você está apenas comparando o que escreveu com o que o padrão diz. Se você se desafiar toda vez que não cumprir, isso poderá fornecer algum feedback negativo necessário para ajudá-lo a adotar o padrão.

Com esse tipo de coisa, lembro-me de Gulliver em Lilliput. Os liliputianos estavam travando uma guerra pela qual, para abrir um ovo cozido. (O big endian original, pouca luta endian).

Tome como uma oportunidade de rir de si mesmo, eles realmente não vêm com frequência suficiente nos negócios.

Seu exemplo em particular é lamentável, pois é um com o qual alguns concordam e outros não. Discordo de seus argumentos contra, por exemplo, e tenho certeza que muitos outros também, assim como tenho certeza que muitos outros concordarão com eles. Quase me faz pensar que a questão deve ser encerrada, pois é tão subjetiva.

No entanto, a pergunta sobre como lidar com um padrão com o qual você não concorda é possível de responder. Eu acho que a resposta é que, onde as diretrizes de estilo existem e são acordadas e foram usadas, a resposta é apenas sorrir, suportar e lidar com isso. Considere que ter consistência é mais importante. Se a diretriz for imprecisa ou incorreta, pode haver um argumento para a mudança, mas isso é estilístico; portanto, não há argumento realmente separado da preferência pessoal.

Eu vim de um background Java originalmente, então segui o padrão que você mencionou. Eu então mudei para mais C ++ e C # onde o estilo que você odeia é usado. Mas não tem resposta certa ou errada. O mais importante é ter um padrão seguido por todos. Se um padrão de codificação é estilístico como esse e não está claramente errado, tentar argumentar que causará atrito na equipe.

Um formatador + gancho de check-in é um bom começo. Mas não é suficiente, pois o que você escreve não é tão importante quanto o que você observa o dia todo. Em algumas situações, a abordagem do modo Óculos do Emacs - mantenha os arquivos no estilo deles, mas seja mais próximo do seu estilo - é atraente.

Minha experiência com ele - enfrentando exatamente o problema para o qual foi escrito, CamelCapsvs underscore_separated- foi que rapidamente se tornou mais irritante do que útil, mas por algumas semanas suavizou minha transição para (de má vontade) aceitar o estilo da empresa, além de fornecer uma saída para canalizar minha raiva ("ah, eu odeio, deixe-me ajustar as configurações novamente ... aí, pelo menos eu fiz alguma coisa ") ;-)

De qualquer forma, o modo Óculos não lida com o posicionamento da chave, você provavelmente não usa o Emacs e não lê o código exclusivamente no seu editor :-(
Mas o último ponto também é uma oportunidade - se você ler o código na maioria das vezes em uma ferramenta separada, você pode modificar isso para converter estilos sem se preocupar com o ruído de reformatação de ida e volta - porque é somente leitura! Especificamente, se você ler código em algumas interfaces da web, use Greasemonkey.

Aqui estão algumas idéias mais fáceis para mitigação leve:

• Escolha uma fonte mais larga, mas não tão alta, para recuperar as linhas da tela perdidas.

  • Use a tela inteira com mais frequência, se disponível.

• Configure chaves para serem destacadas em uma cor sutil (e fonte menor?), Tornando-as menos visíveis que o restante do código. O recuo deve ser suficiente para a leitura, esp. com o espaço vazio das {linhas ...

• Certifique-se de que o seu editor destaque a chave de abertura correspondente quando terminar }- pode ajudar um pouco quando seus olhos vão instintivamente para o lugar errado.

• Re "mais difícil de digitar": obtenha um editor real, configure-o para abrir uma nova linha automaticamente quando você pressionar {.

Vive com isso.

Isso é claramente cosmético e não altera nada na qualidade do código ou na sua produtividade como desenvolvedor. Nada vale a pena começar uma discussão.

Para esse tipo de padrão de codificação, eu selecionaria consistência em toda a base de código e legibilidade em qualquer abordagem "religiosa" específica (mesmo que bem fundamentada) a qualquer dia.

Pensar nisso como uma decisão democrática da maioria dos membros da equipe sobre um problema não tão importante pode ajudá-lo a superá-lo.

É o padrão:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

A maioria dos que dizem "é o padrão" está seguindo o princípio dos "cinco macacos".

Vá em frente e use o estilo que você deseja. Em seguida, use algum embelezador de código para alterar o código no formato padrão ou corrija seu próprio aplicativo pequeno que converterá o código do seu estilo para o estilo padrão especificado. Use o embelezador antes de verificar o código.
Você também pode fazer o inverso para alterar o código verificado do formato padrão para o formato, quando estiver trabalhando nele.