Trovo molto più logico mettere le parentesi su una riga o in una colonna. È molto difficile capire il codice in cui non è chiaro dove inizia o finisce un blocco. Bene, se lo scopo di tale formattazione è quello di nascondere il senso del codice ai nemici, allora l'obiettivo è raggiunto.
È chiaro. Qual è lo scopo dell'ottimizzazione del codice comunque? Nel ridurre il numero di linee? Vedo l'unico senso nell'aumentare la velocità del codice, e questo può essere ottenuto riducendo il numero di chiamate di funzioni cicliche, per esempio. O escludendo le ripetizioni di calcolo dell'indicatore. All'incirca così.
Vedo solo l'utilità di aumentare la velocità del codice
In generale, la velocità non è cruciale nel 90% dei casi. Il punto è fare inizialmente il codice in modo che sia il più facile possibile da costruire e leggere.
Poi, se il tempo è fondamentale, ottimizziamo la velocità.
int AnaliseFunc (string sy, int tf)
{
CurAsk =MarketInfo(Symbol(),MODE_ASK);
CurBid =MarketInfo(Symbol(),MODE_BID);
OpnPrice =iOpen(NULL,PERIOD_M5,0);
OpnPrice1=iOpen(NULL,PERIOD_M5,1);
ClsPrice1=iClose(NULL,PERIOD_M5,1);
if (sy=="" || sy=="0") sy=Symbol();
double
BB_1 =iCustom(sy,tf,"BB_MA",13,1,1,1),
BB_2 =iCustom(sy,tf,"BB_MA",13,1,1,2),
BB_3 =iCustom(sy,tf,"BB_MA",13,1,1,3),
AO1 =iAO(sy,tf,1),
AO2 =iAO(sy,tf,2),
AO3 =iAO(sy,tf,3),
AC1 =NormalizeDouble(iAC(sy,tf,1),8)*1000,
AC2 =NormalizeDouble(iAC(sy,tf,2),8)*1000,
AC3 =NormalizeDouble(iAC(sy,tf,3),8)*1000,
AC4 =NormalizeDouble(iAC(sy,tf,4),8)*1000,
AC5 =NormalizeDouble(iAC(sy,tf,5),8)*1000,
SpMan1=iCustom(sy,tf,"SpearmanRankCorr",14,1000,30,true,0,1),
SpMan2=iCustom(sy,tf,"SpearmanRankCorr",14,1000,30,true,0,2),
DeM_1 =iDeMarker(sy,tf,14,1),
DeM_2 =iDeMarker(sy,tf,14,2),
Mom_1 =iMomentum(sy,tf,14,PRICE_CLOSE,1),
Mom_2 =iMomentum(sy,tf,14,PRICE_CLOSE,2),
Mom_3 =iMomentum(sy,tf,14,PRICE_CLOSE,3);
//---------------- Проверка на разворот BB_MA ------------------------------------------------------- if (BB_1>BB_2 && BB_2<=BB_3 && BB_1<0) // Найден разворот BB вверх
{
switch (tf)
{
case1: TrBBTurnUP_M1 =true; TrBBTurnDN_M1=false; // Флаг разворота вверх на М1case5: TrBBTurnUP_M5 =true; TrBBTurnDN_M5=false; // Флаг разворота вверх на М5case15: TrBBTurnUP_M15=true; TrBBTurnDN_M15=false; // Флаг разворота вверх на М15 case30: TrBBTurnUP_M30=true; TrBBTurnDN_M30=false; // Флаг разворота вверх на М30 case60: TrBBTurnUP_H1 =true; TrBBTurnDN_H1=false; // Флаг разворота вверх на H1case240: TrBBTurnUP_H4 =true; TrBBTurnDN_H4=false; // Флаг разворота вверх на H4case1440: TrBBTurnUP_D1 =true; TrBBTurnDN_D1=false; // Флаг разворота вверх на D1case10080: TrBBTurnUP_W1 =true; TrBBTurnDN_W1=false; // Флаг разворота вверх на W1case43200: TrBBTurnUP_MN =true; TrBBTurnDN_MN=false; // Флаг разворота вверх на MN
}
}
if (BB_1<BB_2 && BB_2>=BB_3 && BB_1>0) // Найден разворот BB вниз
{
switch (tf)
{
case1: TrBBTurnUP_M1 =false; TrBBTurnDN_M1=true; // Флаг разворота вниз на М1case5: TrBBTurnUP_M5 =false; TrBBTurnDN_M5=true; // Флаг разворота вниз на М5case15: TrBBTurnUP_M15=false; TrBBTurnDN_M15=true; // Флаг разворота вниз на М15 case30: TrBBTurnUP_M30=false; TrBBTurnDN_M30=true; // Флаг разворота вниз на М30 case60: TrBBTurnUP_H1 =false; TrBBTurnDN_H1=true; // Флаг разворота вниз на H1case240: TrBBTurnUP_H4 =false; TrBBTurnDN_H4=true; // Флаг разворота вниз на H4case1440: TrBBTurnUP_D1 =false; TrBBTurnDN_D1=true; // Флаг разворота вниз на D1case10080: TrBBTurnUP_W1 =false; TrBBTurnDN_W1=true; // Флаг разворота вниз на W1case43200: TrBBTurnUP_MN =false; TrBBTurnDN_MN=true; // Флаг разворота вниз на MN
}
}
//---------------------- Проверка на разворот Momentum -----------------------------------------------if (Mom_1>Mom_2 && Mom_2<=Mom_3 && Mom_1<100.0)
{
switch (tf)
{
case1: TrMomTurnUP_M1 =true; TrMomTurnDN_M1=false; // Флаг разворота вверх на М1case5: TrMomTurnUP_M5 =true; TrMomTurnDN_M5=false; // Флаг разворота вверх на М5case15: TrMomTurnUP_M15=true; TrMomTurnDN_M15=false; // Флаг разворота вверх на М15 case30: TrMomTurnUP_M30=true; TrMomTurnDN_M30=false; // Флаг разворота вверх на М30 case60: TrMomTurnUP_H1 =true; TrMomTurnDN_H1=false; // Флаг разворота вверх на H1case240: TrMomTurnUP_H4 =true; TrMomTurnDN_H4=false; // Флаг разворота вверх на H4case1440: TrMomTurnUP_D1 =true; TrMomTurnDN_D1=false; // Флаг разворота вверх на D1case10080: TrMomTurnUP_W1 =true; TrMomTurnDN_W1=false; // Флаг разворота вверх на W1case43200: TrMomTurnUP_MN =true; TrMomTurnDN_MN=false; // Флаг разворота вверх на MN
}
}
if (Mom_1<Mom_2 && Mom_2>=Mom_3 && Mom_1>100.0)
{
switch (tf)
{
case1: TrMomTurnUP_M1 =false; TrMomTurnDN_M1=true; // Флаг разворота вверх на М1case5: TrMomTurnUP_M5 =false; TrMomTurnDN_M5=true; // Флаг разворота вверх на М5case15: TrMomTurnUP_M15=false; TrMomTurnDN_M15=true; // Флаг разворота вверх на М15 case30: TrMomTurnUP_M30=false; TrMomTurnDN_M30=true; // Флаг разворота вверх на М30 case60: TrMomTurnUP_H1 =false; TrMomTurnDN_H1=true; // Флаг разворота вверх на H1case240: TrMomTurnUP_H4 =false; TrMomTurnDN_H4=true; // Флаг разворота вверх на H4case1440: TrMomTurnUP_D1 =false; TrMomTurnDN_D1=true; // Флаг разворота вверх на D1case10080: TrMomTurnUP_W1 =false; TrMomTurnDN_W1=true; // Флаг разворота вверх на W1case43200: TrMomTurnUP_MN =false; TrMomTurnDN_MN=true; // Флаг разворота вверх на MN
}
}
ha sempre ucciso la logica di una tale costruzione in operandi ciclici:
completamente incomprensibile ...
Se non lo capite, posso solo comprenderlo.
Se me lo chiedete, la logica standard è più chiara e comprensibile:
Trovo molto più logico mettere le parentesi su una riga o in una colonna. È molto difficile capire il codice in cui non è chiaro dove inizia o finisce un blocco. Bene, se lo scopo di tale formattazione è quello di nascondere il senso del codice ai nemici, allora l'obiettivo è raggiunto.
Sono sempre stato ucciso dagli if annidati -- perché fare tale annidamento alla fonte?
Se non è chiaro, posso solo simpatizzare.
La vostra logica non è standard. È sbagliato.Mi correggo, è solo una frase che si attacca :-)
--
Una logica non convenzionale non significa che sia sbagliata.
--
Quando il percorso della logica non standard è più breve di quello della logica standard - a parità di condizioni di ingresso e uscita -.
allora al diavolo gli standard!
Allora sono a favore della logica non standard.
--
sì, il codice crunch è difficile da leggere...
...anche se ho visto un codice molto breve e difficile da leggere...
per la manutenzione - replicare questo codice non è l'ideale.
Se lo scrivi per la circolazione, di solito devi occuparti dei tuoi colleghi per mantenerlo.
se si scrive codice con l'aspettativa che qualcuno lo rompa!
Idealmente, è LOGICO passare attraverso il problema - scrivere codice corretto ma renderlo illeggibile.
Non capisco dove sia la foratura? E perché il secondo? Se è il secondo, allora dov'è il primo?
Il codice che è stato rimproverato non è davvero super, è perfetto per confondere!
2 Vinin . Victor, perché chiamare sempre la funzione di selezione dell'ordine? È più facile riempire tutte le variabili in un solo ciclo.
Penso che sia abbastanza buono:
int time;In MQL il comportamento degli operatori && e || è diverso che in C++, quindi ha senso separare le condizioni.
2 Vinin - Victor, perché chiamare sempre la funzione di selezione dell'ordine? È più facile riempire tutte le variabili in un solo ciclo.
...Dipende.
Vedo solo l'utilità di aumentare la velocità del codice
In generale, la velocità non è cruciale nel 90% dei casi. Il punto è fare inizialmente il codice in modo che sia il più facile possibile da costruire e leggere.
Poi, se il tempo è fondamentale, ottimizziamo la velocità.
Trasferirsi qui da qui