Você deve sacrificar a legibilidade do código com a eficiência do código? [fechadas]

Você deve sacrificar a legibilidade do código com a eficiência do código?

por exemplo, 3 linhas de código em 1 linha.

Li no Code Craft de Pete Goodliffe que a legibilidade é a chave.

Seus pensamentos?

"Menos linhas" nem sempre é a mesma coisa que "mais eficiente". Suponho que você queira dizer "Um programa deve ser reduzido em detrimento da legibilidade".

Os programas devem ser escritos para as pessoas lerem e, incidentalmente, para as máquinas executarem.

-Abelson & Sussman, Estrutura e Interpretação de Programas de Computador

Em geral, acho que é mais importante que um programa seja facilmente compreendido do que curto. Devo observar, porém, que tornar um programa mais curto também o torna mais legível (existe o limite óbvio que você atinge quando seu código começa a parecer ruído de linha, mas até esse momento, expressar algo de forma mais sucinta parece torná-lo mais claro).

Existem exceções específicas (como seus scripts de shell pessoais ou um dos códigos de transferência de dados) que ninguém precisará manter e somente você precisará ler. Nessa situação, provavelmente não há problema em sacrificar alguma legibilidade por conveniência, desde que você ainda possa entendê-la.

Às vezes sim.

A legibilidade é uma coisa boa a se esforçar. A maioria dos códigos escritos para aplicativos típicos de linha de negócios terá desempenho suficiente e o foco na legibilidade é importante. Em áreas mais exigentes em termos de desempenho (como programação de videogame ou computação pesada), pode ser importante renunciar à legibilidade em favor do uso de um recurso de linguagem específico que é terrivelmente ilegível e, ainda assim, incrivelmente eficiente.

Para um exemplo deste último, consulte o artigo Raiz quadrada inversa rápida na Wikipedia.

Geralmente penso que é melhor tornar algo legível primeiro e me preocupar com o desempenho depois, desde que sejam tomadas precauções de bom senso, como não escolher um algoritmo O (n ^ 2) sobre O (n). Sacrificar a legibilidade apenas por uma questão de brevidade é, em minha opinião, equivocado.

A única vez em que sacrificaria a legibilidade seria quando o código fosse mostrado como um gargalo de desempenho e uma reescrita resolveria isso. Nesse caso, a intenção do código deve ser bem documentada, para que, se houver um erro, ele possa ser rastreado com mais facilidade.

Isso não diz que a reescrita deve ser ilegível, é claro.

Eu citei isso antes , e vou citar novamente:

Corrija,
deixe claro,
conciso,
rápido.

Naquela ordem.

Wes Dyer

Você deve sacrificar a legibilidade do código com a eficiência do código?

Em termos de código, é sempre bom ser auto-documentado. Mas às vezes isso não pode acontecer. Às vezes, você precisa otimizar e, às vezes, esse código não é, por si só, muito legível.

É para isso que os comentários foram inventados . Usa-os. Até a montagem tem comentários. Se você escreveu uma grande quantidade de código e não há um comentário à vista, estou preocupado. Os comentários não afetam o desempenho do tempo de execução, mas algumas notas sobre o que está acontecendo sempre ajudam.

Penso que não há desculpa para não fazer alguns comentários básicos. Claramente if ( x == 0 ) /* check if x is 0 */é totalmente inútil; você não deve adicionar ruído desnecessário ao código, mas algo como isto:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

É bastante útil.

Você deve sacrificar a legibilidade do código com a eficiência do código?

Se a eficiência é seu objetivo atual (como na fase de otimização) e você sabe - você tem métricas, não é? - essa (s) linha (s) de código é o gargalo atual, então sim.

Caso contrário, não: legibilidade permitirá que você (ou outro) possa alterar esse código posteriormente para torná-lo mais eficiente, pois é mais fácil de entender.

Ninguém ganha o Code Golf

por exemplo, 3 linhas de código em 1 linha

Uma ideia particularmente terrível.

Custo para jogar código de golfe - muito alto.

Custo para manter programas ilegíveis - astronômicos.

Valor desse tipo de código minimizado - zero. Ainda funciona, mas não funciona "melhor".

Eficiência escolhida com sabedoria

Custo para escolher o algoritmo e a estrutura de dados corretos - moderado.

Custo para manter o algoritmo e a estrutura de dados corretos - baixo.

Valor do algoritmo e estrutura de dados corretos - alto. O uso de recursos é baixo.

Eficiência tola ("micro-otimização")

Custo para jogar em torno da micro-otimização - alto.

Custo para manter código ilegível e micro-otimizado - muito alto.

Valor de micro-otimização - varia. Quando há um valor diferente de zero aqui, os custos ainda o superam.

Depende se estamos falando de eficiência em termos de velocidade com que o código é executado ou eficiência em quão rápido o desenvolvedor pode escrever o código. Se você está sacrificando a legibilidade do código em favor de poder digitá-lo muito rapidamente, provavelmente estará pagando o tempo de volta no caminho em termos de depuração.

No entanto, se estamos falando sobre o sacrifício da legibilidade do código em termos de velocidade com que o código é executado, é provável que seja uma troca aceitável, desde que o código precise ser executado de maneira eficiente. Escrever algo que seja executado o mais rápido possível, apenas porque você não pode ser um motivo tão bom quanto porque é algo como a raiz quadrada inversa rápida em que o desempenho é essencial. O truque será entre equilibrar o código e garantir que, embora a fonte possa ser difícil de ler, os comentários descrevendo o que ela explica explicam o que está acontecendo.

Muitos truques, que deveriam tornar o código mais rápido, mas tendem a torná-lo menos legível, não são mais necessários, porque os compiladores ficaram muito inteligentes (ainda mais espertos que a maioria dos desenvolvedores) ou as máquinas ficaram ridículas rapidamente.

Não aceito o argumento "legibilidade sobre desempenho". Deixe-me dar uma resposta com uma rotação diferente.

Alguns antecedentes: você sabe o que me deixa doente? Quando clico duas vezes em Meu computador e tenho que realmente esperar que ele seja preenchido. Se isso demorar mais de 5 segundos, fico muito frustrado. O mais estúpido é que, e não culpe a Microsoft por isso, é que, em alguns casos, o motivo para demorar tanto é que é preciso tomar uma decisão sobre qual ícone mostrar! Está certo. Então, aqui estou eu, apenas interessado em ir para a minha unidade C: e preciso aguardar o driver acessar meu CD-ROM e ler o ícone de lá (supondo que exista um CD na unidade).

ESTÁ BEM. Então, por um segundo, imagine todas as camadas entre mim clicando duas vezes em Meu computador e, na verdade, falando através de drivers no CD-ROM. Agora imagine que cada camada era ... mais rápida ...

Veja bem, por trás de tudo isso existem milhares de programadores felizes, porque seu código é "mais legível". Isso é ótimo. Estou feliz por você. Mas, da perspectiva do usuário, é uma merda (termo técnico). E assim você dorme durante a noite dizendo a si mesmo que fez a coisa certa, certificando-se de que o código seja mais legível e mais lento. Mesmo um pouco mais lento do que pode ser. E assim, milhares de desenvolvedores fazem isso e acabamos esperando nossos PCs por sua causa. Na minha opinião você não é digno. Não estou dizendo que suas primeiras linhas precisam ser as melhores.

Aqui está a minha abordagem: primeiro, faça com que funcione e depois mais rápido. Sempre tente escrever um código eficiente e, se você precisar sacrificar a legibilidade, complemente-o com comentários. Não sacrificarei a eficiência para que algum programador medíocre possa mantê-la. Entretanto, explicarei meu código, mas se isso não for suficiente, desculpe, você é simplesmente incompetente para trabalhar aqui. Porque aqui, escrevemos um código que é rápido e legível e, embora exista um equilíbrio, o código legível pode ser explicado, enquanto a ineficiência é inaceitável.

Essa pergunta frequentemente vem à minha mente quando as entrevistas são discutidas no escritório. Muitos anos atrás, quando me formei, me fizeram a pergunta "Você acha que o código é auto-documentado?". Agora, eu deveria responder a essa pergunta como programador e, no que dizia respeito ao entrevistador, era uma questão em preto e branco, portanto não havia meio termo. O processo deve sobreviver ao indivíduo, pois as pessoas vão e vêm mais do que animadas, e você deseja obter novos começos prontos o mais rápido possível, e quanto mais fácil a leitura do código, mais rápido será o entendimento do que está acontecendo.

Há algum tempo, li um livro muito bom, chamado Desenvolvimento Orientado a Domínio: Design Orientado a Domínio: Enfrentando a Complexidade no Coração do Software É certo que é uma leitura um tanto seca no começo, mas o material é bem apresentado. Isso mostra uma boa abordagem que leva a sistemas que se documentam bem. O idioma é o meio de comunicação da sua solução; portanto, quanto mais clara a solução for expressa, mais fácil será a adaptação se a performance se tornar um fator cíclico. Essa é a minha crença e parece ter funcionado bem para mim.

Raramente valeria o retorno sobre o investimento em tornar o código mais rápido, em detrimento da legibilidade. Os computadores modernos funcionam tão rápido que duvido que haja um cenário em que você deseje isso. Se um computador estiver executando o código, esse código precisará ser mantido.

Para esse fim, acho a legibilidade muito importante. Obviamente, como declarado várias vezes, apenas porque o código é legível não significa necessário que seja mais lento.

Um bom exemplo é um nome de variável: $a

O que é $a?? Isso está fora de contexto, então você não pode responder isso, mas você já se deparou com isso no código real? Agora assuma que alguém escreveu $file_handle- agora o que é isso? É claro, mesmo fora de contexto. O comprimento do nome da variável faz uma diferença insignificante para o computador.

Eu acho que há bom senso aqui.

Alguns aplicativos podem justificar um atalho de mudança de bits que nem todos entenderão, mas acho que em algum momento há retornos reduzidos e encontrar um cenário é raro *.

* isso depende da indústria e de outras coisas. Estou analisando isso da perspectiva do desenvolvedor de software comercial (Business Information Systems).

Para analisar isso de outra perspectiva (mas não para divagar), trabalho em uma empresa que faz o SAAS. Quando um site é desativado, precisamos corrigi-lo muito, muito rápido - geralmente alguém está consertando o código de outro desenvolvedor.

Eu muito em vez de alguém fazer algo muito ineficiente, mas legível do que para torná-lo extravagante e "rápido". Nossos servidores da web são avançados e uma solicitação não precisa ser entregue em milionésimos de segundo. Não temos problemas de carregamento.

Então, na prática, acho que é mais provável que você se machuque ou a outros ... (prefiro ter meu fim de semana de volta.)

Para quase todos os casos, a resposta é "Confie no seu compilador para fazer seu trabalho" e escreva um código legível. Isso implica que o código é logicamente estruturado (ou seja, sem espaguete) e se auto-documenta (ou seja, nomes suficientemente claros de variáveis, funções, etc.). Código de suplemento que não é auto-documentado com comentários significativos. Não comente apenas para comentar, ou seja,

x++; // Add one to x

Em vez disso, comente para você, leitor, em 6 meses ou 12 meses ou em algum outro período suficientemente longo. Adote um padrão de codificação e siga-o.

Código limpo é um código rápido. Claramente escrito, o código de fácil manutenção tende a ser mais rápido, porque é um indicador de que o programador entendeu a tarefa em questão e refatorou o código até seu objetivo principal.

Além disso, os compiladores modernos otimizam as instruções com muita eficácia. Quantas linhas de código você digita para fazer alguma coisa e o que o compilador cria em termos de instruções não estão necessariamente relacionadas. Leia os compiladores para entender por que esse é o caso.

Quando estou trabalhando em algo baseado no desempenho, como gráficos, ocasionalmente sacrifico a legibilidade / capacidade de manutenção quando estou fazendo coisas como processamento de imagens quando estou trabalhando no mais profundo dos algoritmos aninhados, onde pequenas otimizações podem ter um efeito importante. E mesmo assim, só o faço após a criação de perfil para garantir que as mudanças realmente aceleram as coisas. Não posso dizer quantas vezes tentei 'otimizações' codificadas manualmente, apenas para descobrir que ele realmente diminuiu a velocidade do aplicativo devido à maneira como o compilador otimizou o código digitado manualmente.

A legibilidade é uma desculpa para programadores incompetentes e preguiçosos (na verdade o mesmo se aplica à "simplicidade" quando usada como argumento para defender um algoritmo / design de baixa qualidade)!

Para cada problema, você deve procurar a solução ideal! O fato de os computadores hoje serem rápidos não é desculpa para desperdiçar ciclos de CPU. A única restrição deve ser "hora de entregar". Observe que "solução ideal" aqui significa aquela que VOCÊ pode apresentar (nem todos podemos encontrar a melhor solução; ou ter a habilidade / conhecimento para implementá-las).

Como alguém mais mencionou, se há aspectos "difíceis de entender" de uma solução, é para isso que servem os comentários. A ordem "correta, legível, rápida" (ou algo parecido), mencionada por outra pessoa, é apenas perda de tempo.

Tenho muita dificuldade em acreditar que existem programadores por aí, que, quando apresentados a um problema, pensam nas linhas "... isso deve ser feito assim, mas farei dessa maneira menos eficiente, mas mais legível / manuteníveis e outras porcarias ... ". A falácia disso é que o próximo desenvolvedor (vendo as ineficiências) provavelmente modificará o código e o próximo fará o mesmo e assim por diante ... O resultado final é que, após algumas versões, o código se tornará o que o original desenvolvedor deveria ter escrito em primeiro lugar. A única desculpa para o desenvolvedor original é a. ele / ela não pensou nisso (bastante justo) e (como mencionado anteriormente) b. restrições de tempo e recursos.

se a diminuição da legibilidade ajuda no desempenho / otimização do código (como no swfobject e em outras bibliotecas js), é apenas uma razão para continuar escrevendo código bem formatado e claramente legível e convertê-lo em ilegível / otimizado como parte do processo de "compilação" / liberação.