Onde você vai ler bons exemplos de código-fonte? [fechadas]

Você pode procurar projetos de código aberto em sites de repositório como o GitHub , Codeplex , Google Code ou BitBucket . Você vai encontrar projetos de diferentes níveis de complexidade, então você deve ser capaz de encontrar algo que lhe interesse e não exagere muito no começo.

Outra opção é o Código Fonte Semanal de Scott Hanselman.

Eu recomendo começar com um projeto ativo e estabelecido para reduzir as chances de começar a ler o código que ainda não foi usado e examinado. O ideal é encontrar algo que lhe interesse e que você possa usar. Usando o aplicativo irá ajudá-lo a entender o código-fonte. Outro benefício de escolher um projeto de código aberto é que você pode contribuir com algumas correções ou recursos, o que ajudará a tornar a leitura do código mais interessante.

Encarar um monte de código de outra pessoa pode ser intimidante, então comece com a função main (ou equivalente) e trabalhe até o fim.

Poucas pessoas escrevem um bom código-fonte em sua primeira tentativa. Um bom código-fonte costuma ser produzido por uma série de revisões. Assim, se você encontrar o código-fonte que foi revisado várias vezes e corrigido várias vezes, provavelmente estará em um local melhor. Alguns projetos de código aberto (e algumas partes deles) são particularmente bem revisados. O código proveniente de empresas que têm ciclos de revisão obrigatórios (por exemplo, o Google, mas há muitos outros) pode ser adequado ao projeto.

Dito isto, não sei se o seu objetivo deve ser encontrar "código excelente". Deve ser olhar para diferentes estilos de código (como aqueles escritos por seus colegas de trabalho), e aprender a identificar os pontos positivos e negativos sobre isso. Quanto mais pontos negativos você identificar, mais se esforçará para tornar seu código melhor e saber como.

Depois de algumas vezes você fica desorientado com funções de 100 linhas com dez níveis de recuos e dependências em globais, e algumas vezes que você passa por um código bem decomposta, você melhora sua própria programação.

Em vez de encontrar códigos excelentes, consulte os Livros de programação geral.

por exemplo. Código Completo, Escrevendo código sólido, Padrões de Design (Tenho certeza que existem muitos outros livros em outras perguntas e respostas neste site)

Esses livros descrevem a filosofia que é considerada um bom código. Legibilidade, desempenho, manutenibilidade, detecção de bugs, etc.

Que serve recursos ainda melhores e mais eficientes do que tentar descobrir o que o autor está tentando alcançar.

p. Um bom design de software é o que você deve analisar também. O que seria difícil de reconhecer apenas a partir da observação de códigos, dado que o projeto é grande o suficiente.

Descobri que o código das bibliotecas que vêm com a sua linguagem de programação de escolha costuma ser um bom começo para ver o que é considerado uma prática recomendada e um bom estilo de codificação.

Embora você não queira começar com lugares como algoritmos de classificação ou classes de contêiner complexas.

Outro lugar para informações interessantes sobre como escrever código é o Projeto Euler ( link ). Uma pequena desvantagem: Você deve resolver o problema primeiro para ter acesso ao fórum onde os outros postaram suas soluções (desafios interessantes para todos os níveis de experiência). Mas uma vez feito, você encontrará exemplos para quase todas as principais linguagens de programação. E como você já resolveu o problema, ele ajudará você a entender o código de outras pessoas. Além disso, você pode ver o código de idiomas que ainda não conhece, mas pode achar interessante.

Gostei muito de ler o Beautiful Code . Tem exemplos de código curtos, mas muito bons, com explicações detalhadas.

...leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes.

...The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules.

This book contains 33 chapters contributed by Brian Kernighan, KarlFogel, Jon Bentley, Tim Bray, Elliotte Rusty Harold, Michael Feathers,Alberto Savoia, Charles Petzold, Douglas Crockford, Henry S. Warren,Jr., Ashish Gulhati, Lincoln Stein, Jim Kent, Jack Dongarra and PiotrLuszczek, Adam Kolawa, Greg Kroah-Hartman, Diomidis Spinellis, AndrewKuchling, Travis E. Oliphant, Ronald Mak, Rogerio Atem de Carvalho andRafael Monnerat, Bryan Cantrill, Jeff Dean and Sanjay Ghemawat, SimonPeyton Jones, Kent Dybvig, William Otte and Douglas C. Schmidt, AndrewPatzer, Andreas Zeller, Yukihiro Matsumoto, Arun Mehta, TV Raman,Laura Wingerd and Christopher Seiwald, and Brian Hayes...