Estilizador no terminal comercial MetaTrader 5 - página 5

[Andrey Khatimlianskii]

Renat :

Cavalheiros, para quem está a ser escrito o código?

Tenho quase a certeza que é para outros programadores. É muito desagradável para eles ler o código não formatado de outras pessoas.

Foi para resolver este mesmo problema que criámos a função styler integrada. Se quiser que outras pessoas (não você, mas outras pessoas) estejam dispostas a ver através do seu código, é melhor torná-lo o mais simples e inequívoco possível. E a palavra-chave aqui é "pessoas", não "você".

Renat, para quem foi escrito o estilista?

Tenho quase a certeza de que foi escrito para outros utilizadores. Mas é muito desagradável para eles ler código formatado no estilo de outra pessoa.

É para resolver este problema que sugerimos o alargamento das funções do estilizador regular. Se quiser que outras pessoas (não você, mas outras pessoas) queiram usar o seu modelador, é melhor torná-lo o mais conveniente e personalizável possível. E a palavra-chave aqui é "pessoas", não "você".

Os programadores escrevem código não para eles próprios, embora pensem erroneamente que é para eles. Sabe disso, não sabe?

ps: esta desculpa CodeBase é absurda, o que é que o estilizador incorporado no editor tem a ver com isso?

[Renat Fatkhullin]

komposter :

ps: a desculpa sobre CodeBase é absurda, o que é que o modelador embutido tem a ver com isso...?

Quando construir, manter e pagar a Base de Código por si próprio, a questão desaparecerá de imediato. Ou acha que tudo à sua volta é feito de graça?

Neste momento, só estamos a falar da posição de princípio de "é mau só porque não é personalizável".

Passemos a pontos específicos - apontar qual o ponto e porque não é feito correctamente pelo estilizador.

[TheXpert]

Renat :

Agora só se fala da posição de princípio de "só é mau porque não é sintonizável".

Não estou de acordo.

Eu, por exemplo, tenho a seguinte posição - "o que temos não é bom porque não satisfaz as normas de codificação geralmente aceites. Os meios de satisfazer o resultado não importam".

Tem uma posição de princípio, e não apenas sobre esta questão.

E não está categoricamente disposto a ouvir os argumentos de outras pessoas, apesar de os argumentos serem bastante razoáveis e racionais.

Passemos a pontos específicos - aponte qual o ponto e porque é que o estilizador o faz mal.

O Styler faz tudo correctamente. Mas o resultado não é o desejado (aceitável).

[Stanislav Korotky]

TheXpert :

Não estou de acordo.

Por exemplo, a minha posição é a seguinte -- "o que não está satisfeito porque não cumpre as normas de codificação geralmente aceites. embora não satisfeito, não utilizarei, quando satisfeito, utilizarei. Os meios de satisfazer o resultado não importam".

Tem uma posição de princípio, e não apenas sobre esta questão.

E não está disposto a ouvir com firmeza os argumentos de outras pessoas, mesmo que sejam bastante razoáveis e racionais.

O Styler faz tudo correctamente. Mas o resultado não é o que se pretende (aceitável).

+1. Em todos os aspectos.

Apenas se toma a decisão de voltar aos estilos padrão. Eles simplesmente não querem admitir os erros de adoptar uma vez no passado um estilo tortuoso.

[VonDo Mix]

marketeer :

+1. Em todos os aspectos.

Apenas se toma a decisão de voltar aos estilos padrão. Eles apenas não querem admitir os erros de adoptar um estilo tortuoso algum tempo no passado.

Não estou de acordo com a "curvatura".

Tem um sabor "mais saboroso" e "mais brilhante" para eles... Não discuta sobre isso.

E sobre a personalização, dizem eles - de volta ao tópico mais tarde

;)

[Stanislav Korotky]

Sorento :

Não estou de acordo com a 'curvatura'.

Tem um sabor "mais saboroso" e "mais brilhante" para eles... Não discuta sobre isso.

E sobre as configurações, dizem eles - de volta ao assunto mais tarde

;)

O que quer dizer com não concordar? Há normas de facto com as quais não se pode discordar, basta segui-las. Não lhes ocorreu gerar relatórios no seu próprio HTML com uma subversão - eles fizeram-no exactamente no padrão. É o mesmo com estilo. A programação é uma indústria global, os estilos são definidos, e a MetaQuotes não pode ir contra as massas com tal "inovação".

[Renat Fatkhullin]

Por favor especifique qual o artigo e porque não é feito correctamente pelo modelador.

De preferência com uma demonstração de peças de código formatadas.

[TheXpert]

Renat :

Por favor especifique qual o artigo e porque não é feito correctamente pelo estilizador.

De preferência com demonstração de peças de código formatadas.

https://www.mql5.com/ru/forum/122145, apenas existem separadores pequenos -- 2 caracteres, mas não é tão crucial, embora seja normal 3-4.

A manifestação está no primeiro posto. Não há aí vírgula, deve ser como nesta frase.

Se está a falar a sério, posso citar excertos do nosso acordo de estilo empresarial.

[Sergey Kravchuk]

Renat :

Por favor especifique qual o artigo e porque é feito incorrectamente pelo modelador.

Seria desejável a demonstração de fragmentos de código formatados.

Renat, isto já é anti-desportivo ;)

MQL é a SUA língua, não existe um padrão para ela, por isso tem o direito de estabelecer os SEUS padrões. E não lhe iremos provar nada.

Mas o MQL é uma linguagem semelhante ao C. E C tem várias normas geralmente aceites. Aqui estão: https://en.wikipedia.org/wiki/Indent_style.

Eu pessoalmente prefiro o estilo Allman (bsd em Emacs).

O estilo coloca a cinta associada a uma declaração de controlo na linha seguinte, recuada ao mesmo nível da declaração de controlo. As declarações dentro da cinta são recuadas para o nível seguinte.

enquanto (x === y)
{
    algo();
    { somethingelse();
}
 finalthing();

Parece-me que o problema de defender o seu próprio ponto de vista é absolutamente rebuscado. Querem ver o vosso texto formatado assim, sejam meus convidados! Mas há outras pessoas que querem vê-lo formatado de forma diferente. Estas pessoas (que não têm acesso ao corpo) pedem-lhe que considere as suas necessidades e faça ajustes na formatação para que esta possa ser formatada tanto à sua maneira como à deles. Só você - os criadores podem fazer isto. É a isto que nos voltamos para si com este pedido. Ou nos encontra a meio caminho ou envia-nos a todos de volta ao seu padrão. Escolha a sua opção e anuncie-a.

[Sergey Kravchuk]

Apenas alguns parágrafos para acrescentar porque é que penso que esta questão é importante e porque é que penso que o estilo Allman (bsd em Emacs) é o correcto. Esqueçamos por um momento quem está habituado a quê e apelemos à lógica nua.

Porque precisa de formatar o texto? A fim de isolar e dividir blocos lógicos individuais, utilizando esta mesma formatação.

Vamos dar uma vista de olhos a um tempo vulgar. Tem dois blocos logicamente isolados: o "cabeçalho" do laço e o corpo do laço. Para não os misturar, têm de ser colocados em linhas separadas. Por esta razão, abrir parênteses na mesma linha de enquanto (para mim pessoalmente) causa perplexidade (é como um homem a meio de uma sala - o corpo inteiro está na sala e a cabeça continua "deixada" atrás da porta).

Agora a segunda questão é empurrar parênteses ou não? Em princípio, os parênteses não se referem directamente ao cabeçalho e são antes uma parte do corpo do laço. No entanto, apenas comandos executáveis devem ser empurrados para dentro, ou seja, algo que tenha a sua própria lógica separada. Mas há pelo menos um exemplo sensato de um laço sem corpo:

while ( TradingServerNotAvailable() )
{
}

Simplesmente não temos nada para fazer enquanto o servidor comercial não estiver disponível - por isso não fazemos nada e o ciclo do corpo está vazio. Neste caso, os parênteses empurrados dentro do olhar (do meu ponto de vista) - um pouco estranho: direito deslocado e vazio realçado.

Quando um laço tem um corpo, é movido para a direita e é disponibilizado espaço à esquerda para encontrar pares de parênteses de fecho:

while ( TradingServerNotAvailable() )
{
   Sleep ( 1000 );
}

Esta é outra razão pela qual abrir parênteses não deve ser colocado na mesma linha que o cabeçalho do laço - são mais difíceis de encontrar quando se procura fechar parênteses. Na minha versão, pode ver claramente um parêntesis nesta posição e o seu homólogo noutra linha, mas na mesma posição. Além disso, a linha com um único suporte (mesmo sem comentários!) serve como um elemento visual adicional, realçando e separando o bloco interno do externo.

Como pode ver: nada pessoal - apenas a lógica da percepção visual do texto!

E é do ponto de vista dessa lógica (e não das preferências e hábitos pessoais) que o texto na formatação actual do estilista é incompreensível para mim:

// чего вдавлен внутрь кусок кода - в котором кода нет и выделять там нечего
 while ( TradingServerNotAvailable() )
   {
   }

// каждый отступ вправо ассоциируется с новым уровнем вложенности, а здесь визуально ТРИ уровня!
 while ( TradingServerNotAvailable() ) // первый уровень
  {                                   // второй уровень
   Sleep(1000);                       // третий уровень
  }

E se, na escrita inspirada no GNU, é apenas papa.

if ( TradingServerNotAvailable() ) {
  ....
} else { // вот тут в одной строке ТРИ элемента разных блоков: закрытие предыдущего, разделитель, начало следующего :(((
  ....
}

e como pode dizer se não perdeu os parênteses de abertura ou colocar um parêntese de fecho extra? É assim:

if ( TradingServerNotAvailable() ) 
{
  ....
} 
 else 
{ 
  ....
}

Mais uma vez: não são os meus hábitos pessoais ou qualquer outra coisa - apenas a lógica da percepção visual do texto!