Progetto del consigliere - pagina 2

Nuovo commento
 
Vasiliy Sokolov:

Risistemare le parentesi non lo rende meno incasinato. Prima di dare consigli, porta almeno il tuo livello alla media.

Cosa c'è che non va nel mio livello?

 
STARIJ:

Il commento dovrebbe occupare metà del testo del programma

Scrivo anche alcune cose - prima un lungo commento "cosa dovrebbe succedere qui", e poi il codice che lo implementa :-) A proposito, consiglio questo approccio anche ai principianti
 
Maxim Kuznetsov:
Alcune cose che scrivo - prima un lungo commento "cosa dovrebbe esserci", e poi il codice che lo implementa :-) A proposito, consiglio un tale approccio anche ai principianti
Prima uno stub per la funzione con la descrizione di ciò che farà e il ritorno (qualcosa). Poi il codice
 
Vitaly Muzichenko:

Non scrivere funzioni che sono sempre costanti e non cambiano mai in questo stile

Scriveteli in modo conciso, tanto nessuno li guarda mai, e occupano la metà dello spazio.


Commentare il codice tutto il tempo, di cosa è responsabile questo pezzo di codice, non è difficile, e ora saprete sempre qual è il codice, e ridurre il tempo per studiarlo


Vitaly, ho capito bene, hai uno schermo da 12 pollici?

Mi ricordo ai vecchi tempi, al CV-1420 con schermo alfanumerico 24 linee x 80 caratteri, anche, ha cercato di risparmiare spazio )) Ora in qualche modo cerco di scriverlo in modo che sia più veloce da capire.

 
Vitaly Muzichenko:

Non scrivere funzioni che sono sempre costanti e non cambiano mai in questo stile

Scriveteli in modo conciso, tanto nessuno li guarda mai, e occupano la metà dello spazio.


Commentare il codice tutto il tempo, ciò che questo pezzo di codice è responsabile per, non è difficile, e qui alla finalizzazione sarà sempre sapere che cosa il codice, e ridurre il tempo di studiarlo

E poi guarda a cosa si riferiscono queste 4 parentesi in basso. Questo è uno stile di codice molto cattivo. In generale MS ha il meglio, e il fatto che MQ professi lo stile K&R non è una ragione per emularlo. I tempi delle schede perforate e dei monitor 80x24 sono lontani.

void CloseOrders(int cmd) {
 for(int i=OrdersTotal()-1;i>=0;i--) {
  if(OrderSelect(i,SELECT_BY_POS)) {
   if(OrderSymbol()==Symbol() && OrderMagicNumber()==Magic) {
    if(OrderType()==OP_BUY && cmd==OP_BUY) {
     if(!OrderClose(OrderTicket(),OrderLots(),Bid,Slippage,Blue)) Print("Order BUY not close! Error = ",GetLastError());
    }
     if(OrderType()==OP_SELL && cmd==OP_SELL) {
      if(!OrderClose(OrderTicket(),OrderLots(),Ask,Slippage,Red)) Print("Order SELL not close! Error = ",GetLastError());
    }
}}}}
Vasiliy Sokolov:
Bene, allora il 90% del codice sono commenti. Inoltre, ci deve essere quanto più codice senza senso e mal leggibile possibile, in modo che sia possibile mettere più commenti!

Ma quando sarò vecchio potrò pubblicare i commenti sotto forma di un libro "Forex and Me" )))). No, preferisco "Io e il Forex".

 
Alexey Volchanskiy:

E poi scegliete con gli occhi a cosa si riferiscono quelle quattro parentesi in basso. Questo è uno stile di codice molto cattivo. In generale MS ha il meglio, e il fatto che MQ professi lo stile K&R non è una ragione per emularlo. I tempi delle schede perforate e dei monitor 80x24 sono lontani.


Ma quando sarò vecchio potrò pubblicare i commenti sotto forma di un libro "Forex and Me" )))). No, preferisco "Io e il Forex".

Schermo di lavoro 27".

Non ho intenzione di rileggerlo, ma di citarlo:"Non scrivere funzioni che sono sempre costanti e non cambiano mai in questo stile"

Perché puntare gli occhi su una funzione che viene scritta una volta sola quando la piattaforma viene rilasciata e non cambierà mai in futuro? Modificate spesso il codice nelle funzioni per ottenere la dimensione del lotto, il numero di ordini e il tipico? Allora perché allungarlo su 3 schermi di un monitor 32"?

P.S. Il codice allegato è falsificato da kodobase.

 
Vitaly Muzichenko:

Schermo di lavoro da 27 pollici

Non ho intenzione di rileggerlo, mi limiterò a citare:"Non scrivere funzioni che sono sempre costanti e non cambiano mai in quello stile"

Perché puntare gli occhi su una funzione che viene scritta una volta sola quando la piattaforma viene rilasciata e non cambierà mai in futuro? Modificate spesso il codice nelle funzioni per ottenere la dimensione del lotto, il numero di ordini e il tipico? Allora perché allungarlo su 3 schermi di un monitor 32"?

L'archivio dove giacciono viene aperto una volta ogni trecento anni nello stesso modo.

E quando si apre - vai a cercarlo in un mucchio }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} cosa è cosa.

Perché dovresti scrivere una trappola per te stesso se l'hai scritta, testata e mandata a una biblioteca o a una classe per la memorizzazione? Questo è tutto. E quando hai bisogno di rinfrescarti la memoria (può essere, hai bisogno di fare qualcosa sulla base di esso, qualunque cosa... hai bisogno di aggiungere qualcosa ) - basta sedersi e spostare le parentesi...

 
Vitaly Muzichenko:

Schermo di lavoro da 27 pollici

Non ho intenzione di rileggerlo, mi limiterò a citare:"Non scrivere funzioni che sono sempre costanti e non cambiano mai in quello stile"

Perché puntare gli occhi su una funzione che viene scritta una volta sola quando la piattaforma viene rilasciata e non cambierà mai in futuro? Modificate spesso il codice nelle funzioni per ottenere la dimensione del lotto, il numero di ordini e il tipico? Allora perché allungarlo su 3 schermi di un monitor 32"?

P.S. Il codice è allegato estratto da kodobase.

Vitaly, la prima versione della tua funzione mostra chiaramente quale parentesi di chiusura si riferisce a quale parentesi di apertura, mentre la seconda versione rompe gli occhi per cercare una coppia...

Di solito le funzioni personalizzate non sono così grandi da non potersi adattare allo schermo. E non importa affatto come sono disposte le parentesi nell'EA compilato.

 
Artyom Trishkin:

Anche l'archivio dove giacciono viene aperto una volta ogni trecento anni.

Ma quando si apre, dovrete cercare nel mucchio di }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} per scoprire cosa c'è dentro.

Perché scrivere una trappola per te stesso, se la scrivi, la testi e la mandi alla biblioteca o alla classe per la conservazione. Questo è tutto. E quando è necessario rinfrescare la memoria (magari fare qualcosa sulla base di essa, non si sa mai...) - basta sedersi e spostare le parentesi...

No, non ho niente nel file, non sono avido e condivido programmi con conoscenti e molto spesso, e invece di inviare archivi, invio solo un file.

Tutte le funzioni sono in basso, ma il codice esecutivo è sempre ben scritto e commentato, anche un bambino può capirlo.

 
Gregory Kovalenko:
Salve.
Quando la quantità di codice cresce, a volte diventa difficile e confusa.
Ho visto del codice EA con un enorme numero di linee di codice, mi chiedo come vengono progettati gli EA complessi, forse ci sono alcuni strumenti o tecniche per affrontare algoritmi così complessi?

Ho diverse migliaia di righe di codice in qualsiasi EA. (Sono automaticamente inclusi attraverso le inclusioni).

Infatti, un EA consiste nella classe-template CExpert, che ha funzioni OnInit, OnTick, ecc. Nel modello di collegamento dell'EA, tutte le funzioni globali - eventi - chiamano le funzioni corrispondenti di questo tipo di oggetto.

Durante l'inizializzazione - CExpert richiede tramite la funzione globale predefinita "EA parts factory", che sa come creare tutto il necessario per il lavoro.

L'Expert Advisor stesso consiste di cinque linee. L'oggetto stesso della fabbrica di parti EA è dichiarato in questo file, e le inclusioni sono incluse.

Personalmente mi piace molto l'approccio OOP, con la divisione delle interfacce virtuali e dell'implementazione. Per prima cosa, descriviamo il file di interfaccia - una classe astratta in cui tutte le funzioni sono virtuali e uguali a zero. Questa classe definisce il "protocollo di interazione". E poi, ereditiamo da essa delle vere e proprie classi in cui tutte queste funzioni sono completamente implementate (a volte abbiamo un'intera gerarchia di classi, quando la descrizione delle funzioni è distribuita "per livello").

Questo approccio - permette di separare le entità, il che rende molto facile sostenere ulteriormente l'intero progetto, così come riutilizzare le classi.

1234567
Nuovo commento