Projeto do assessor - página 2

Novo comentário
 
Vasiliy Sokolov:

Reorganizar os parênteses não faz com que seja menos confuso. Antes de dar conselhos, pelo menos, eleve seu nível até a média.

O que há de errado com meu nível?

 
STARIJ:

O comentário deve ocupar metade do texto do programa

Eu até escrevo algumas coisas - primeiro um longo comentário "o que deve acontecer aqui", e depois um código que o implemente :-) A propósito, eu também aconselho esta abordagem para iniciantes
 
Maxim Kuznetsov:
Algumas coisas que escrevo - primeiro um longo comentário "o que deveria estar lá", e depois um código que o implemente :-) A propósito, também aconselho tal abordagem para iniciantes
Primeiro um toco para função com descrição do que fará e retornará (algo). Então o código
 
Vitaly Muzichenko:

Não escreva funções que são sempre constantes e nunca mudam neste estilo

Escreva-os concisamente, ninguém nunca olha para eles de qualquer maneira, e ocupam a metade do espaço.


Comente o código o tempo todo, o que este pedaço de código é responsável, não é difícil, e agora você sempre saberá o que é o código, e reduzirá o tempo para estudá-lo


Vitaly, entendi bem, você tem uma tela de 12" para laptop?

Lembro-me que antigamente, no CV-1420 com tela alfanumérica 24 linhas x 80 caracteres, também tentava economizar espaço)) Agora, de alguma forma, eu tento escrevê-lo para que seja mais rápido de entender.

 
Vitaly Muzichenko:

Não escreva funções que são sempre constantes e nunca mudam neste estilo

Escreva-os concisamente, ninguém nunca olha para eles de qualquer maneira, e ocupam a metade do espaço.


Comente o código o tempo todo, o que este código é responsável por ele, não é difícil, e aqui na revisão sempre saberá o que o código, e reduzirá o tempo para estudá-lo

E depois fazer contato visual com o que estes 4 colchetes na parte inferior se referem. Este é um estilo de código muito ruim. Em geral a MS tem o melhor, e o fato de que a MQ professa ser o estilo K&R não é motivo para imitá-lo. Os tempos dos cartões perfurados e dos monitores 80x24 já se foram há muito tempo.

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:
Bem, então 90% do código são comentários. Além disso, tem que haver o máximo possível de código sem sentido e de má leitura, para que seja possível fazer mais comentários!

Mas quando eu for velho, posso publicar os comentários na forma de um livro "Forex and Me" )))). Não, eu prefiro "Eu e o Forex".

 
Alexey Volchanskiy:

E, em seguida, escolha seus olhos sobre o que esses quatro colchetes na parte inferior se referem. Este é um estilo de código muito ruim. Em geral, a MS tem o melhor, e o fato de que a MQ professa o estilo K&R não é motivo para imitá-lo. Os tempos dos cartões perfurados e dos monitores 80x24 já se foram há muito tempo.


Mas quando eu for velho, posso publicar os comentários na forma de um livro "Forex and Me" )))). Não, eu prefiro "Eu e o Forex".

Tela de trabalho 27".

Não vou reler, mas citar:"Não escreva funções que são sempre constantes e nunca mudam neste estilo"

Por que escolher seus olhos sobre uma função que é escrita uma vez quando a plataforma é liberada e nunca mudará no futuro? Você costuma mudar/editar código em funções para obter tamanho de lote, número de pedidos e típico? Então por que esticá-lo através de 3 telas de um monitor de 32"?

P.S. O código anexo é forjado a partir do kodobase.

 
Vitaly Muzichenko:

Tela de trabalho de 27".

Não vou relê-la, vou apenas citá-la:"Não escreva funções que são sempre constantes e nunca mudam nesse estilo"

Por que escolher seus olhos sobre uma função que é escrita uma vez quando a plataforma é liberada e nunca mudará no futuro? Você costuma mudar/editar o código nas funções para obter tamanho de lote, número de pedidos e típico? Então por que esticá-lo através de 3 telas de um monitor de 32"?

O arquivo onde eles se encontram é aberto uma vez a cada trezentos anos da mesma maneira.

E quando ela abrir - vá encontrá-la em uma pilha }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} o que é o quê.

Por que você escreveria uma armadilha para si mesmo se a escrevesse, a testasse e a enviasse a uma biblioteca ou a uma classe para armazenamento? É isso aí. E quando você precisa refrescar sua memória (pode ser, você precisa fazer algo com base nisso, o que quer que seja... você precisa acrescentar algo ) - você apenas senta e move parênteses...

 
Vitaly Muzichenko:

Tela de trabalho de 27".

Não vou relê-la, vou apenas citá-la:"Não escreva funções que são sempre constantes e nunca mudam neste estilo"

Por que escolher seus olhos sobre uma função que é escrita uma vez quando a plataforma é liberada e nunca mudará no futuro? Você costuma mudar/editar código em funções para obter tamanho de lote, número de pedidos e típico? Então por que esticá-lo através de 3 telas de um monitor de 32"?

P.S. O código é anexado puxado da kodobase.

Vitaly, a primeira versão de sua função mostra claramente qual colchete de fechamento se refere a qual abertura, enquanto a segunda versão quebra seus olhos em busca de um par...

Normalmente, as funções personalizadas não são tão grandes que não possam caber na tela. E não importa em nada como os parênteses estão dispostos na EA compilada.

 
Artyom Trishkin:

O arquivo onde eles se encontram também é aberto uma vez a cada trezentos anos.

Mas quando abrir, você terá que pesquisar através da pilha }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} para descobrir o que há nela.

Por que escrever uma armadilha para você mesmo, se você a escrever, testá-la e enviá-la para a biblioteca ou classe para armazenamento. É isso aí. E quando é necessário refrescar sua memória (talvez fazer algo com base nisso, nunca se sabe...) - basta sentar e mover parênteses...

Não, eu não tenho nada no arquivo, não sou ganancioso e compartilho programas com conhecidos e muitas vezes, e em vez de enviar arquivos, eu envio apenas um arquivo.

Todas as funções estão no fundo, mas o código executivo está sempre bem escrito e comentado, até mesmo uma criança pode descobrir isso.

 
Gregory Kovalenko:
Olá.
À medida que a quantidade de código cresce, às vezes fica difícil e confusa.
Já vi código EA com um grande número de linhas de código, eu me pergunto como os EAs complexos são projetados, talvez existam algumas ferramentas ou técnicas para lidar com algoritmos tão complexos...

Eu tenho vários milhares de linhas de código em qualquer EA. (Eles são incluídos automaticamente através de inclusões).

Na verdade, um EA consiste na classe CExpert, que tem funções OnInit, OnTick, etc. No modelo de conexão da EA, todas as funções globais - eventos - chamam as funções correspondentes a este tipo de objeto.

Durante a inicialização - CExpert solicita através da função global predefinida "fábrica de peças EA", que sabe como criar tudo o que é necessário para o trabalho.

O próprio Expert Advisor consiste em cinco linhas. O objeto da própria fábrica de peças da EA é declarado neste arquivo, e as inclusões estão incluídas.

Eu pessoalmente gosto muito da abordagem OOP, com a divisão das interfaces virtuais e a implementação. Primeiro, descrevemos o arquivo de interface - uma classe abstrata na qual todas as funções são virtuais e iguais a zero. Esta classe define o "protocolo de interação". E então, herdamos dela classes reais nas quais todas estas funções são plenamente implementadas (às vezes temos toda uma hierarquia de classes, quando a descrição das funções é distribuída "por nível").

Esta abordagem - permite separar as entidades, o que torna muito fácil apoiar ainda mais todo o projeto, bem como as classes de reutilização.

1234567
Novo comentário
Razão: