Eu sei que ficou provado que um padrão de codificação ajuda enormemente. No entanto, existem muitas ferramentas e IDEs diferentes que serão formatados para qualquer padrão que o programador preferir. Desde que o código seja limpo / comentado (e não seja uma bagunça de espaguete), não vejo a necessidade de um padrão de codificação.

Existem argumentos para o desenvolvimento de um padrão de codificação (não temos um, mas eu estava pensando em criar um)?

No entanto, existem muitas ferramentas e IDEs diferentes que serão formatados para qualquer padrão que o programador preferir.

Boa sorte com isso. Minha experiência, há um pequeno número de ferramentas (zero!) Que podem reformatar adequadamente o código do formato X para o formato Y. Existem muitas coisas que atrapalham. Abas vs espaços, instruções com várias linhas, etc. Veja a implementação do GNU dos arquivos de biblioteca padrão do C ++. O que você pode fazer é fazer com que o seu IDE faça é usar sempre espaços em vez de guias e simplesmente não se incomode em reformatar o código externo. Agora, seu código tem a aparência que você gosta e o código estrangeiro é a aparência que o autor original escreveu.

Um estilo de indentação específico é a última coisa que um padrão de codificação deve especificar. Isso está prestes a começar uma guerra religiosa de programação. Na IMO, um padrão de codificação deve especificar um conjunto razoável de estilos de indentação aceitáveis, mas deixar os detalhes específicos para os autores de um pacote. O estilo de indentação é, ou deveria ser, uma pequena parte de um padrão de codificação. Regra número zero dos padrões de codificação: não se preocupe com as pequenas coisas. O estilo de recuo é uma coisa pequena.

Coisas maiores:

• Como nomeio as coisas?
• Certas partes do idioma estão fora dos limites?
• O código precisa ser compilado e com que configurações do compilador?
• O código precisa passar determinadas métricas?
• Que tipo de teste é necessário?
• Que tipo de documentação é necessária, tanto no código (comentários) quanto em outros lugares?
• Mais importante, como obtenho uma renúncia ao padrão?

Adenda
Talvez ainda mais importante seja o que não colocar nos padrões de codificação. Tópicos como escrever requisitos não pertencem aos padrões de codificação. Detalhes sobre o teste também não pertencem. Um projeto não deve usar os padrões de codificação como substituto do plano de gerenciamento do projeto, do plano de gerenciamento de testes, do plano de verificação e validação etc. O objetivo dos padrões de codificação é melhorar a segurança, a qualidade, a compreensibilidade, a manutenção, e outras "ilidades". Existem várias maneiras de garantir que isso não aconteça. Apenas alguns: tornando os padrões um livro tão complexo quanto as leis tributárias de alguns países, incitando a programação de guerras religiosas, tendo convenções de nomes ruins.

Os padrões de codificação podem ter conseqüências não intencionais. Exemplo: Alguns tolo de um engenheiro de projeto vai interpretar a "nenhuma mágica números governar" para significar que if (index == 0) {...}e for (ii = 0; ii < 3; ++ii) {...}deve ser alterado para if (ZERO == index) {}e for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}não rir. Eu já vi isso acontecer. Hoje em dia, quando escrevo um padrão de codificação, é uma "diretriz de números não mágicos", e não uma regra para combater esse tipo de tolice.

O padrão de codificação não é a defesa número um contra más práticas de programação / práticas perigosas de codificação. A revisão do código é. Apesar de muitos anos de automação, ainda não há nada melhor do que um conjunto subjetivo de olhos humanos olhar e julgar um pedaço de código.

Os padrões de codificação não são apenas os parâmetros preferidos para indent- eles também incluem convenções de nomes, convenções de comentários e um grande número de recomendações possíveis para idiomas, uso de recursos de idioma etc.

Mais ao ponto, você ainda precisa documentar tudo isso em algum lugar. E, finalmente, nem todo mundo vai querer usar um IDE que reformate o código dessa maneira ...

Se você usa um estilo consistente em uma equipe, seu código fica mais fácil de ler. Quando seu código ficar mais fácil de ler, sua equipe será mais produtiva. Eles serão mais produtivos porque não precisam analisar mentalmente o código e podem se concentrar na lógica e não na sintaxe ao revisar e manter o código.

Se cada pessoa permitir que o IDE reformate o código de acordo com a sua escolha, você tem um dos dois problemas: você deve sempre convertê-lo para o formato original ao salvar ou sofrer com o fato de que os seus diffs mostrarão muito ruído, dificultando a visualização do que mudou na lógica do código.

Resposta curta: Sim, reflete a qualidade .

O que é e por que precisamos disso?

Os padrões de codificação são peças muito importantes de software de alta qualidade. Eles aumentam a produtividade no processo de desenvolvimento, facilitam a manutenção do código e evitam que o código seja vinculado a uma pessoa ou equipe. A consistência no padrão de codificação também diferencia o código criado prematuramente da arte bem criada.

OK, todo desenvolvedor sabe que as convenções de codificação são boas. Mas de onde os padrões devem vir?

É principalmente ditado pelo fornecedor que possui o produto. Todo desenvolvedor pode escolher entre muitos padrões de codificação do setor. Algumas empresas Microsoft, Oracle e Sun Microsystems oferecem diretrizes.

Existem argumentos para o desenvolvimento de um padrão de codificação (não temos um, mas eu estava pensando em criar um)?

Sim, existem padrões da indústria que são recomendados para serem usados. No entanto, cada padrão de codificação é específico para a plataforma de desenvolvimento. Assim, os padrões de codificação são principalmente específicos do idioma. Por exemplo, Java tem um padrão diferente do .NET. Por exemplo, o C # .NET está usando esses padrões nesta referência .

Normas comuns

Os padrões comuns não têm dependências em nenhuma linguagem de programação. Além dos padrões oferecidos pelo fornecedor, também conhecidos como padrões de codificação do setor, existem notações de programação diferentes, como Hungarian Notation ou CamelCase . Eu acho que os padrões de codificação do Microsoft .NET foram inicialmente baseados em notações do CamelCase.

Normas e diretrizes de codificação de equipe

Pensamos que toda equipe de desenvolvimento deve concordar com os padrões de codificação assim que o projeto for iniciado. As diretrizes de codificação geralmente são criadas pelo líder da equipe ou pelo arquiteto-chefe da empresa. Geralmente, é um documento aberto a ser seguido e aprimorado mediante uma necessidade. Por exemplo, em nossa empresa, temos páginas Wiki em que este documento é carregado e disponível para os desenvolvedores da empresa.

Vou tomar a opinião controversa e dizer não, você não precisa de um padrão de codificação . As regras são, como você diz, diretrizes aplicáveis ​​do IDE, melhores práticas gerais que todos em toda empresa devem seguir ou são chamadas de julgamento caso a caso por equipe que devem ser feitas por mais de uma pessoa em uma equipe capaz via programação em pares ou revisões de código.

Coisas como Como devemos nomear essa variável? Quais recursos de idioma devemos usar? Devemos evitar? Qual teste é melhor? É melhor ficar sem resposta até encontrarmos o problema estritamente definido em que estamos trabalhando agora .

Cristalizados a partir dessas decisões minuciosas, padrões / padrões informais dentro das equipes podem surgir, com base na interseção com o atual domínio do problema e as tecnologias em uso. Codificar isso significa que acreditamos que coisas como o padrão de nomenclatura, o subconjunto de idiomas apropriado etc. usado nesses projetos, com base em centenas de micro decisões e adotado informalmente por essas equipes devem orientar todos os projetos no futuro.

Principalmente, isso parece ótimo, mas, na realidade, apenas se torna um ímã para a política. Quais ferramentas podemos forçar todos a usar? O que eu quero forçar outras pessoas a evitar? Se todos concordassem com essas perguntas, não precisaríamos de um padrão. Nós apenas faríamos isso. Na minha experiência, os padrões resultam do desejo de um subconjunto dos desenvolvedores exercer controle sobre outro subconjunto. Normalmente, esse tipo de política e o policiamento tecnológico a seguir apenas sufocam a inovação, em vez de fornecer orientação.

Se você deseja orientação real , em vez de ler um padrão com várias regras inúteis, encontre membros capazes de sua equipe e pergunte a eles o que eles pensam. O que eles foram queimados? Como eles sugerem que você escreva código? Você obterá uma variedade de respostas úteis com muita experiência valiosa para fazer o backup. Você verá muitas interseções com base na experiência comum. Em vez da monocultura aplicada pelo padrão, você também verá muita diversidade, o que só pode ajudá-lo a ver muitas maneiras válidas de resolver problemas.

E quando alguém lhe disser para não fazer algo causador de uma regra no "padrão", mas não tiver experiência ou backup razoável de sua reivindicação, ignore-o. Aqui, o padrão não serviu a ninguém ou fez de alguém um desenvolvedor melhor.

Agora que as aeronaves comerciais são fly-by-wire, você espera que os programas que pilotam o avião com base nas informações dos pilotos funcionem. Quando os programadores escrevem esse código, você espera que eles sigam um conjunto estrito de regras para evitar erros de programação comumente evitáveis. Uma maneira de fazer isso é com um padrão de codificação.

Consulte: Padrões de codificação C e C ++ da Federal Aviation Administration

Preciso dizer mais.

Nota: Não consegui encontrar o padrão atual na FAA online, mas já o vi.

Para mim, é uma questão de disciplina e ser disciplinado sempre ajuda, é um reflexo da qualidade do trabalho que você produz.

Dito isto, eu faria o padrão de codificação tendo em vista o IDE e / ou as ferramentas em uso. Além disso, o IDE deve ser configurado de forma idêntica (por exemplo, o IDE de cada desenvolvedor deve usar todas as guias ou todos os espaços em branco para indentação e o IDE de todos deve ter o mesmo comprimento de guia) para cada desenvolvedor, para que todos possam seguir o padrão facilmente ...

Além disso, scripts de check-in podem ser desenvolvidos e usados, o que pode ajudar a seguir os padrões de codificação até certo ponto; por exemplo, eles podem corrigir o recuo antes de efetivamente enviar o arquivo com check-in ao sistema de controle de versão.

Os padrões de codificação NÃO poderiam ser mais importantes! Sou um usuário ávido do CakePHP e gosto de revisar os conjuntos de alterações de versão para versão e os desenvolvedores não seguem os padrões.

Na verdade, fiquei tão chateado com as diferenças de estilo que tive que escrever Convenções sobre codificação . Custa muito tempo e dinheiro trazendo novos desenvolvedores para uma equipe já existente - imagine imaginar um novo desenvolvedor sem padrões ... aprender o código seria o próximo impossível demais.