Enseño desde cero, así como ayudo a los recién llegados a unirse a las filas de los profesionales de MQL4. - página 7

 
Dmitry Sumsky:

¿No tienes nada mejor que hacer que pasar horas buscando fallos en mi código o es que soy un pesado y quieres vengarte de mí?

Eres un hombre extraño, Andrew...

¿Para qué sirve el foro? -- Para divertirse.

estoy tomando mi té en un platillo y algunos pasteles -- busco en el foro y tal vez encuentre algo para divertirme -- tu tema es divertido (siempre me gustó este).

p.d. ¿por qué necesitas venganza, y por qué razón? -- p.s.2 no te enfades conmigo - es curioso, tu tema siempre ha sido un aprendizaje para mí.


p.s.2 no te enfades, he borrado mi post - tal vez era realmente espinoso - no pretendía ofenderte de ninguna manera

 
Andrey F. Zelinsky:

¿para qué sirve el foro? -- por diversión.

estoy tomando una taza de té y bollos -- estoy navegando por el foro, quizás encuentre algo para divertirme -- tu tema es divertido (siempre me ha gustado el tema del aprendizaje).

p.d. ¿por qué necesitas venganza y para qué? - No entiendo

Además, Dimochka, tú eres el que me atacó primero... yo soy puramente la parte perjudicada.

Eres una chica tan inocente. Irrumpiste en mi cuna y empezaste a decirme cómo vivir mi vida. Todo lo que hice fue decir toda la verdad. Por lo visto, la verdad se te metió en la garganta y decidiste buscar alguna pista, para fastidiarme de alguna manera. Pero cuanto más despotricas, más te humillas. Puedes seguir provocándome humillándote delante de los demás. Esto es un foro, un foro de hilaridad. Además, no sólo lo leemos tú y yo... )))
 
Dmitry Sumsky:
Eres una chica tan inocente. Irrumpiendo en mi cuna, diciéndome cómo vivir mi vida. Todo lo que dije fue toda la verdad. Al parecer, la verdad se te metió en la garganta y decidiste encontrar alguna pista para fastidiarme de alguna manera. Pero cuanto más despotricas, más te humillas. Puedes seguir provocándome humillándote delante de los demás. Esto es un foro, un foro de hilaridad. Además, no sólo lo leemos tú y yo... )))

Te escribí:

Andrey F. Zelinsky:

p.s.2 no te enfades, he borrado mi post -- tal vez fue un pinchazo -- no quise ofenderte de ninguna manera

-- y tú sigues atacando -- probablemente no debería haber borrado mi post.

 
Andrey F. Zelinsky:

Tú... yo te escribí:

-- y sigues atacando -- debo haber borrado mi post para nada.

Debes haberla borrado mientras escribía. Bueno, lo siento... )))
 
Dmitry Sumsky:

Este hilo está pensado para ayudar a los que intentan aprender pero les resulta largo y doloroso. Sólo ofrecí mi ayuda para aprender más rápido el lenguaje, además de entender cómo funciona en la memoria del ordenador, para poder programar el mejor código de una vez, en lugar de hacerlo "de alguna manera", y luego tratar de optimizarlo... )))

Creo que estas construcciones no son muy óptimas:

for(int i=0; i+1<iBars(NULL,Sarpperiod); i++)

Sería mejor asignar el resultado de la función iBars() a una variable antes del operador for, ya que se comprueba la veracidad de la "Expresión2" después de cada iteración, y cada vez que se llame a la función se tardará más tiempo que comparándola con una variable.

 
Vasiliy Pushkaryov:

En mi opinión, estos diseños no son muy óptimos:

for(int i=0; i+1<iBars(NULL,Sarpperiod); i++)

Sería mejor asignar el resultado de la función iBars() a una variable antes de la sentencia for, ya que se comprueba la veracidad de la "Expresión2" después de cada iteración, y cada vez que se llame a la función, se tardará más tiempo que comparando con la variable.

Estoy de acuerdo, eso es básicamente lo que hago. Y si no hay diferencia en el inicio de la pasada, entonces escribo for(int i=iBars(NULL,SarPeriod)-1; i>=0; i--). Esto es óptimo para el proceso y menos caracteres en la cadena. En este código, no tenía como objetivo la optimización al 100% - tenía que hacer menos cadenas, así que lo escribí así... )))

Lo que más se "come" el proceso es el iCustom, etc., y ahí tengo mucho. Debería escribir los algoritmos de todos los indicadores que uso en el propio Asesor Experto para que "vuele", pero no tenía esa tarea...

 
Dmitry Sumsky:
Estoy de acuerdo, eso es básicamente lo que hago. Y si no hace ninguna diferencia donde empezar a pasar, entonces escribo for(int i=iBars(NULL,SarPeriod)-1; i>=0; i--). Esto es óptimo para el proceso y menos caracteres en una cadena. En este código, no tenía como objetivo la optimización al 100% - tenía que hacer menos cadenas, así que lo escribí así... )))
Ya veo. Entonces estoy satisfecho por sus estudiantes )
 
Vasiliy Pushkaryov:

En mi opinión, estos diseños no son muy óptimos:

for(int i=0; i+1<iBars(NULL,Sarpperiod); i++)

Sería mejor asignar el resultado de iBars() a una variable antes de la sentencia for, porque se comprueba la veracidad de la "Expresión2" después de cada iteración, y cada vez que se llame a la función, se tardará más tiempo que comparando con la variable.

Realmente no importa mucho. Recuerdo que en "El arte de la programación" de Knuth se decía algo así: un buen programador debería:

1. Ser capaz de acortar u optimizar cualquier programa,

2. no hacerlo nunca.

 
Yuriy Asaulenko:

Realmente no importa mucho. Recuerdo que The Art of Programming de Knuth decía algo así: un buen programador debería:

1. Ser capaz de acortar u optimizar cualquier programa,

2. no hacerlo nunca.

Me gusta más este enfoque.

Cuando escribo mis funciones, son largas y complejas. Contienen sangrías de varios niveles y bucles anidados. Tienen largas listas de argumentos. Los nombres se eligen de forma caótica y hay duplicados en el código. Pero también tengo un conjunto de pruebas unitarias para todas estas líneas torpes hasta la última.

Así que empiezo a "peinar" y refinar mi código, destacando nuevas funciones, cambiando nombres y eliminando duplicados. Acorto los métodos y los reordeno. A veces tengo que romper clases enteras, pero me aseguro de que todas las pruebas se ejecuten con éxito.

Al final, me quedo con las funciones construidas de acuerdo con las reglas señaladas en esta categoría. No los escribo así desde el principio. Y no creo que nadie pueda hacerlo en absoluto.

Robert Martin, Clean Code. Creación, análisis y refactorización.

Algunas personas son capaces y lo hacen, otras son capaces y no lo hacen, es una cuestión de cómo uno lo hace.

 
Vasiliy Pushkaryov:

Me gusta más este enfoque

Algunos pueden y lo hacen, otros pueden y no lo hacen, es cuestión de cómo lo hagas.

No se trata de enfoques mutuamente excluyentes. Se trata de cosas diferentes.