Recentemente, tenho alternado entre vários projetos e ambientes de desenvolvimento. As expectativas para o estilo de codificação em cada um são diferentes.
Agora, minha pergunta é em três partes, a primeira, apenas por curiosidade:
Respostas:
№1. # Como você definiu e encontrou seu estilo de codificação?
Através de amostras de código primeiro nos livros, depois nos textos e artigos do MSDN, depois nos blogs e em outros sites.
№2. Como você continua aumentando e melhorando?
Fico de olho em todas as sugestões que as pessoas fazem. Eu os experimento, se eles trabalham para mim, eles permanecem. Eu também experimento de tempos em tempos, o que parece melhorar as coisas fica comigo.
№3. Como você o mantém? (A partir de notas mentais, mantendo um documento, usando uma ferramenta como StyleCop etc.)
Lembro-me do meu estilo e o aplico automaticamente em todos os lugares.
Nota 1. Manter os olhos abertos e os ouvidos afiados é extremamente importante para se manter atualizado. Anos atrás, aprendi com outras pessoas que a notação da Hungria era obrigatória, então eu a segui. Quando a comunidade percebeu que não era tão bom, mudei com todo mundo.
Nota 2. Geralmente, não é tão importante quais elementos de estilo específicos você adota, mas sim que você mantenha seu estilo consistente em todos os seus códigos. O mesmo se aplica a uma equipe. Escolha um estilo, mas depois cumpra-o.
Nota 3. Os estilos de codificação para diferentes idiomas podem variar. C ++ merece um estilo, Java o outro. HTML e CSS têm suas características que exigem um estilo diferente novamente.
Nota 4. Seja qual for o estilo escolhido, entenda e aceite que não funcionará 100%. Às vezes, você possui algum código que requer um estilo diferente, como multilinha dividida, alinhamento diferente ou o que for, para manter mais legível essa parte do código em particular. Não force seu estilo em qualquer lugar, concentre-se na legibilidade do código. Se for óbvio, o estilo não funciona nesse local específico, faça uma exceção.
Nota 5. Não faça seguir um estilo de código para uma religião. As ferramentas que impõem um estilo de código são boas, mas às vezes podem deixá-lo louco. Por exemplo, desativei a formatação automática de código do Visual Studio porque estava me deixando louco. Se uma ferramenta se tornar um obstáculo, basta adicionar uma exceção e não se preocupe, pois seu código não é 100% compatível. Não é tão importante assim e perfeição não alcançável é de qualquer maneira.
Eu não acho que houve um tempo em que eu disse: "Ok, esse vai ser o meu estilo". Concentre-se em um ambiente ou idioma específico. Seu estilo deve refletir a maneira como você enfrenta um determinado problema.
Eu trabalhei em uma equipe com um jogo de código fechado que eu amava e o desenvolvedor líder me orientou e me ajudou a melhorar minhas habilidades depois que perguntei a ele também.
Ele sugeriu e eu adotei o Estilo de codificação do Zend Framework (http://framework.zend.com/manual/en/coding-standard.html)
Acabei adotando características de estilos diferentes - incluindo estilos refletidos no MSDN. Em seguida, configurei modelos no VS que fornecem meus #region/#endregionblocos e qualquer outra coisa que seja preferível.
Continuo estudando outros estilos que encontro através da pesquisa e da leitura. Se acho que há algo que se destaca e poderia melhorar meu estilo de legibilidade, manutenção ou organização, eu o testo. Se um novo ajuste de estilo estiver em ordem, atualizarei os modelos no VS ou farei anotações mentais.
Ao codificar sozinho, busco concisão; A programação espartana pode ser completa, insanidade idiota ... Mas é provavelmente a coisa familiar mais próxima do meu credo.
Ao codificar com outras pessoas, especialmente com a manutenção, pretendo ser um camaleão - minhas alterações devem melhorar o que modificam, sem parecer fora do lugar.
Como você definiu e encontrou seu estilo de codificação?
Concentrando-se na simplicidade e legibilidade (legibilidade! == compreensibilidade, consulte Programação espartana )
Como você continua aumentando e melhorando?
Revendo o código dos outros e o meu próprio (e até os próprios padrões de codificação).
Como você o mantém? (A partir de notas mentais, mantendo um documento, usando uma ferramenta como StyleCop etc.)
Eu uso dokuwiki , uma brisa para configurar (sem banco de dados), estrutura hierárquica, controle granular (ACL pronto para uso), aparência muito bonita e, bem, é um wiki, para que qualquer pessoa possa contribuir. Além disso, as contribuições / alterações estão sempre sob consenso e justificadas, com base na simplicidade e legibilidade.
Essa é uma resposta estranha, mas levei muito tempo para entender a programação. Passei muito tempo trabalhando nas 'artes' antes de me considerar um programador.
Ao codificar, costumo pensar em unidades como a escrita - parágrafos, frases, etc. Por causa disso, espalharei o código por mais linhas na busca de torná-lo legível como uma história / ensaio / etc. Fico muito irritado quando os desenvolvedores tentam colocar o máximo possível em uma linha ou em um espaço pequeno, porque isso não realiza nada além de fazer o escritor parecer inteligente e irritar qualquer futuro leitor.
Se eu precisar fazer algo estranho por uma questão de eficiência, comentarei para explicar por que é assim.
Provavelmente não receberei nenhum voto positivo por isso, mas talvez isso acenda alguma discussão de qualquer maneira.
Quanto ao lado técnico, como a colocação de suportes e outros, eu os mantenho alinhados porque o resultado é uma legibilidade aumentada.
1. How did you define and find your coding style?
Eu adotei um guia de estilo já desenvolvido, amplamente desenvolvido e amplamente aceito ou popularizado por uma grande empresa / projeto.
Faço isso por várias razões, mas principalmente porque esses guias de estilo podem ser imediatamente adotados pelos desenvolvedores. Um guia de estilo vale tanto quanto os desenvolvedores estão dispostos a cumpri-lo.
Exemplos disso são o PEP 8 do Python , o guia de estilo do Android para Java , o guia de estilo do jQuery Core ou o guia de estilo do Python do Google .
2. How do you keep augmenting and improving it?
O maior argumento para esses guias de estilo é que eles não foram inventados aqui e não inventados por mim. Foram necessários vários desenvolvedores, linhas de código intimidadoras e mais tempo do que sua empresa / equipe jamais estaria disposta a investir no desenvolvimento e manutenção de um guia de estilo.
Quanto às melhorias, nunca houve um guia de estilo que responda imediatamente tudo o que você precisa saber. Mas, na maioria dos casos, as melhorias que eu vi sendo empurradas para frente eram apenas uma versão mais detalhada do que o guia de estilo já preparou com sua abordagem para escrever código.
Nesses casos, quando você se deparar com um bloco de estranheza, cole-o em uma essência ou em outra ferramenta apropriada de compartilhamento de trechos de código com suporte à sintaxe de cores e discuta-o em algum lugar com outros desenvolvedores. O mais importante é que, nesses casos, você não está interessado no que o código faz, mas apenas como o código aparece, para que você possa tirar esse bloco do contexto e discutir como deve aprimorá-lo, comparando-o com o que já está especificado em o guia de estilo como o principal ponto de partida para as discussões.
3. How do you maintain it?
Bem, o melhor é que você já terá documentos existentes que são mantidos publicamente online.
Quando se trata de formatação de código, você também pode ir além e fornecer à sua equipe as configurações do formatador para o editor favorito, o que deve levar em consideração as suposições e críticas sobre como manter as aparências de ponta. Na verdade, eu não chamaria isso de sair uma milha extra, mas parte integrante do desenvolvimento - não há nada pior do que fazer uma diferença em que 90% das alterações de código eram alguém fazer o check-in de código devidamente formatado / com estilo porque alguém se esqueceu de limpar antes que eles comprometessem um enorme novo recurso.
Se você faz parte de uma equipe, deve sempre aderir ao padrão da equipe. Há muito a ser dito para usar um layout genérico e não o seu próprio. Isso torna seu código mais fácil de ler e entender por outras pessoas, o que é essencial.