Características da linguagem mql4, sutilezas e técnicas - página 11

Novo comentário
 
Ihor Herasko:

Em muitas empresas de software, um código como esse arrancaria todos os dedos. A primeira coisa que é sempre e em qualquer lugar necessário é evitar "leitura desnecessária". Por exemplo, se uma condição é usada ao entrar em uma função:

então é recomendável escrever:

Esta abordagem ajuda muito quando não há condições associadas.

Mais uma vez, será uma dor no pescoço. Afinal de contas, ninguém verificou o que a função OrderType() retornou. Ou talvez tenha retornado -1 ou 6? Este é um exemplo de colocação sobre as propriedades do compilador do qual você deve sempre se manter afastado. Você mesmo cita muitos exemplos de código de plataforma cruzada. Então, por que você está se afastando disso neste caso? Um novo compilador MQ sairá e este código não funcionará mais corretamente.

O que as empresas de software têm a ver com o que estamos discutindo! O código não vai parar de funcionar, não há necessidade de cospirologia aqui.

É a mesma situação com a continuação. Código como:

é mais difícil de ler do que:

E ainda assim, a eficiência da execução é a mesma em ambos os casos.

Neste caso, o código de uma linha é mais fácil de ler do que o código de seis linhas. Além disso, é mais lógico porque não é obrigado a estar dentro de um loop de forma alguma. Ou seja, você pode copiar e colar o primeiro caso sem se preocupar com o segundo.

 
fxsaber:

O exemplo de Lots[] acima é um tesouro de como o código pode ser ao mesmo tempo super-lacônico e totalmente compreensível.

É você quem acha que o código é compreensível. Mas alguém que só olha através da documentação e vê seu código vai se perguntar por que o tamanho da matriz é 8, enquanto a documentação contém apenas 6 tipos de pedidos.

E, pessoalmente, também acho mais fácil ler as condições se elas estiverem separadas separadamente, ou seja, assim:

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

Eu também estou mais confortável do que assim:

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

Mas eu acho que é uma questão de gosto e hábito. Ninguém precisa impor ou provar nada.

Por outro lado, concordo com você que:

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

E acho que é lógico, e não me lembro de nenhum outro momento.

 
Alexey Kozitsyn:

Para você, o código é compreensível. Mas alguém que acabou de dar uma olhada na documentação e viu seu código vai imediatamente se perguntar por que a matriz tem tamanho 8, enquanto os tipos de pedidos na documentação são apenas 6.

Então você vê como um simples código gera perguntas certas na mente das pessoas! E depois disso, você deve confiar em tudo o que está escrito na Documentação?

 
fxsaber:

E depois disso, você deve confiar em tudo o que está na Documentação?

você deve, é um princípio básico da programaçãoRTFM

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

deve, é um princípio básico da programaçãoRTFM

As realidades contradizem este princípio.

 
fxsaber:

O que as empresas de software têm a ver com o que estamos discutindo!

Bem, quem mais você pode citar como uma autoridade?

O código não vai parar de funcionar, não há necessidade de cospirologia aqui.

Sim, na MT4 com 99% de probabilidade, porque a MT4 está quase enterrada. Mas tente puxar tal manobra cruzada e você imediatamente se depara com um defeito que desaparece, levando a um erro fatal.

Neste caso, o código de uma linha é mais fácil de ler do que o código de seis linhas. Além disso, é mais lógico porque não está vinculado de forma alguma à necessidade de estar dentro de um loop. Isto é, o primeiro caso pode ser facilmente copiado, o segundo não.

Se estamos falando de um caso particular, pode ser verdade, porque o código dado é quase padrão para cada EA. Mas se você tomar algo mais complicado, é difícil lê-lo quando escrito em uma linha.

Por que ouvir maldições do espaço sideral de alguém que trabalha com seu código? ))

 
Ihor Herasko:

Bem, quem mais você pode citar como uma autoridade?

É estranho que a noção de autoridade seja tocada aqui.

Sim, na MT4 há 99% de probabilidade de que assim seja, pois a MT4 está quase enterrada. Mas tente puxar tal manobra cruzada e você imediatamente encontrará um defeito que desaparece, levando a um erro fatal.

A escrita em MT5 é idêntica.

Se estamos falando de um caso em particular, pode ser porque o código dado é quase padrão para cada EA. Mas se você tomar algo mais complicado, é difícil lê-lo quando está escrito em uma linha.

E também há construções if -> else if -> else. Não entendo porque uma expressão de bool em um operador condicional deve ser dada na forma mais primitiva.

 
Alexey Kozitsyn:

Para você, o código é compreensível. Mas alguém que acabou de dar uma olhada na documentação e viu seu código vai imediatamente se perguntar por que a matriz é de tamanho 8, enquanto os tipos de ordem na documentação são apenas 6.

E, pessoalmente, também acho mais fácil ler as condições se elas estiverem separadas separadamente, ou seja, assim:

Eu também estou mais confortável do que assim:

Mas eu acho que é uma questão de gosto e hábito. Ninguém precisa impor ou provar nada.

Por outro lado, concordo com você que:

E acho que é lógico, e não me lembro de nenhum outro momento.

Essas são as palavras-chave.

Pessoalmente, estou aborrecido com a ortografia de continuar de forma alguma.

Para que servem???? Se você ler 

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

tudo lê russo:

Se o pedido for selecionado e o símbolo do pedido for "nosso" e o mágico também for nosso... então fazemos tudo em aparelho de curativos.

Mas isso não soa muito russo:

Se o mandado não for selecionado, vá se foder...

Se o símbolo do mandado não for nosso, vá se foder...

e assim por diante.

Quantas vezes temos que nos mandar para lá...................

Aparentemente, isto fazia sentido em mql3. Foi uma forma de reduzir o tempo de verificação da condição. Então todas as condições são verificadas do início ao fim. Entretanto, a situação já foi resolvida há muito tempo; se o cheque encontrar uma condição não preenchida, outros cheques param. E todos estes truques não fazem absolutamente nenhum sentido.

 
Alexey Viktorov:

Estas são as palavras-chave.

Pessoalmente, estou aborrecido com a ortografia de continuar de forma alguma

Para que servem???? Se você ler

tudo isso se lê em russo:

Se o pedido for selecionado e o símbolo do pedido for "nosso" e o mágico também for nosso... então fazemos tudo em aparelho de curativos.

Mas isso não soa muito russo:

Se o mandado não for selecionado, vá se foder...

Se o símbolo do mandado não for nosso, vá se foder...

e assim por diante.

Quantas vezes temos que nos mandar para lá...................

Isso deve ter feito sentido em mql3. Era uma forma de reduzir o tempo de verificação de uma condição. Naquele momento todas as condições foram verificadas do início ao fim. Entretanto, a situação já foi resolvida há muito tempo; se a verificação tiver tropeçado em uma condição não cumprida, outras verificações cessarão. E todos estes truques não fazem absolutamente nenhum sentido.

Você mesmo concordou que se trata de uma questão de hábito. Por exemplo, eu me aborreço com os ninhos desnecessários, eu sempre os removo com retorno, continuo. E ao invés de "ir para o inferno" é fácil se acostumar a ler "as condições 1 e 2 estão preenchidas":

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

Por exemplo, eu me aborreço com os ninhos desnecessários, eu sempre os removo usando retorno, continuo

Estou irritado com"Negação Booleana NÃO(!)", não só leva um custo de CTs, mas a leitura de uma expressão lógica se transforma em leitura "para trás e para frente")))

Eu sempre devolvo "verdadeiro" em funções bool como a resposta mais esperada, como exemplo: eu verifico a disponibilidade do servidor desta forma:

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

Eu o chamo de bastante legível e lógico:

if(ServerDisable()) return;

se o servidor está ocupado - saída, normalmente uso em funções comerciais, não há necessidade de incomodar o servidor com pedidos porque ele está ocupado

como eles dizem - é uma questão de gosto, mas como você sabe: os gostos diferem ))))

1...456789101112131415161718...35
Novo comentário