O objetivo por trás do código é 'idiomático' para reduzir a sobrecarga cognitiva?

Estou tentando explicar a alguém que a maneira como eles escreveram o código dificulta a compreensão e, se você o refatorar, fica mais fácil ler. Esse estilo de código em que estou dirigindo é comumente chamado de código 'idiomático'.

Mas a frase código idiomático traz consigo uma bagagem de correção moral , o que não é um grande motivador para levar as pessoas a mudarem seu estilo de codificação. Uma maneira mais positiva de dizer isso é o código que segue o estilo comum - mas para um pensador crítico que aparece como raciocínio de mentalidade de rebanho.

O jeito que eu explico essa ideia de uma maneira que motiva as pessoas a mudar seu código é:

• escrever o código de maneira a reduzir a sobrecarga cognitiva do leitor (por exemplo, não me lembro se esse é o primeiro tipo de vetor - ou o quinto tipo de vetor)
• código que facilita a compreensão da intenção (por exemplo, para que serve esse vetor?)

(Como um aparte, eu sei que o livro The Joy of Clojure, antes de sua primeira publicação, tinha o rascunho de título Idiomatic Clojure. Portanto, parece uma razão para tornar o código 'idiomático', para 'trazer alegria' ao leitor )

Minha pergunta é: o objetivo por trás do código é 'idiomático' para reduzir a sobrecarga cognitiva?

Primeiro, não tenho certeza de que exista algum tipo de "correção moral" no termo "idiomático". A definição simples do dicionário é simplesmente

peculiar ou característica de um idioma ou dialeto específico: francês idiomático.

Sim, o código idiomático geralmente reduz a sobrecarga cognitiva, principalmente nas definições de interface em que as bibliotecas padrão e quaisquer bibliotecas de terceiros necessárias para o projeto são (praticamente) todas idiomáticas.

Como ponto de venda, no entanto, eu me concentraria no que reduzir a sobrecarga cognitiva faz por você. Isso torna mais fácil para os programadores identificarem erros, porque eles não estão tentando desvendar o código escrito em um estilo único para descobrir onde ele está sutilmente desviado por um ou manipular mal um caso externo. Isso facilita a revisão do código de outras pessoas, o que torna mais provável que a equipe faça análises reais que identifiquem problemas reais em vez de discutir sobre sintaxe.

Além de reduzir a sobrecarga cognitiva, o código idiomático é geralmente um código mais eficiente. A maioria dos idiomas em um idioma específico evolui porque o idioma é projetado para abordar problemas de uma maneira específica. Os compiladores ou intérpretes que você estiver usando concentrarão suas otimizações no código idiomático. Se você usar uma linguagem em que recursão é a maneira idiomática de estruturar um trecho de código, por exemplo, você pode ter certeza de que seu compilador implementa recursão final. Se você usar um idioma em que a recursão não é idiomática, é muito menos provável. É improvável que a recursão da cauda não possa ser implementada em qualquer lugar, mas a maioria dos criadores de compiladores não se concentrará em coisas que não acontecem comumente.

Não sei de onde você tira a idéia de que expressões idiomáticas têm alguma conotação moral. Os idiomas são apenas uma maneira de expressar as coisas. São padrões em uma escala maior que palavras ou frases individuais.

Se eu lhe dissesse que é preciso uivar com os lobos, você não saberia o que eu quis dizer, mesmo que esse seja um idioma alemão bem conhecido. Se, ó OTOH, eu lhe disse, quando em Roma, faça como os romanos, você saberá imediatamente do que estou falando, porque usei o idioma inglês apropriado.

Linguagens de computador não são diferentes.

Na verdade, um nome alternativo para "idioma" no mundo da programação é "padrão de implementação". Isso relaciona a idéia à idéia de padrões, que vem do arquiteto (Christopher e argamassa, não bits e bytes). A maioria dos programadores conhece padrões de design, alguns conhecem padrões de arquitetura, que são padrões em uma escala maior que os padrões de design. Expressões idiomáticas são padrões em uma escala menor que os padrões de design.

A maioria das línguas intencionalmente se presta a um estilo particular. Código escrito nesse estilo é o que é idiomático. Se você ignorar o fato circunstancial de que sua escolha do ambiente de tempo de execução restringe sua escolha de idiomas disponíveis, escolha idiomas, pois o problema em questão é fácil de expressar nas expressões específicas de um idioma.

A maioria das pessoas não entende isso. Por exemplo, muitos programadores de Java se esforçam muito para manter o mesmo estilo quando precisam escrever JavaScript (eles poderiam ter escrito Java e compilado de maneira cruzada, lembre-se) e conseguem, até certo ponto - escrever código idiomático de Java em JavaScript - mas eles sempre terão a sensação de combater o JavaScript. Faltam determinados recursos ou acham difícil imitá-los.

O código linguístico é bom. É difícil para quem está de fora, mas eles podem aprender. Por fim, o código deve ser mantido por anos; portanto, se você puder encontrar um idioma dentro dos idiomas nos quais o programa subjacente possa ser expresso de maneira simples, é isso que você deve fazer.

Deixe-me esclarecer que existe definitivamente o uso excessivo de idiomas (ou os recursos de linguagem subjacentes). Se você usar modelos C ++ para executar partes significativas da lógica do aplicativo em tempo de compilação, ou se o seu programa Lisp completo for uma chamada para alguma macro que se desdobra na coisa real de maneiras praticamente imprevisíveis, se a sua solução Java de um problema simples aumentar para as proporções de FizzBuzzEnterpriseEdition ... você está fazendo errado.

As pessoas dizem que o código deve ser fácil de ler. Isso é apenas metade da verdade. Deve ser fácil de entender, o que exige que seja fácil raciocinar também. Isso requer um uso adequado de abstrações. Como na maioria das coisas, é uma questão de encontrar o equilíbrio certo.