Interessante assumir a OLP - página 9

Novo comentário
 
Igor Makanu:

Tenho 99% de certeza de que esses códigos serão executados com a mesma velocidade até um tato no nível do processador - o processador tem otimização, paralelismo e qualquer outra coisa que esteja rodando no nível do microcomando

Você não tem um efeito negativo aqui quando você escreve código de qualquer qualidade confiando em "o compilador irá escová-lo até o ideal"?


Se você escrever um estilo de código, você sabe exatamente que o compilador fará a coisa certa. Com outro estilo, é preciso confiar que o compilador é mais inteligente.

Dada a plataforma cruzada, diferentes compiladores, etc., eu escolho estar ciente do que estou fazendo no código.
 
fxsaber:

Não tem um efeito negativo quando qualquer código de qualidade é escrito com a expectativa de "o compilador o escovará ao máximo"?

Meus exemplos quase não são de qualidade, são construções típicas - há muito tempo comparo as fontes no githab, tanto os exemplos tst1 como tst2, ambos são ativamente utilizados pelos programadores

É por isso que eu acho que os desenvolvedores de compiladores aprenderam o código padrão construído há muito tempo e isso não é um problema para os compiladores.


efeito negativo - aqui, como@TheXpert escreveu acima, há requisitos da empresa para a formatação do código, mas os requisitos são geralmente os mesmos - o código deve ser compreensível para outros membros da equipe, incluindo mesmo aqueles que acabaram de chegar....


fxsaber:

Com um estilo de escrita que você conhece com certeza, o compilador fará a coisa certa. Com outro estilo você só tem que confiar que o compilador é mais inteligente.

Não é o compilador que é mais inteligente agora, mas o próprio processador, imho, se estamos falando de código de alto desempenho - a principal sobrecarga de desempenho não está nas chamadas de função, mas nas leituras de memória (acessos à memória) - se você puder substituir o armazenamento de dados/variáveis por pequenos valores de computação, você terá (no nível de otimização de microcomandos do processador) um pequeno ganho

... mas todo o resto, imho, é maligno ))))


SZY: há também otimização de um código em um nível do compilador, eu não li o suficiente - tudo em um nível de suposição, em hardware de PC que eu leio periodicamente, há muito tempo eu leio, eu tenho escrito a opinião




fxsaber:

Dada a plataforma cruzada, diferentes compiladores, etc., eu escolho estar ciente do que estou fazendo no código.

Não tenho escolha então - em resumo: "Sou um artista - é assim que vejo as coisas" )), espero não ter ofendido.

 

Eu tenho uma regra, após 5 anos o código deve ser compreensível para o codificador, se não compreensível, código ruim.

E se compreendido por outros, muito bom.

 
Valeriy Yastremskiy:

Eu tenho uma regra, após 5 anos o código deve ser compreensível para o codificador, se não compreensível, código ruim.

E se compreendido por outros, muito bom.

Aqui ( e aqui) é um código muito bom. Mas eu não entendo isso. Meu cérebro parou de crescer há muito tempo.

 
fxsaber:

Aqui ( e aqui) é um código muito bom. Mas eu não entendo isso. Meu cérebro parou de crescer há muito tempo.

Os tópicos são complicados. Nem todos os entendem,) para não mencionar o código.

 

Oh, que tópico... E sem mim... Não é bom... É preciso falar mais alto.

Quanto ao artigo no título - a premissa correta (o código deve ser o mais determinístico possível) é usada de forma muito tola, comparando a operação de adição e a operação de acumulação como exemplos. E a conclusão é que a operação de adição é determinista, sempre retorna o mesmo resultado, enquanto a acumulação não é, porque o resultado é sempre diferente.

Mas, desculpem-me... São operações diferentes, e em ambos os casos os resultados são perfeitamente corretos, e exatamente o que se espera da adição e da acumulação, respectivamente!

Mesmo o exemplo do gerador de números aleatórios - também não pode ser chamado de "não-determinístico" se se considerar que se trata de uma operação com um componente aleatório.

Como me parece, toda a coisa não determinista é que o autor não espera do código de forma alguma o que o código se destina.


E a segunda coisa é a legibilidade do código - eu acho a operação "ponto de interrogação" muito prejudicial e difícil de entender. A substituição da "pergunta" por um operador condicional produz um código executável com absolutamente a mesma eficiência. Neste caso, o código fonte torna-se visivelmente mais volumoso, mas também muito mais claro. O que eu acho que é uma grande vantagem.

Eu sempre tento dividir todas essas numerosas expressões lógicas em uma série de operações separadas com resultados intermediários. Mesmo que tal código resulte em códigos executáveis menos eficientes, o benefício de uma melhor compreensão é, em minha opinião, muito mais importante.

 

e este é o reino da programação orientada para as árvores de Natal :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }
 
Maxim Kuznetsov:

e este é o reino da programação orientada para as árvores de Natal :-)

Se as condições forem expressões curtas, tudo bem. Embora, você possa separá-los em funções.

E em parênteses ao contrário nesses casos, sempre coloco um comentário no cabeçalho do parênteses de abertura para deixar claro.

 
fxsaber:

Com um estilo de escrita, você sabe com certeza que o compilador vai fazer a coisa certa. Com outro, tudo o que você precisa fazer é confiar que o compilador é mais inteligente.

Não haverá diferença na execução deste

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  

e isto:

return( a() || b() );

Sou a favor de códigos fáceis de ler e de depurar.

 
Andrey Khatimlianskii:

Não haverá nenhuma diferença em fazer isto:

e isto:

Sou a favor de códigos fáceis de ler e de depurar.

Não gosto nada deste projeto em termos de legibilidade e desordem

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  
12345678910111213
Novo comentário