Aqui está um problema de programação / linguagem em que gostaria de ouvir seus pensamentos.
Desenvolvemos convenções que a maioria dos programadores deve seguir, que não fazem parte da sintaxe das linguagens, mas servem para tornar o código mais legível. É claro que sempre é uma questão de debate, mas há pelo menos alguns conceitos fundamentais que a maioria dos programadores consideram agradáveis. Nomear suas variáveis adequadamente, nomeando em geral, tornando suas linhas não excessivamente longas, evitando funções longas, encapsulamentos, essas coisas.
No entanto, há um problema que ainda não encontrei alguém comentando e que talvez seja o maior do grupo. É o problema dos argumentos serem anônimos quando você chama uma função.
Funções derivam da matemática, onde f (x) tem um significado claro, porque uma função tem uma definição muito mais rigorosa do que normalmente faz na programação. Funções puras em matemática podem fazer muito menos do que na programação e são uma ferramenta muito mais elegante, geralmente usam apenas um argumento (que geralmente é um número) e sempre retornam um valor (também geralmente um número). Se uma função recebe vários argumentos, quase sempre são apenas dimensões extras do domínio da função. Em outras palavras, um argumento não é mais importante que os outros. Eles são explicitamente ordenados, com certeza, mas fora isso, eles não têm ordenação semântica.
Na programação, no entanto, temos mais funções de definição de liberdade e, neste caso, eu argumentaria que não é uma coisa boa. Uma situação comum, você tem uma função definida como esta
func DrawRectangleClipped (rectToDraw, fillColor, clippingRect) {}
Observando a definição, se a função estiver escrita corretamente, é perfeitamente claro o que é o quê. Ao chamar a função, você pode até ter alguma mágica de conclusão de código / inteligência acontecendo no seu IDE / editor que lhe dirá qual deve ser o próximo argumento. Mas espere. Se eu precisar disso quando realmente estiver escrevendo, não há algo faltando aqui? A pessoa que lê o código não tem o benefício de um IDE e, a menos que salte para a definição, não tem idéia de qual dos dois retângulos passados como argumentos é usado para quê.
O problema vai além disso. Se nossos argumentos vierem de alguma variável local, pode haver situações em que nem sabemos qual é o segundo argumento, pois apenas vemos o nome da variável. Tomemos, por exemplo, esta linha de código
DrawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])
Isso é aliviado em várias extensões em idiomas diferentes, mas mesmo em idiomas estritamente digitados e mesmo se você nomear suas variáveis de maneira sensata, nem mesmo menciona o tipo de variável ao passar para a função.
Como geralmente acontece com a programação, existem muitas soluções em potencial para esse problema. Muitos já estão implementados em idiomas populares. Parâmetros nomeados em C #, por exemplo. No entanto, tudo o que sei tem desvantagens significativas. Nomear cada parâmetro em cada chamada de função não pode levar a um código legível. Quase parece que estamos superando as possibilidades que a programação em texto simples nos oferece. Passamos do APENAS texto em quase todas as áreas, mas ainda codificamos o mesmo. Mais informações são necessárias para serem exibidas no código? Adicione mais texto. De qualquer forma, isso está ficando um pouco tangencial, então vou parar por aqui.
Uma resposta que cheguei ao segundo trecho de código é que você provavelmente descompactaria o array para algumas variáveis nomeadas e as usaria, mas o nome da variável pode significar muitas coisas e a maneira como é chamada não indica necessariamente o caminho que deve ser interpretado no contexto da função chamada. No escopo local, você pode ter dois retângulos nomeados leftRectangle e rightRectangle porque é isso que eles representam semanticamente, mas não precisa se estender ao que eles representam quando atribuídos a uma função.
De fato, se suas variáveis são nomeadas no contexto da função chamada, você está introduzindo menos informações do que poderia potencialmente com essa chamada de função e, em algum nível, se isso levar a um código com código pior. Se você possui um procedimento que resulta em um retângulo armazenado em rectForClipping e outro procedimento que fornece retForDrawing, a chamada real para DrawRectangleClipped é apenas uma cerimônia. Uma linha que não significa nada de novo e existe apenas para que o computador saiba exatamente o que você deseja, mesmo que você já o tenha explicado com a sua nomeação. Isso não é uma coisa boa.
Eu realmente adoraria ouvir novas perspectivas sobre isso. Tenho certeza de que não sou o primeiro a considerar isso um problema, então como é resolvido?