Como você pode explicar "código bonito" para um não programador? [fechadas]

Ao falar com uma amiga não programadora, mencionei o conceito de "código bonito" e ela queria entender o que isso significava, mas fiquei um pouco sem saber como explicar isso a alguém que não teria nenhum qualquer contexto.

Quando todo o código parece sem sentido para alguém, como explicar o que torna um pedaço de código mais bonito que o outro? Analogias também podem ser úteis.

Analogia de linguagem

Pense na sua história mais favorita. Provavelmente está maravilhosamente escrito. Para quem não fala inglês, só porque eles não conseguem entender ou entender por que é bonito não diminui sua beleza.

Analogia da construção

Considere uma casa de má qualidade. Tem portas e janelas que são obviamente empedradas. A argamassa está rachada em um canto onde a fundação era insuficiente. E ninguém consegue entender por que existe uma escada que leva ao segundo andar que não existe. O banheiro é construído ao lado da cozinha, sem exaustor, e está situado de modo que os ventos predominantes soprem os odores desagradáveis ​​do pântano pelo resto da casa. A chaminé da lareira fica a 5 cm de um pouco de madeira, pronta para pegar fogo.

Compare com uma casa em que tudo está onde deveria estar, baixa manutenção e perfeitamente isolado para que um pouco de calor solar o mantenha quente no inverno, a energia é recuperada da ventilação, para que você tenha ar fresco e temperatura confortável e contas de energia desprezíveis. É fabricado com materiais não inflamáveis, para que não possa queimar pelo fogo. Ele suportará um terremoto de 9,0 e um tornado F5. Custa apenas 30% a mais para construir do que a outra casa, mas pagará a diferença em 5 anos. E é esteticamente agradável.

A GUI é como a aparência externa de uma casa. Um usuário pode reconhecer a beleza em uma GUI, assim como pode apreciar uma casa bonita. Mas talvez ainda mais importante, a verdadeira beleza do design, tanto em casas quanto em programas, são coisas invisíveis para os não iniciados, mas importantes ou agradáveis ​​de se ter, independentemente.

Pense em um carro.

A maioria de nós olha para o carro e só consegue ver o corpo. Se alguém reparar alguns dings e colocar uma nova pintura no carro, ficará muito mais bonito. É basicamente o mesmo carro, mas é tudo o que vemos.

Um mecânico abre o carro e olha para o motor. Eles veem o quão bom é esse motor. Eles vêem que tudo está organizado para facilitar o acesso, a manutenção e o trabalho. Eles vêem as peças e sabem como foi bem projetado. Para um mecânico experiente, o motor de um carro de alta qualidade e bem conservado se torna algo de beleza. Eles não podem explicar o que a torna bonita, mas a noção de beleza provavelmente se traduzirá em custos de manutenção mais baixos, uma vida útil mais longa do carro e melhor desempenho. Tudo isso aumenta o valor desse carro, mesmo que você não possa vê-lo.

Quando você olha para um site ou aplicativo, olha como a maioria de nós vê carros. Quando olho para o código, vejo como o mecânico olha para o motor do carro. Você nunca pode experimentar a beleza desse código como eu, ele é literalmente invisível para você. Mas essa beleza é importante, assim como a beleza do mecânico. Ele determina o quão bem o software é executado, que tipo de problemas ele terá, com que facilidade o software pode ser aprimorado e assim por diante. Tudo isso aumenta o valor desse software, mesmo que você não possa vê-lo.

Todo o código presente é necessário e nada disso requer explicação.

Eu me referiria à poesia:

Um poema bem escrito tem uma sensação diferente do que um extrato de um manual mal traduzido sobre o mesmo assunto.

Os problemas de codificação são sobre conceitualização, portanto, um código bonito representa uma conceitualização notável do problema.

Por exemplo, gostamos quando um problema pode ser reduzido a um problema resolvido existente, fornecendo informações sobre a natureza do problema em si .

Às vezes, uma re-conceituação do problema pode torná-lo tão fácil; falamos de soluções elegantes que exigem truques simples que simplificam uma tarefa difícil.

Para mim, o Quicksort é um belo exemplo: escolha um elemento aleatório de uma matriz e compare todos os outros elementos da matriz com ele; se o número for menor que ele, coloque-o na pilha A; se o número for maior que ele, coloque-o na pilha B. Agora, pela desigualdade do triângulo, nenhum elemento da pilha A precisará ser comparado a qualquer elemento da pilha B. Recorra a A e B, e pronto .

Me lembra isso:

Fonte: XKCD - LISP

Nenhum código não trivial pode ser perfeito porque o código perfeito requer objetivos simultaneamente satisfatórios e que freqüentemente entram em conflito. Um código bonito, portanto, equilibra todos os atributos importantes perfeitamente para a tarefa em questão e chega mais perto de satisfazer todos esses simultaneamente, do que muitos pensariam ser possível. Em nenhuma ordem particular:

• Legibilidade
• Concisão
• Eficiência
• Flexibilidade
• Explicitação
• Robustez
• Segurança / resistência a idiotas
• Completude
• Consistência
• Facilidade de uso (para APIs)

As pinturas de Jackson Pollock são um exemplo de algo bonito para alguns e sem sentido para outros.

Se a pessoa é versada em matemática, gosto de comparar um código bonito a uma solução elegante para um problema.

Alguns aspectos do bom código são:

1. Possui um grande número de pequenos detalhes que apontam para a mesma direção
2. é consistente na estrutura , cada parte seguindo o mesmo padrão
3. mas não se repete , cada parte é diferente
4. ele também não permite comportamento que é considerada inválida
5. tem o menor número possível de estados diferentes
6. você pode entender todo o comportamento do código lendo protótipos de funções
7. não tem efeitos colaterais
8. a execução é garantida para parar
9. ele não usa nenhum recurso avançado disponível nas linguagens de programação
10. não é muito complexo comparado com a complexidade do problema que resolve
11. não há erros ou comportamento indefinido
12. ele pode ser compilado com compiladores de vários fornecedores diferentes
13. não possui dependências para codificar que não é usado

Para mim, o (s) idioma (s) são minhas ferramentas.

E, como qualquer artesão, prefiro que minhas ferramentas estejam em perfeitas condições.

Quanto melhor a condição do código, no que diz respeito à clareza de conceito, manutenção e legibilidade. melhor o código.

Então, para mim, ler códigos bem escritos é como abrir uma caixa de ferramentas com ferramentas bem criadas.

Eu usei essa analogia algumas vezes com sucesso. Especialmente as pessoas com uma formação mais prática ou artística parecem entender o conceito de código limpo / bonito dessa maneira.

Eu acho que depende do que você quer dizer com código bonito.

Para mim, o código é bonito quando legível. Além de possíveis problemas com os conceitos de programação, um leigo pode ler e, pelo menos em um nível alto, entender o que o código está fazendo.

Como algumas outras respostas discutiram, o código também pode ser bonito no sentido de atingir uma funcionalidade complexa combinando alguns conceitos simples. Não tenho certeza de que tipo de analogia seria melhor explicar que para um não programador, isso depende do leigo. Brinquedos de quebra-cabeça vêm à mente, como o NeoCube .

Na minha opinião humilde e pessoal, código bonito é como um bom livro de romance:

• você pode lê-lo do início ao fim / não precisa pular para as páginas futuras de um livro para entender a página atual.
• não possui repetições desnecessárias / um livro é meio chato se está sempre dizendo as mesmas coisas.
• a intenção de cada parte é evidente quase sempre; você não precisa sempre ter um dicionário ao seu lado para ler um livro (a menos que seja poesia / código de golfe xD).
• está organizado em subestruturas de tamanhos e complexidade acessíveis (módulos, funções, instruções, etc.), não possui muitos 'aninhamentos' / capítulos, parágrafos e frases são adequadamente balanceados; ele não usa muitos níveis de subordinação de sentenças etc.
• é agradável aos olhos de uma maneira estética (bem recortada, blocos delimitados corretamente etc.) / como um livro com uma tipografia adequada.

É como uma empresa enxuta, na qual todo mundo conhece seu papel, é fácil descobrir quem é bom no quê e não há duplicação de esforços

Vs.

Escritório onde a mediocridade é defendida, três gerentes não têm nada melhor a fazer do que incomodá-lo nos relatórios do TPS, a MÁQUINA DE FAX! @ # $ Ing NUNCA FUNCIONA !!! e qualquer funcionário em questão pode realizar apenas 15 minutos de trabalho real por semana. Um funcionário pode nem mesmo trabalhar tecnicamente lá porque alguém se esqueceu de demiti-lo (é difícil dizer realmente porque ninguém trabalha de forma eficiente e é difícil avaliar o que está tentando realizar). E para realizar qualquer coisa prática é necessário navegar por um sistema absurdamente complicado demais, sobre o qual alguém leu e pensou que ficaria bem em seu currículo, mesmo que isso não resolva realmente um problema que eles tinham.

Não existe "código bonito", existem "algoritmos elegantes" e "designs elegantes". O design pode ser entendido por não programadores.

Eu odeio programadores que discutem sobre "código bonito", porque, de um jeito ou de outro, eles realmente não sabem como um intérprete ou compilador o digerirá e o que a máquina fará, por isso é mais como crianças mostrando à mãe como maravilhosa a história dele é, mas realmente não é.

Você explica às pessoas por que uma boa foto é boa? Não. Você mostra a imagem (porque, você sabe, uma imagem diz mais do que 1000 palavras). Então, o melhor é mostrar a eles um pequeno pedaço de código que é realmente elegante, bonito, perfeito (e talvez como comparação, como Joe Average o teria codificado).