Você acha que uma empresa de software deve impor aos desenvolvedores um estilo de codificação? [fechadas]

https://stackoverflow.com/questions/145508

02-07-2019
|

Pergunta

Se você acha que não deve, explicar o porquê.

Se sim, o quão profundo deve as diretrizes a sua opinião? Por exemplo, o recuo de código deve ser incluído?

Solução

Eu acho que um equipe (em vez de um empresa ) necessidade de chegar a acordo sobre um conjunto de diretrizes para o estilo razoavelmente consistente. Isso torna mais fácil para manutenção.

Qual a profundidade? Tão superficial como você pode concordar. O mais curto e mais claro é o mais provável é que todos os membros da equipe podem concordar com ele e vai cumpri-la.

Outras dicas

Você quer ler todos e escrever código de uma forma padrão. Há duas maneiras que você pode conseguir isso:

Clone um único desenvolvedor várias vezes e certifique-se que todos passam pelo mesmo treinamento. Esperemos que todos eles devem ser capazes de escrever a mesma base de código.
Dê aos seus desenvolvedores existentes instrução explícita sobre o que você necessita. Tabs ou espaços para recuo. Onde chaves sentar. Como a comentar. Version-control cometer diretrizes.

Quanto mais você deixar indefinido, maior a probabilidade de um dos desenvolvedores irá colidir no estilo.

A empresa deve impor que algum estilo deve ser seguido. O estilo que é e como profundamente as orientações são deve ser decidido coletivamente pela comunidade de desenvolvedores na empresa.

Eu definitivamente adoptar directrizes sobre chaves, recuo, nomeando etc ... Você escrever código para facilitar a leitura e manutenção. Sempre assumir alguém vai ler o seu código. Existem ferramentas que irão auto magicamente formatar seu código, e você pode mandato que todo mundo usa a ferramenta.

Se você está no olhar .Net no StyleCop, FxCop e ReSharper

Você acha que uma empresa de software deve impor aos desenvolvedores um estilo de codificação?

Não de uma forma top-down. Desenvolvedores de uma empresa de software devem concordar com um estilo de codificação comum.

Se sim, o quão profundo deve as diretrizes a sua opinião?

Eles só devem descrever as diferenças de convenções bem conhecidas, tentando manter o desvio mínimo. Isso é fácil para linguagens como Python ou Java, um pouco desfocadas para C / C ++, e quase impossível para Perl e Ruby.

Por exemplo, recuo de código deve ser incluído?

Sim, ele torna o código muito mais legível. Mantenha recuo consistente em termos de espaços vs guias e número (se você optar por espaços) de caracteres de espaço. Além disso, concordar com uma margem (por exemplo, 76 caracteres ou 120 caracteres) para as linhas longas.

Sim, mas dentro da razão.

Todos os IDEs modernos oferecem código de um keystroke pretty-print, então o ponto "recuo" é bastante irrelevante, na minha opinião.

O que é mais importante é estabelecer as melhores práticas: por exemplo, o uso tão pouco "fora" ou parâmetros "REF" quanto possível ... Neste exemplo, você tem 2 vantagens: melhora a legibilidade e também corrige uma série de erros (um monte de parâmetros de saída é um cheiro de código e provavelmente deve ser reformulado).

Indo além do que é, na minha opinião honesta, um pouco "anal" e desnecessariamente irritante para os devs.

Bom ponto por Hamish Smith:

O estilo é bastante diferente da melhor práticas. É uma pena que 'codificação normas tendem a rolar os dois juntos. Se as pessoas pudessem manter o parte estilo ao mínimo e concentrado sobre as melhores práticas que provavelmente adicionar mais valor.

Eu não acredito que a equipe de desenvolvimento deve ter diretrizes de estilo que devem seguir como regra geral. Há exceções, por exemplo o uso de <> vs. "" em # incluir instruções , mas essas exceções devem vir de necessidade.

A razão mais comum que ouço as pessoas usam para explicar por diretrizes de estilo são necessárias é que o código escrito em um estilo comum é mais fácil de manter esse código escrito em estilos individuais. Discordo. Um programador profissional não vai ser atolados quando vêem esta:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

... quando eles estão acostumados a ver isso:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

Além disso, eu descobri que é realmente mais fácil de manter o código em alguns casos, se você pode identificar o programador que escreveu o código original, simplesmente reconhecendo o seu estilo. Vai perguntar-lhes porque eles implementaram o aparelho de tal forma complicado em 10 minutos em vez de passar a maior parte de um dia para descobrir a razão muito técnica porque eles fizeram algo inesperado. É verdade, o programador deve ter comentado o código para explicar seu raciocínio, mas em que os programadores do mundo real, muitas vezes, não.

Finalmente, se for preciso Joe 10 minutos backspacing e movendo suas chaves para que Bill pode passar 3 menos segundos olhando para o código, ela realmente salvar qualquer momento para fazer Bill fazer algo que não vem natural para ele?

Acredito que ter uma base de código consistente é importante. Ele aumenta a manutenção do código ur. Se todo mundo espera que o mesmo tipo de código, eles podem facilmente ler e entender.

Além disso ele não é muito de IDEs um aborrecimento dado de hoje e as suas capacidades Autoformatting.

P.S: Eu tenho esse hábito irritante de colocar o meu aparelho na linha seguinte :). Ninguém mais parece gostar

Eu acho que os programadores devem ser capazes de se adaptar ao estilo de outros programadores. Se um novo programador é incapaz de se adaptar, isso normalmente significa que o novo programador é teimoso demais para usar o estilo da empresa. Seria bom se pudéssemos todos fazer nossas próprias coisas; No entanto, se todos os códigos ao longo de algumas orientação bast, que torna a depuração e manutenção mais fácil. Isso só é verdade se o padrão é bem pensado e não demasiado restritiva.

Enquanto eu não concordo com tudo, este livro contém um excelente ponto de partida para os padrões

A melhor solução seria para IDEs de considerar tais formatação como metadados. Por exemplo, a posição de abertura encaracolado cinta (linha atual ou próxima linha), recuo e espaço branco em torno de operadores deve ser configurável, sem alterar o arquivo de origem.

Na minha opinião eu acho que é altamente necessário, com padrões e guias de estilo. Porque quando a sua base de código cresce, você vai querer tê-lo consistente.

Como uma nota lateral, que é por isso que eu amo Python; porque já impõe um monte de regras sobre como estruturar suas aplicações e tal. Compare isso com Perl, Ruby ou qualquer outra coisa onde você tem uma liberdade extrema (o que não é bom neste caso).

Há uma abundância de boas razões para os padrões para definir a forma como as aplicações são desenvolvidas ea forma como o código deve ser semelhante. Por exemplo, quando todos usam o mesmo padrão de um estilo de verificador automático poderia ser usado como uma parte do CI projeto. Usando os mesmos padrões de melhorar a legibilidade do código e ajuda a reduzir a tensão entre os membros da equipe sobre re-factoring o mesmo código de maneiras diferentes. Portanto:

Todo o código desenvolvido pela equipe particular deve seguir exatamente o mesmo padrão.
Todo o código desenvolvido para um determinado projeto deve seguir exatamente o mesmo padrão.
É desejável que as equipes pertencentes à mesma empresa usar o mesmo padrão.

Em uma empresa de terceirização uma exceção poderia ser feito para uma equipe que trabalha para um cliente, se o cliente quer para impor um padrão próprio. Neste caso, a equipe adota padrão do cliente que poderia ser incompatível com o utilizado por sua empresa.

Como outros já mencionados, eu acho que deve ser por engenharia ou pela equipe -. A empresa (ou seja, unidades de negócios) não devem estar envolvidos nesse tipo de decisão

Mas uma outra coisa que eu gostaria de acrescentar é quaisquer regras que são implementadas devem ser aplicadas por ferramentas e não por pessoas. cenário de pior caso, IMO, é um pouco esnobe gramática excesso de zelo (sim, nós existimos; eu sei porque podemos sentir a nossa própria) escreve alguma documentação que define um conjunto de diretrizes de codificação que absolutamente ninguém realmente lê ou segue. Eles tornam-se obsoletos com o tempo, e à medida que novas pessoas são adicionados à equipe e idosos sair, eles simplesmente tornar-se obsoleto.

Então, algum conflito surge, e alguém é colocado na desconfortável posição de ter de alguém confronto mais sobre estilo de codificação - esse tipo de confronto deve ser feito por ferramentas e não por pessoas. Em suma, este método de aplicação é o menos desejável, na minha opinião, porque é muito fácil ignorar e simplesmente implora programadores para discutir sobre coisas estúpidas.

A melhor opção (novamente, IMO) é ter advertências lançadas em tempo de compilação (ou algo similar), desde que o seu ambiente de compilação suporta isso. Não é difícil configurá-lo no VS.NET, mas tenho conhecimento de outros ambientes de desenvolvimento que têm características semelhantes.

Diretrizes de estilo são extremamente importantes, sejam elas para o projeto ou desenvolvimento, porque eles acelerar a comunicação e o desempenho das pessoas que trabalham de forma colaborativa (ou mesmo sozinho, sequencialmente, como quando pegar os pedaços de um projeto antigo). não ter um sistema de convenção dentro de uma empresa está apenas pedindo às pessoas para ser tão improdutivo quanto puderem. A maioria dos projetos requerem a colaboração, e mesmo aqueles que não podem ser vulneráveis ??ao nosso desejo natural de exercer nossos costeletas de programação e se manter atualizado. Nosso desejo de aprender fica no caminho da nossa consistência -. Que é uma boa coisa em si, mas pode dirigir um novo funcionário louco tentando aprender os sistemas que está pulando em on

Como qualquer outro sistema que é destinado para o bem e não o mal, o poder real das mentiras de guia nas mãos de seu povo. Os próprios desenvolvedores irão determinar o que as partes essenciais e úteis são e, em seguida, esperamos, usá-los.

Como a lei. Ou no idioma Inglês.

Estilo guias devem ser tão profundo como eles querem ser - se ele vem para cima na sessão de brainstorm, ele deve ser incluído. É estranho como você formulada a questão, porque no final do dia não há nenhuma maneira de "impor" um guia de estilo porque é apenas um guia.

RTFM, em seguida, recolher o material bom e seguir em frente.

Sim, eu acho que as empresas deveriam. Desenvolvedor pode precisar para se acostumar com o estilo de codificação, mas na minha opinião, um bom programador deve ser capaz de trabalhar com qualquer estilo de codificação. Como Midhat disse:. É importante ter uma base de código consistente

Eu acho que isso também é importante para projetos de código aberto, não há nenhum supervisor para dizer-lhe como escrever seu código, mas muitas línguas têm especificações sobre como nomeação e organização do seu código deve ser. Isso ajuda muito ao integrar componentes de código aberto em seu projeto.

Claro, as orientações são boas, e a menos que seja mal utilizado notação húngara (ha!), Provavelmente vai melhorar a consistência e fazer a leitura do código de outras pessoas mais fácil. As diretrizes devem ser apenas diretrizes, porém, não regras estritas impostas para programadores. Você poderia me dizer onde colocar o meu aparelho ou não use nomes como temp, mas o que você não pode fazer é obrigar-me a ter espaços em torno dos valores de índice entre parênteses Array (eles tentaram uma vez ...)

Sim.

padrões de codificação são uma forma comum de assegurar que o código dentro de uma determinada organização seguirá o princípio da menor surpresa:. Consistência nas normas a partir de nomenclatura de variáveis ??de recuo para uso chaveta

Os codificadores ter seus próprios estilos e suas próprias normas só irá produzir um código-base que é inconsistente, confuso e frustrante para ler, especialmente em projetos maiores.

Estes são os padrões de codificação para uma empresa que eu usei para se trabalhar. Eles estão bem definidas, e, ao mesmo tempo que me levou um tempo para se acostumar a eles, significava que o código foi lido por todos nós, e uniforme durante todo o tempo.

Eu acho padrões de codificação são importantes dentro de uma empresa, se nenhum está definido, não vão ser confrontos entre desenvolvedores e problemas com legibilidade.

Tendo o uniforme código durante todo o tempo apresenta um código melhor para o usuário final (assim parece que ele é escrito por uma pessoa - que, a partir de um End Users ponto de vista, deve - essa pessoa ser "a empresa "e também ajuda com a leitura dentro da equipe ...

A codificação comum estilo promove a consistência e torna mais fácil para as pessoas diferentes para entender facilmente, manter e expandir toda a base de código, não só as suas próprias peças. Também torna mais fácil para novas pessoas para aprender o código mais rápido. Assim, qualquer equipe deve ter algumas orientações sobre como o código está prevista para ser escrita.

diretrizes importantes incluem (em nenhuma ordem particular):

espaço em branco e recuo
comentários padrão - arquivo, classe ou método cabeçalhos
Naming Convention - classes, interfaces, variáveis, namespaces, arquivos
anotações de código
projeto de organização - estruturas de pastas, binários
bibliotecas padrão - o que moldes, os genéricos, recipientes e assim por diante para uso
tratamento de erros - exceções, HRESULTs, códigos de erro
threading e sincronização

Além disso, ter o cuidado de programadores que não podem ou não vai se adaptar ao estilo da equipe, não importa o quão brilhante que poderia ser. Se eles não jogam por uma das regras da equipe, eles provavelmente não vai jogar por outras regras da equipe também.

Eu concordo que a consistência é a chave. Você não pode confiar em IDE impressão bonita para salvar o dia, porque alguns de seus desenvolvedores podem não gostar usando um IDE, e porque quando você está arrasto através de uma base de código de milhares de arquivos de origem, é simplesmente inviável muito imprimir todos os arquivos quando você começar a trabalhar neles, e realizar um roll-back depois que o seu VCS não tenta cometer volta todas as alterações (entupimento do repositório com atualizações desnecessárias que sobrecarregam todos).

Eu gostaria de sugerir a padronização pelo menos os seguintes (em ordem decrescente de importância):

Espaços em branco (é mais fácil se você escolher um estilo que está em conformidade com a automática impressão bonita de alguma ferramenta compartilhada)
Naming (arquivos e pastas, classes, funções, variáveis, ...)
Comentando (usando um formato que permite a geração de documentação automática)

A minha opinião:

Algumas regras básicas são boas, pois ajuda a todos para ler e manter o código
Muitas regras são ruins como ele pára desenvolvedores a inovar com as formas mais claras de colocar para fora o código
O estilo individual pode ser útil para determinar a história de um arquivo de código. ferramentas de diff / culpa pode ser usado, mas a dica é ainda útil

IDEs modernos permitem definir um modelo de formatação. Se houver um padrão corporativo, então, desenvolver um arquivo de configuração que define todos os valores de formatação que se preocupam e se certificar de todo mundo corre o formatador antes de verificar em seu código. Se você quer ser ainda mais rigoroso sobre isso você pode adicionar um gancho de confirmação para o seu sistema de controle de versão para recuar o código antes de ser aceite.

Sim, em termos de utilização de um padrão comum de nomenclatura, bem como um layout comum de aulas e código por trás de arquivos. Tudo o resto é aberta.

Toda empresa deveria. estilo de codificação consistente garante maior legibilidade e manutenção da base de código em toda a sua equipe.

A loja que eu trabalho em não ter um padrão de codificação unificada, e eu posso dizer que nós (como uma equipe) muito sofrer com isso. Quando não há vontade dos indivíduos (como no caso de alguns dos meus colegas), o líder da equipe tem que bater com o punho na mesa e impor alguma forma de diretrizes de codificação padronizados.

Idioma Sempre tem padrões gerais que são usados ??pela comunidade. Você deve seguir as também possível, para que o código pode ser mantida por outras pessoas usadas para a linguagem, mas não há nenhuma necessidade de ser ditatorial sobre isso.

A criação de um padrão oficial está errado porque uma empresa de codificação padrão é geralmente muito rígida, e incapaz de fluir com a comunidade em geral utilizando a linguagem.

Se você está tendo um problema com um membro da equipe ser realmente lá fora no estilo de codificação, que é uma coisa excelente para o grupo gentilmente sugerir não é uma boa idéia em uma revisão de código.

Normas de codificação: SIM. Por motivos já abordados neste segmento.

padrões Estilo: não. Seu legível, é o meu lixo desconcertante, e vice-versa. Boa comentando e factoring código tem um benefício muito maior. Também gnu travessão.

Eu gosto de resposta de Ilya porque incorpora a importância da leitura e da utilização de integração contínua como o mecanismo de execução. Hibri mencionado FxCop, e acho que seu uso no processo de construção como um dos critérios para determinar se uma compilação passa ou falha seria mais flexível e eficaz do que simplesmente documentar um padrão.

Concordo inteiramente que padrões de codificação devem ser aplicadas, e que ela deve ser quase sempre no nível da equipe. No entanto, existem algumas exceções.

Se a equipe está escrevendo código que é para ser usado por outras equipes (e aqui quero dizer que outras equipes terão que olhar para a fonte, não apenas usá-lo como uma biblioteca), então há benefícios para fazer normas comuns em toda todas as equipes usando. Da mesma forma, se a política da empresa é de mudar frequentemente programadores de uma equipe para outra, ou está em uma posição onde uma equipe quer frequentemente para reutilização de código de outra equipe, então provavelmente é melhor para impor padrões em toda a empresa.

Existem dois tipos de convenções.

convenções de tipo A: "por favor, faça isso, é melhor"

e Tipo B:. "Favor dirigir no lado direito da estrada", enquanto ele está bem para dirigir do outro lado, desde que todo mundo faz da mesma maneira

Não há tal coisa como uma equipe separada. Todo o código em uma boa empresa está ligado de alguma forma, e estilo deve ser consistente. É mais fácil obter-se usado para um novo estilo de vinte estilos diferentes .

Além disso, um novo desenvolvedor deve ser capaz de respeitar as práticas de base de código existente e segui-los.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow