Caratteristiche del linguaggio mql4, sottigliezze e tecniche - pagina 11

Nuovo commento
 
Ihor Herasko:

In molte aziende di software, un codice come questo farebbe staccare tutte le dita. La prima cosa che si richiede sempre e ovunque è di evitare le "letture inutili". Per esempio, se usate una condizione quando inserite una funzione:

allora si raccomanda di scrivere:

Questo approccio aiuta molto quando non ci sono condizioni.

Ancora una volta, sarà una spina nel fianco. Dopo tutto, nessuno ha controllato cosa restituisce la funzione OrderType(). O forse ha restituito -1 o 6? Questo è un esempio di come ci si possa appoggiare sulle proprietà del compilatore da cui si dovrebbe sempre stare alla larga. Tu stesso citi molti esempi di codice multipiattaforma. Allora perché se ne allontana in questo caso? Uscirà un nuovo compilatore MQ e questo codice non funzionerà più correttamente.

Cosa c'entrano le aziende di software con quello di cui stiamo discutendo! Il codice non smetterà di funzionare, non c'è bisogno di cospirologia qui.

È la stessa situazione con il continuo. Codice come:

è più difficile da leggere che:

Eppure l'efficienza dell'esecuzione è la stessa in entrambi i casi.

In questo caso, il codice di una linea è più facile da leggere che quello di sei linee. Inoltre, è più logico perché non è vincolato in alcun modo all'interno di un ciclo. Cioè potete fare un copia-e-incolla del primo caso senza preoccuparvi del secondo.

 
fxsaber:

L'esempio Lots[] qui sopra è un tesoro di come il codice può essere sia super-laconico che totalmente comprensibile.

Sei tu che trovi il codice comprensibile. Ma qualcuno che guarda solo la documentazione e vede il tuo codice si chiederà perché la dimensione dell'array è 8, mentre la documentazione contiene solo 6 tipi di ordine.

E personalmente, trovo anche più facile leggere le condizioni se sono separate separatamente, cioè così:

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

Sono anche più a mio agio che così:

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

Ma credo che sia una questione di gusto e di abitudine. Nessuno ha bisogno di imporre o dimostrare nulla.

D'altra parte, sono d'accordo con te:

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

E penso che sia logico, e non ricordo altre volte.

 
Alexey Kozitsyn:

Per voi il codice è comprensibile. Ma qualcuno che ha appena guardato la documentazione e visto il tuo codice si chiederà immediatamente perché l'array ha dimensione 8, mentre i tipi di ordine nella documentazione sono solo 6.

Così vedi come un semplice codice genera domande giuste nella mente della gente! E dopo questo, ci si deve fidare di tutto ciò che è scritto nella Documentazione?

 
fxsaber:

E dopo, ci si deve fidare di tutto quello che c'è nella Documentazione?

si dovrebbe, è un principio di base della programmazioneRTFM

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

dovrebbe, è un principio fondamentale della programmazioneRTFM

La realtà contraddice questo principio.

 
fxsaber:

Cosa c'entrano le aziende di software con quello di cui stiamo discutendo!

Bene, chi altro potete citare come autorità?

Il codice non smetterà di funzionare, non c'è bisogno di cospirologia qui.

Sì, in MT4 con il 99% di probabilità lo è, perché MT4 è quasi sepolto. Ma provate a fare una trovata del genere su più piattaforme e vi imbatterete immediatamente in un difetto che scompare e porta a un errore fatale.

In questo caso, il codice di una linea è più facile da leggere di quello di sei linee. Inoltre, è più logico perché non è legato alla necessità di essere all'interno di un ciclo in alcun modo. Cioè il primo caso può essere facilmente copiato, il secondo no.

Se stiamo parlando di un caso particolare, può essere vero, perché il codice dato è quasi standard per ogni EA. Ma se si prende qualcosa di più complicato, è difficile leggerlo se scritto in una riga.

Perché ascoltare le maledizioni dallo spazio da qualcuno che lavora con il tuo codice? ))

 
Ihor Herasko:

Bene, chi altro può citare come autorità?

È strano che la nozione di autorità sia toccata qui.

Sì, in MT4 c'è una probabilità del 99% che lo sia, perché MT4 è quasi sepolto. Ma provate a fare una trovata del genere su più piattaforme e vi imbatterete immediatamente in un difetto che scompare e porta a un errore fatale.

La scrittura in MT5 è identica.

Se stiamo parlando di un caso particolare, può essere così perché il codice dato è quasi standard per ogni EA. Ma se si prende qualcosa di più complicato, è difficile leggerlo quando è scritto in una riga.

E ci sono anche costruzioni if -> else if -> else. Non capisco perché un'espressione bool in un operatore condizionale debba essere data nella forma più primitiva.

 
Alexey Kozitsyn:

Per voi il codice è comprensibile. Ma qualcuno che ha appena guardato la documentazione e visto il tuo codice si chiederà immediatamente perché l'array è di dimensione 8, mentre i tipi di ordine nella documentazione sono solo 6.

E personalmente, trovo anche più facile leggere le condizioni se sono separate separatamente, cioè così:

Sono anche più a mio agio che così:

Ma credo che sia una questione di gusto e di abitudine. Nessuno ha bisogno di imporre o dimostrare nulla.

D'altra parte, sono d'accordo con te:

E penso che sia logico, e non ricordo altre volte.

Queste sono le parole chiave.

Personalmente, sono infastidito dall'ortografia di continue.

Qual è il senso di loro???? Se leggete 

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

tutto si legge in russo:

Se l'ordine è selezionato e il simbolo dell'ordine è "nostro" e il mago è anche nostro... allora facciamo tutto tra parentesi graffe.

Ma questo non suona molto russo:

Se il mandato non è selezionato, vaffanculo...

Se il simbolo del mandato non è nostro, vaffanculo...

e così via.

Quante volte dobbiamo mandarci lì...................

Apparentemente questo aveva senso in mql3. Era un modo per ridurre il tempo di controllo delle condizioni. Poi tutte le condizioni sono controllate dall'inizio alla fine. Tuttavia, la situazione è stata da tempo corretta e se il controllo incontra una condizione non soddisfatta, ulteriori controlli si fermano. E tutti questi trucchi non hanno assolutamente senso.

 
Alexey Viktorov:

Queste sono le parole chiave.

Personalmente, sono infastidito dall'ortografia di continuare a tutti

Qual è il senso di loro???? Se leggete

si legge tutto in russo:

Se l'ordine è selezionato e il simbolo dell'ordine è "nostro" e il mago è anche nostro... allora facciamo tutto tra parentesi graffe.

Ma questo non suona molto russo:

Se il mandato non è selezionato, vaffanculo...

Se il simbolo del mandato non è nostro, vaffanculo...

e così via.

Quante volte dobbiamo mandarci lì...................

Questo deve aver avuto senso in mql3. Era un modo per ridurre il tempo di controllo di una condizione. In quel momento tutte le condizioni sono state controllate dall'inizio alla fine. Tuttavia, la situazione è stata risolta da tempo; se il controllo è incappato in una condizione non soddisfatta, gli ulteriori controlli si fermano. E tutti questi trucchi non hanno assolutamente senso.

Lei stesso ha convenuto che è una questione di abitudine. Io, per esempio, sono infastidito dall'annidamento inutile, lo rimuovo sempre con return, continue. E invece di "vai all'inferno" è facile abituarsi a leggere "le condizioni 1 e 2 sono soddisfatte":

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

Per esempio, sono infastidito dalla nidificazione non necessaria, la rimuovo sempre usando return, continue

Sono irritato da"negazione booleana NOT(!)", non solo prende un costo di CTs, ma la lettura di un'espressione logica si trasforma in una lettura "al contrario e in avanti" )))

Restituisco sempre "true" nelle funzioni bool come la risposta più attesa, per esempio: controllo la disponibilità del server in questo modo:

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);}

Lo definisco abbastanza leggibile e logico:

if(ServerDisable()) return;

se il server è occupato - exit, di solito uso nelle funzioni commerciali, non c'è bisogno di disturbare il server con richieste perché è occupato

come si dice - è una questione di gusti, ma come si sa: i gusti differiscono ))))

1...456789101112131415161718...35
Nuovo commento