Styler en el terminal comercial MetaTrader 5 - página 5

[Andrey Khatimlianskii]

Renat :

Señores, ¿para quién se escribe el código?

Estoy bastante seguro de que es para otros programadores. Es muy desagradable para ellos leer el código sin formato de otras personas.

Es para resolver este mismo problema que creamos la función integrada del estilizador. Si quieres que otras personas (no tú, sino otras personas) estén dispuestas a revisar tu código, será mejor que lo hagas lo más sencillo y sin ambigüedades posible. Y la palabra clave aquí es "gente", no "tú".

Renat, ¿para quién se escribió el estilista?

Estoy bastante seguro de que fue escrito para otros usuarios. Pero es muy desagradable para ellos leer código formateado en el estilo de otra persona.

Para resolver este problema, proponemos ampliar las funciones del estilizador normal. Si quieres que otras personas (no tú, sino otras personas) quieran usar tu estilista, será mejor que lo hagas lo más cómodo y personalizable posible. Y la palabra clave aquí es "gente", no "tú".

Los programadores no escriben el código para sí mismos, aunque creen erróneamente que es para ellos. Lo sabes, ¿no?

ps: esta excusa de CodeBase es absurda, ¿qué tiene que ver el estilizador incrustado en el editor?

[Renat Fatkhullin]

komposter :

ps: la excusa sobre CodeBase es absurda, ¿qué tiene que ver el estilizador incrustado...?

Cuando construyas, mantengas y pagues tú mismo el Code Base, la pregunta desaparecerá de inmediato. ¿O crees que todo lo que hay alrededor se hace gratis?

Ahora mismo, todo lo que estamos hablando es la posición de principio de "es malo sólo porque no es personalizable".

Pasemos a los puntos concretos: señale qué punto y por qué no lo hace correctamente el estilista.

[TheXpert]

Renat :

Ahora toda la palabrería se centra en la postura de principio de "sólo es malo porque no es sintonizable".

No estoy de acuerdo.

Yo, por ejemplo, tengo la siguiente postura: "lo que tenemos no es bueno porque no cumple las normas de codificación generalmente aceptadas. Los medios para satisfacer el resultado no importan".

Tienes una posición de principios, y no sólo en este tema.

Y usted se niega rotundamente a escuchar los argumentos de los demás, aunque los argumentos sean bastante razonables y racionales.

Pasemos a los puntos concretos: señale qué punto y por qué lo hace mal el estilista.

Styler lo hace todo correctamente. Pero el resultado no es el deseado (aceptable).

[Stanislav Korotky]

TheXpert :

No estoy de acuerdo.

Por ejemplo, mi posición es la siguiente: "lo que no está satisfecho porque no cumple las normas generalmente aceptadas para la codificación. mientras no esté satisfecho, no lo usaré, cuando esté satisfecho, lo usaré". Los medios para satisfacer el resultado no importan".

Tienes una posición de principios, y no sólo en este tema.

Y usted se niega rotundamente a escuchar los argumentos de los demás, aunque sean bastante razonables y racionales.

Styler lo hace todo correctamente. Pero el resultado no es el deseado (aceptable).

+1. En todos los aspectos.

Sólo hace falta una decisión para volver a los estilos estándar. Sencillamente, no quieren admitir los errores de haber adoptado un estilo torcido en el pasado.

[VonDo Mix]

marketeer :

+1. En todos los aspectos.

Sólo hace falta una decisión para volver a los estilos estándar. Simplemente no quieren admitir los errores de haber adoptado un estilo torcido en algún momento del pasado.

No estoy de acuerdo con la "curvatura".

Les sabe "más sabroso" y "más brillante"... No discutas por ello.

Y sobre la personalización, dicen - volviendo al tema más tarde

;)

[Stanislav Korotky]

Sorento :

No estoy de acuerdo con la "curvatura".

Les sabe "más sabroso" y "más brillante"... No discutas por ello.

Y sobre los ajustes, dicen - volviendo al tema más tarde

;)

¿Cómo que no estás de acuerdo? Hay normas de facto con las que no se puede estar en desacuerdo, sólo hay que seguirlas. No se les ocurrió generar informes en su propio HTML con una subversión - lo hicieron exactamente en el estándar. Lo mismo ocurre con el estilo. La programación es una industria global, los estilos están definidos, y MetaQuotes no puede ir en contra de las masas con tal "innovación".

[Renat Fatkhullin]

Por favor, especifique qué elemento y por qué no lo hace correctamente el estilista.

Preferiblemente con una demostración de piezas de código formateadas.

[TheXpert]

Renat :

Por favor, especifique qué artículo y por qué no lo hace correctamente el estilista.

Preferiblemente con demostración de piezas de código formateadas.

https://www.mql5.com/ru/forum/122145, sólo allí las pestañas son pequeñas -- 2 caracteres, pero no es tan crucial, aunque es normal 3-4.

La demostración está en el primer post. Ahí no hay coma, debería ser como en esta frase.

Si lo dices en serio, puedo citar extractos de nuestro acuerdo de estilo corporativo.

[Sergey Kravchuk]

Renat :

Por favor, especifique qué elemento y por qué está mal hecho por el estilista.

Sería deseable la demostración de fragmentos de código formateados.

Renat, esto ya es antideportivo ;)

MQL es SU lenguaje, no hay ningún estándar para él, así que tiene el derecho de establecer SUS estándares. Y no le demostraremos nada.

Pero MQL es un lenguaje similar a C. Y C tiene varias normas generalmente aceptadas. Aquí están: https://en.wikipedia.org/wiki/Indent_style.

Personalmente prefiero el estilo Allman (bsd en Emacs).

El estilo coloca la llave asociada a una sentencia de control en la línea siguiente, con sangría al mismo nivel que la sentencia de control. Las sentencias dentro de las llaves están sangradas al siguiente nivel.

while (x == y)
{
    algo();
    { algo más();
}
 finalthing();

Me parece que el problema de defender tu propio punto de vista es absolutamente descabellado. Si quieres ver tu texto formateado así, ¡adelante! Pero hay otras personas que quieren verlo con un formato diferente. Estas personas (que no tienen acceso al cuerpo) te piden que tengas en cuenta sus necesidades y que hagas ajustes en el formato para que pueda estar formateado tanto a tu manera como a la suya. Sólo ustedes, los desarrolladores, pueden hacerlo. A esto nos dirigimos con esta petición. O nos satisface a medias o nos devuelve todo a su nivel. Elija su opción y anúnciela.

[Sergey Kravchuk]

Sólo un par de párrafos para añadir por qué creo que esta cuestión es importante y por qué creo que el estilo Allman (bsd en Emacs) es el correcto. Olvidemos por un momento quién está acostumbrado a qué y apelemos a la lógica desnuda.

¿Por qué hay que formatear el texto? Para aislar y dividir los bloques lógicos individuales en él, utilizando este mismo formato.

Veamos un rato cualquiera. Tiene dos bloques lógicamente aislados: la "cabecera" del bucle y el cuerpo del bucle. Para no mezclarlos, hay que colocarlos en líneas separadas. Por esta razón, abrir paréntesis en la misma línea que mientras (para mí personalmente) causa desconcierto (es como un hombre que entra a medias en una habitación: todo el cuerpo está en la habitación y la cabeza sigue "quedando" detrás de la puerta).

Ahora la segunda pregunta es ¿empujar los soportes o no? En principio, los paréntesis no se refieren directamente a la cabecera, sino que forman parte del cuerpo del bucle. Sin embargo, sólo deben introducirse comandos ejecutables, es decir, algo que tenga su propia lógica. Pero hay al menos un ejemplo sensato de bucle sin cuerpo:

while ( TradingServerNotAvailable() )
{
}

Simplemente no tenemos nada que hacer mientras el servidor de comercio no esté disponible, así que no hacemos nada y el ciclo del cuerpo está vacío. En este caso, los corchetes empujados hacia el interior se ven (desde mi punto de vista) - un poco extraño: desplazado a la derecha y vacío resaltado.

Cuando un bucle tiene un cuerpo, se desplaza a la derecha y se deja espacio a la izquierda para encontrar pares de paréntesis de cierre:

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

Esta es otra razón por la que los paréntesis de apertura no deben colocarse en la misma línea que la cabecera del bucle - son más difíciles de encontrar allí cuando se buscan los paréntesis de cierre. En mi versión, se puede ver claramente un paréntesis en esta posición y su homólogo en otra línea pero en la misma posición. Además, la línea con un solo corchete (¡incluso sin comentarios!) sirve como elemento visual adicional, resaltando y separando el bloque interno del externo.

Como puede ver: nada personal - ¡sólo la lógica de la percepción visual del texto!

Y es desde el punto de vista de esa lógica (y no de las preferencias y hábitos personales) que el texto con el formato actual del estilista me resulta incomprensible:

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

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

Y si, en la escritura inspirada en GNU, es sólo papilla.

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

¿y cómo se puede saber si no se ha perdido un paréntesis de apertura o se ha puesto un paréntesis de cierre de más? Es así:

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

una vez más: no se trata de mis hábitos personales ni de nada, ¡es sólo la lógica de la percepción visual del texto!