Como melhoro minhas habilidades de leitura de código [fechado]

Bem, a pergunta está no título - como melhoro minhas habilidades de leitura de código.

O ambiente de software / hardware no qual desenvolvo atualmente é bastante lento em relação aos tempos de compilação e ao tempo que o sistema inteiro leva para testar. O sistema é bastante antigo / complexo e, portanto, dividi-lo em vários subprojetos menores e mais gerenciáveis, não é viável em um futuro próximo.

Percebi que o que realmente atrapalha o progresso do desenvolvimento são minhas habilidades de leitura de código. Como aperfeiçoo minhas habilidades de leitura de código, para que eu possa detectar a maioria dos erros e problemas no código mesmo antes de pressionar a tecla "fazer compilação", mesmo antes de iniciar o depurador?

Leia mais código

Eu, por exemplo, adquiri minhas habilidades decentes de leitura de código com a leitura de perguntas de certificação, que eram muito difíceis de seguir, porque eram mal escritas de propósito

Eles devem testar seu conhecimento da linguagem (Java no meu caso), afinal.

Quanto mais código você lê, mais experiência acumula, é simples

Melhore o seu ambiente de desenvolvimento, tanto quanto possível, para que ele possa fornecer feedback que você pode usar.

Os IDE modernos podem ajudar MUITO se você puder fornecer as informações necessárias. Exemplos são:

• Coloração de sintaxe: constantes em uma cor, comentários em outra, identificadores em uma terceira, seqüências de caracteres em uma quarta, etc. Encontrei recentemente um pedaço de código que era ... estranho ... Aconteceu que uma variável foi nomeada como constante seria - a cor errada denunciou.
• Capture erros simples de compilação. A maioria dos idiomas possui uma sintaxe simples, que pode ser ensinada a um editor, portanto, com antecedência, você terá erros.
• Capture erros complexos de compilação. Muitos compiladores podem gerar arquivos informativos que podem ser carregados no seu IDE para saber quantos argumentos uma determinada função leva, etc.

Também existem programas que podem identificar erros lógicos em seus programas, os quais você pode usar para obter ainda mais informações sobre o seu programa.

Além disso, seu IDE pode ajudá-lo a navegar na sua fonte quando souber todas essas coisas. Isso permite que você pesquise facilmente as coisas, em vez de memorizar tudo

Sugiro que você edite sua pergunta para fornecer mais informações sobre o ambiente com o qual trabalha e os programas que escreve, para obter melhores sugestões.

Além do que todo mundo disse, você precisa de paciência para ler o código (especialmente se não for o seu). Sim, a leitura por linha de código de cor requer prática, mas vale a pena, e você também aprende os estilos / truques de codificação de outras pessoas. Aqui está o que eu verifico em ordem:

1. nomes de variáveis, chaves correspondentes, importações etc.
2. verifique se as condições estão devidamente colocadas e se os erros foram detectados
3. tudo o resto - uso de funções, etc.

Estou acostumado a codificar em um editor de texto sem formatação para que Ctrl + F seja meu amigo, mas um IDE é muito útil, especialmente quando você está lendo vários arquivos.

Agora, se você for quem escreverá o código, não tenha medo de colocar espaços em branco, indentações e comentários. Honestamente, se não parece agradável aos olhos, torna-se uma dor na cabeça.

Mesmo que eu pudesse detectar todos os erros antes de clicar em compilar, eu ainda verificaria testando e compilando. Eu só confiaria em um teste positivo e em um programa em execução.

Eu acho que boas habilidades de leitura de código podem levar você muito longe na hipótese de criar código. "Provavelmente isso daria errado!", E teste isso. E ao encontrar bugs "essa pode ser a causa, vamos testá-lo"

A melhor maneira de chegar lá é escrevendo o código você mesmo. A segunda melhor maneira é que o código simplesmente seja realmente bom e se explique (se for realmente difícil, o código não será tão bom)

Se não é seu próprio código e não está escrito bem, a única maneira de melhorar é fazendo, fazendo, fazendo. Leia o código, tente coisas diferentes, escreva testes contra ele, conheça a base de código, refatorar. As ferramentas podem ajudar, ferramentas que podem descobrir onde os métodos são usados, onde as interfaces são implementadas, onde as variáveis ​​são declaradas etc. E ferramentas que fornecem uma visão geral dos namespaces, suas relações e métricas sobre eles.

Eu tive um problema semelhante no passado - meu truque era escrever um pequeno teste, deixar a mesa por um tempo, voltar e simular o teste no papel. Dessa forma, você pode revisar seu código com uma nova aparência e tem um valor específico para verificar (ao contrário de revisar seu código e dizer "ahh .. ahh ... faz sentido")

Possivelmente, seria bom se concentrar em aprender uma habilidade de leitura de código de cada vez, assim como nas revisões formais de código, cada revisor tem uma responsabilidade diferente. Pegue um corpo de código e passe uma semana (digamos) procurando apenas nomes de variáveis ​​incorretos. Bata o mesmo código novamente na próxima semana, procurando por potenciais ponteiros nulos; na próxima semana, procure blocos de código duplicados; problemas de multithreading etc.

Depois de passar um tempo dedicado aprimorando diferentes detectores, você pode descobrir que agora pode ler código com alguns deles - ou talvez todos - ativos, para ter um senso mais rico de código agora em uma única leitura.

Se você está falando sobre erros de compilação, isso não vai acontecer. A melhor solução para erros do compilador é atribuir a pessoa que interrompeu a compilação para cuidar das compilações até que outra pessoa a interrompa. Você quebrou, você conserta.

Os erros de lógica são muito mais difíceis de detectar, deixe impedir. Uma técnica para evitar casos simples é escrever testes de unidade / regressão.

Uma dica que ouvi esta manhã (na Rádio SE) foi pegar um arquivo e reduzi-lo para o tipo 3pt, depois procurar padrões no texto. Você não poderá ler o texto, mas todos os tipos de padrões aparecerão. É um truque legal.

E este é um daqueles lugares onde a linha de comando é seu amigo, grep e pipelines podem fazer muitas coisas úteis.

Eu costumava ser instrutor de programação há vários anos. Durante esse período, passei muito tempo lendo o código e comentando sobre ele. Isso envolve detectar erros de compilação (nem sempre compilamos o código dos alunos), erros de lógica e design e problemas de padronização.

Para fazer isso bem, tivemos que desenvolver um olho afiado para esse tipo de erro e ser capaz de "executar a seco" o código. Esse tipo de atividade também me expôs a muitos estilos de codificação. Hoje, minhas habilidades de leitura de código são bastante boas, graças a esse período.

Então, minha sugestão para você é esta:

• Faça uma revisão de código com seus colegas.
• Eu recomendo ler o código deles sozinho antes de analisá-lo com eles, para que você tenha que descobrir o que o código faz por si mesmo.
• Comente a estrutura e a limpeza do código, os padrões e a lógica.
• Isso melhorará sua qualidade de código e suas habilidades de leitura de código.
• Código revise seu próprio código algum tempo depois de terminar de codificá-lo, dessa forma você poderá avaliá-lo "com novos olhos" e aprender com seus erros.

Boa sorte!