Sua empresa possui um padrão de codificação? [fechadas]

Vi recentemente que a Microsoft lançou um documento sobre padrões de codificação (padrões de codificação da estrutura de código da Multifuncional ) e isso me fez pensar ... A empresa em que trabalho não possui padrões formais de codificação. Existem apenas alguns desenvolvedores e estamos juntos o tempo suficiente para evoluir para estilos semelhantes e isso nunca foi um problema.

A empresa em que você trabalha possui padrões de codificação documentados? Se não, por que não? Ter um padrão faz a diferença? Vale a pena escrever um padrão do zero ou você deve adotar outro padrão como o seu (por exemplo, tornar os padrões da Microsoft seus)?

É importante que uma equipe tenha um único padrão de codificação para cada idioma para evitar vários problemas:

• A falta de padrões pode tornar seu código ilegível.
• Discordâncias sobre os padrões podem causar guerras de check-in entre desenvolvedores.
• Ver padrões diferentes na mesma classe pode ser extremamente irritante.

Sou um grande fã do que o tio Bob tem a dizer sobre os padrões:

1. Deixe-os evoluir durante as primeiras iterações.
2. Deixe que eles sejam específicos da equipe, e não da empresa.
3. Não as anote se puder evitá-la. Em vez disso, deixe o código ser o modo como os padrões são capturados.
4. Não legislar um bom design. (por exemplo, não diga às pessoas para não usarem o goto)
5. Certifique-se de que todos saibam que o padrão é sobre comunicação e nada mais.
6. Após as primeiras iterações, reúna a equipe para decidir.

Eu acho que é essencial ter um padrão de codificação, mesmo se tudo o que diz é "usamos recuo de 3 espaços e os colchetes abertos vão para a próxima linha". Alguns benefícios:

• Isso facilita muito a leitura de toda a base de código, uma vez que alternar entre estilos de codificação entre arquivos é irritante.
• Isso facilita a leitura de um único arquivo, pois qualquer arquivo atualizado por dois desenvolvedores com estilos conflitantes acabará tendendo a misturar esses estilos. Ler um arquivo que mistura abas e espaços (e editá-lo mais tarde) é um problema.
• Isso torna mais fácil para os novos desenvolvedores usarem o bom estilo, se houver um padrão explícito, e não implícito.
• Convenções de nomenclatura consistentes facilitam a localização de funções / variáveis. Foi ArraySort ou array_Sort ou sortTheArray ou doSortArray ou ...?

Em termos de adotar um padrão existente, isso realmente não importa - a consistência é o que é importante. Se seus desenvolvedores tiverem uma dúzia de estilos diferentes, é melhor escolher um já publicado. Se todos vocês evoluíram para um estilo bastante consistente, basta escrever isso e usá-lo.

Eu não concordo com o "somos uma loja X", portanto formamos nosso código em todos os idiomas da mesma maneira.

Pessoalmente, descobri que a maioria dos idiomas possui diferentes estilos aceitos.

Eu realmente não suporto quando programadores C escrevem código Java com formatação C. Não apenas não se parece com Java, mas os engana a pensar que podem usar outras práticas semelhantes a C em Java.

Eu acho que se você tem um padrão, deve ser por idioma

Meu ex-empregador tem um padrão de codificação. Estou pensando em documentar formalmente um para mim também.

Ou, como você sugere, encontrar um padrão existente decente e modificar / adotar isso. Para uma empresa, eu certamente sugeriria que analisassem os padrões de codificação existentes, mas criassem / modificassem um para suas próprias necessidades particulares. Não há necessariamente a necessidade de criar uma a partir do zero, mas alguns cuidados devem ser tomados para garantir que o padrão de codificação faça sentido para o tipo de software que a empresa cria.

Sim, ter um padrão de codificação faz a diferença, mas não é uma bala de prata. O código é mais legível, pois não há tantos conflitos de estilo diferentes e alguns erros / armadilhas comuns podem ser evitados. Mesmo com um padrão, você terá algumas variações nos estilos de codificação, mas essa variabilidade será reduzida. O objetivo não é tentar evitar todas as variações ou se preparar para todas as situações possíveis. Um padrão de codificação muito complicado pode ser pior do que nenhum.

Infelizmente não. Então, todo mundo tem seu próprio jeito de usar espaçamento, recuo e assim por diante, tudo misturado (dessa forma, nem precisamos usar a função "culpa" para saber quem é o autor de uma linha de código!)

Mas, pior ainda, alguém escreve nomes de variáveis ​​e classes em italiano, alguém em inglês ...

Eu sempre adapto meu estilo ao da linguagem, biblioteca e estrutura que estou usando, para que um código-fonte pareça uniforme e simples.

Lembre-se de que este é um documento de padrões de codificação específico para o All-In-One Code Framework.

Já trabalhei em várias empresas, algumas das quais tinham um padrão existente e outras (a maioria) ajudaram a desenvolver o padrão. Na maioria das vezes, se você estiver desenvolvendo o .NET, (e mesmo que não esteja, a maioria das regras ainda se aplica), consulte as Diretrizes de Design do Framework . Embora isso seja específico para a criação de APIs voltadas ao público, a maioria das diretrizes se aplica igualmente a qualquer código.

A maior preocupação com os padrões de código é mantê-lo relativamente simples e direto. Você deseja que os desenvolvedores possam internalizar as diretrizes apresentadas, portanto, é inútil fornecer um documento com mais de 50 páginas. Você ainda pode criar esse documento se desejar fornecer informações básicas, exemplos etc., mas também desejará algo que se refira a um conjunto de diretrizes com marcadores. Seu padrão de codificação também deve ser um documento dinâmico e flexível que precisa mudar à medida que a tecnologia muda.

As discussões do padrão de codificação se resumem a isso:

• Sim, você precisa deles, a consistência e o código limpo são a base do bom desenvolvimento.
• O que eles são quase não importa, desde que todos sigam os mesmos padrões.
• Não escreva você mesmo, você acaba em uma discussão interminável e dolorosa. Há muitas por aí que são populares.
• O uso de padrões públicos (como os do MSDN ) oferece um agnóstico de terceiros que não pode ser discutido. Se você quiser discutir com eles, consulte o ponto 2.

Se você estiver desenvolvendo em C # no Visual Studio, o StyleCop é uma vantagem . Se você também estiver usando o ReSharper, o plug-in StyleCop for ReSharper é incrível.

Como somos uma loja de blub, usamos as convenções de programação de blub.

Agora, Paul Graham e seus amigos são muito mais espertos do que nós, mas nós, programadores de blub, todos podemos ler blub uns dos outros, na verdade, qualquer programador de blub pode ler nosso código de blub.

De fato, devido ao design do blub, qualquer programador de blub pode ler e entender qualquer arquivo blub único, porque o blub não possui um sistema de macro.

Se programarmos, digamos, C ou C ++ (somos todos multilíngues, mesmo que programamos em blub), usamos principalmente o estilo blub para novo código ou para código aberto, o padrão do projeto em que estamos trabalhando.

Você precisa de um padrão. Vi padrões diferentes nos diferentes cantos de um aplicativo que tinham leads diferentes que todos queriam fazer "do jeito deles". Talvez o conceito de "padrão" tenha sido mal compreendido. Muito louco. E, os piores padrões são gerados por uma pessoa. Não importa quem é essa pessoa, se apenas uma pessoa desenvolver o padrão, é quase certo que ele seja ruim.

Pode ajudar as pessoas, também pode realmente ajudar com ferramentas:

Se você deseja usar qualquer tipo de formatação automática de código, você realmente precisa padronizar as regras que ela usará; caso contrário, você estará constantemente recebendo muitas alterações de formatação sem sentido, sobrecarregando suas diferenças.

Os conjuntos de regras padrão para ferramentas de análise estática podem muito bem verificar um estilo de nomenclatura específico e, provavelmente, é mais fácil se conformar com isso e escrever um monte de novas regras. (a menos que você simplesmente desative a regra)

por fim, é bom padronizar qualquer coisa que precise ser consultada com alguém de fora da sua equipe. ou seja, você provavelmente deseja um aviso de direitos autorais padrão em seus cabeçalhos, pois não deseja executar todos os novos arquivos gravados pela equipe jurídica da empresa e certamente deseja obter os nomes de qualquer API pública da primeira vez