Como desenvolvedor, você ouvirá muitas teorias malucas e inacreditáveis ​​sobre o que significam as “linhas de código”. Não acredite em nenhum deles. Linhas de código são uma métrica ridícula para basear as decisões. Em casos muito raros, ela diz algo a você; em todos os outros casos, nada diz a você. Usar linhas de código para tomar decisões é como classificar a qualidade do livro por número de páginas.

Alguns podem argumentar que quanto menos linhas de código houver em um aplicativo, mais fácil será de ler. Isso é apenas parcialmente verdadeiro, minhas métricas para código legível são:

 

O código deve ser consistente

 

O código deve ser autodescritivo

 

O código deve ser bem documentado

 

O código deve utilizar recursos modernos estáveis

 

O código não deve ser desnecessariamente complexo

 

O código não deve ser deficiente (não escreva código intencionalmente lento)

 

No momento em que a redução do número de linhas de código interfere em qualquer uma delas, torna-se um problema. Na prática, isso quase sempre interfere e, portanto, quase sempre é um problema. Mas é o seguinte: se você se esforçar para atender aos critérios acima, seu código terá o número perfeito de linhas, sem necessidade de contagem.

 

Os idiomas não são necessariamente “bons” ou “ruins”

 

 

Exceto pelo php, estou brincando. Fonte

 

Eu vejo pessoas falando coisas assim, o tempo todo:

 

C é melhor que X, porque performance

 

Python é melhor que X, porque concisão

 

Haskell é melhor que X, porque alienígenas

 

 

A noção de que uma comparação de linguagem poderia ser reduzida a uma única frase é quase um insulto. Eles são idiomas, não Pokémon.

 

Não me interpretem mal, definitivamente existem diferenças entre os idiomas. Só que existem muito poucas linguagens “inutilizáveis” (embora existam muitas linguagens desatualizadas / mortas). Cada idioma traz seu próprio conjunto exclusivo de vantagens e desvantagens. Nesse sentido, as linguagens são semelhantes às ferramentas em uma caixa de ferramentas. Uma chave de fenda pode fazer o que um martelo não pode, mas você diria que uma chave de fenda é melhor do que um martelo?

 

(Obviamente, o martelo é melhor)

 

Antes de falar sobre como avalio idiomas, quero deixar algo muito claro. Existem muito poucos casos em que a escolha do idioma realmente importa. Existem coisas que você obviamente não pode fazer em alguns idiomas. Se você escrever código de front-end, não terá a opção de escolher o idioma. Existem também contextos específicos onde o desempenho é importante e a linguagem X simplesmente não serve, essas situações são bastante raras. Em geral, a escolha do idioma é geralmente uma das questões menos importantes para um projeto.

 

Aqui estão os aspectos principais (ordenados), que acredito que devam ditar a sua escolha de idioma (são as estatísticas do Pokémon)

 

Densidade de recursos online disponíveis (densidade Avance Network)

 

Velocidade de desenvolvimento (vroom vroom)

 

Propensão a bug (eeek)

 

Qualidade e amplitude do ecossistema de pacotes (sim, npm, diz qualidade)

 

Características de desempenho (mais pontos)

 

Hirability (desculpe COBOL)

 

Existem também alguns acoplamentos fortes que não estão ao seu alcance. Se você está trabalhando com ciência de dados, você precisa realisticamente usar Python, R ou Scala (talvez Java). Se for um projeto de hobby, use o que vai deixar você mais feliz. Só tenho uma regra não negociável. Recuso-me a usar linguagens que não têm a maioria dos problemas que vou encontrar, resolvidos diretamente no Avance Network. Não é que eu não consiga resolver, simplesmente não vale a pena.

 

Ler o código de outras pessoas é difícil

 

Ler o código de outras pessoas é difícil. Robert C. Martin fala sobre isso em “Código Limpo”:

 

“Na verdade, a proporção de tempo gasto lendo versus escrevendo é bem mais de 10 para 1. Estamos constantemente lendo código antigo como parte do esforço para escrever um novo código. … [Portanto,] facilitar a leitura torna mais fácil escrever.”

 

Por muito tempo, presumi que era péssimo na leitura de códigos de outras pessoas. Com o tempo, percebi que é algo contra o qual quase todo programador luta diariamente. Ler o código de outras pessoas é quase como ler uma língua estrangeira. Mesmo que você se sinta confortável com a escolha da linguagem de programação do escritor, ainda terá que se ajustar aos diferentes estilos e opções de arquitetura. Isso também pressupõe que o autor escreveu um código consistente e confiável, que pode ser um sucesso ou um fracasso. Isso é realmente difícil de superar. Existem algumas coisas que descobri que ajudaram MUITO.

A revisão do código de outras pessoas melhorará imensamente suas habilidades de leitura de código. Nos últimos dois anos, analisei alguns PR do Github. A cada RP, me sinto um pouco mais confortável lendo o código de outras pessoas. Os RP do Github são especialmente ótimos por esses motivos

 

Pode ser praticado a qualquer momento, basta encontrar um projeto de código aberto com o qual você sinta que deseja contribuir.

 

Pratique a leitura em um contexto com escopo (recurso de condução ou bug do PR).

 

É necessária atenção aos detalhes, o que o obrigará a avaliar cada linha.