Interesante visión de la OLP - página 10
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
No me gusta nada este diseño en cuanto a legibilidad y desorden
Estoy de acuerdo)))
La única justificación para esto es la depuración)
No me gusta nada este diseño en cuanto a legibilidad y desorden
esa era originalmente mi pregunta
los últimos ejemplos son la afirmación de @fxsaber de que habrá códigos 100% diferentes en tiempo de ejecución. he publicado el desensamblador del depurador hace un par de páginas - los códigos son 90% iguales
no se trata de no devolver las construcciones simples que se leen sin problemas
los desarrolladores escribieron en alguna parte y aquí información similar
sólo encontré esto:
switch es un goto seguro que utiliza una tabla de saltos. Es decir, la dirección del "caso" se calcula utilizandouna clave entera en switch. Debido a esto, switch es extremadamente eficiente incluso comparado con if-else, por no hablar de colecciones más avanzadas como los diccionarios.
¿No tiene esto el efecto negativo de escribir cualquier código de calidad con la expectativa de que "el compilador lo cepillará hasta lo óptimo"?
Con un estilo de escritura, sabes con seguridad que el compilador hará lo correcto. Con otro estilo sólo hay que confiar en que el compilador es más inteligente.
Teniendo en cuenta la multiplicidad de plataformas, los diferentes compiladores, etc., opto por ser consciente de lo que se hace en el código.Sólo el compilador sabe exactamente lo que hará. Los compiladores actuales tienen una eurística asombrosa. Se adaptan al codificador medio y ya saben mejor lo que necesita. Lo mejor que puede hacer un compilador es escribir un código sencillo y directo con funciones cortas. Es más fácil y eficiente para el compilador analizar el gráfico del código fuente que consta de muchos nodos de función para construir el programa resultante. Esto sólo puede tener un impacto positivo en el rendimiento, ya que las funciones necesarias están alineadas en los lugares adecuados.
switch es un goto seguro que utiliza una tabla de saltos. Es decir, la dirección del "caso" se calcula a partir dela clave entera en switch. Por ello, switch es extremadamente eficiente incluso comparado con if-else, por no hablar de colecciones más avanzadas como los diccionarios.
Genial, es una información muy útil.
Gracias.
Muchas personas recomiendan escribir clases pequeñas. El mismo Eckel dice: "crear clases para un propósito único y claramente definido".
Estoy trabajando en un EA ahora mismo, y voy a escribir una pequeña simplificación para un ejemplo. Hay uno de los parámetros "Reach max stoploss". Al obtener SL debería funcionar como contador de retorno hasta cero y detener el trabajo del EA, y al obtener TP debería restablecer el valor inicial, con el valor mostrado en el panel.
He creado una clase separada para este contador. Resulta que cambia desde varios puntos, desde OnInit al establecer los parámetros de entrada y desde el campo de entrada del panel tras el cierre de la orden (sl y tp cambian de valor de forma diferente). Además, la función principal es llamada desde OnTick() para llevar un control del número máximo de stoploss para detener el EA.
La clase parece ser muy sencilla. Pero resulta que esta pequeña clase afecta a otros objetos situados en el panel (caja de entrada, botones). Afecta al funcionamiento de otras funciones. Y cuando hay una docena de estas pequeñas clases, ya es difícil seguir la pista de qué funciones cambian el objeto o qué métodos de algunos objetos pueden cambiar el estado de otros objetos.
Quiero saber cómo organizar la interacción de los objetos entre sí de la mejor manera para reducir la confusión, ¿hay algún buen artículo o libro con ejemplos de códigos, diagramas sobre este tema y buenas explicaciones? Por favor, comparta lo que ayudó a alguien a aprender a escribir arquitecturas bien diseñadas.
No me gusta nada este diseño en cuanto a legibilidad y desorden
Sabor y color.... todos los rotuladores son diferentes.
Era un contraste con el "pequeño monstruo":
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Opinión interesante sobre OOP
fxsaber, 2021.01.31 01:09
Un pequeño monstruo.
Lasoperaciones lógicas permiten una escritura concisa cuando se utilizan diferentes configuraciones mediante macros. Pero es un horror, por supuesto.
Sabor y color.... todos los rotuladores son diferentes.
No es cierto. Sólo varían en color, pero todos saben igual... ))))
No me gusta nada este diseño en cuanto a legibilidad y desorden
¿Por qué?
Por el contrario, con dos "if" es mucho más fácil que con el operador "or".
Es más fácil comprobar una condición primero, y salir de la función si es verdadera, y luego comprobar otra, y salir también, si es verdadera, que tratar de averiguar cuál es el resultado de una condición compleja, utilizando la "o" lógica (que puede confundirse fácilmente con la "y"), y llevar la cuenta de ambas opciones de retorno.
Es bastante gracioso leer más abajo que "la justificación de tal es la depuración", porque significa que tal código es mucho más comprensible (si no, ¿por qué está en depuración?).
"Apoteosis" considero una expresión de fxsaber, sobre la que él mismo no pudo decir cómo funciona, afirmando simplemente que "el código ha sido probado repetidamente, y funciona". Eso, en mi opinión, no debería ser así:
ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType) { const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE); const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE); return((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN) || ((iFillingMode & (otfFilingType + 1)) != otfFilingType + 1)) ? (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT)) ? ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK)) : otfFilingType); };Este código comprueba sila orden otfFilingType puede serejecutada, y la devuelve si está disponible en strSymbol, en caso contrario es correcta.
No tengo ni idea de cómo funciona. Y sólo confiar en la autoridad de fxsaber.
¿Quizás alguien pueda explicarlo?