Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc.
Reglas de estructura. El contenido es secundario, la estructura es primordial.
Mi "Panel" tiene la estructura más sencilla: Evento -> Manejo
Los eventos también son sencillos: pulsación de botones, selección de listas, selección de calendarios, movimientos del ratón, etc.
Un problema bastante típico para empezar a diseñar: cómo organizar (estructurar) el manejo de eventos en un programa para que éste (el programa) pueda seguir desarrollándose y, al mismo tiempo, se pueda rehacer lo mínimo de lo que ya se ha hecho.
¿Quiere discutir las opciones?
De la rama"bugs, bugs, questions":
Un problema muy típico para el comienzo del diseño: cómo organizar (estructurar) el procesamiento de eventos en un programa para que éste (el programa) pueda seguir desarrollándose y, al mismo tiempo, rehacer lo que ya se ha hecho al mínimo.
¿Quiere discutir las opciones?
¿Existe algún tipo de literatura, por ejemplo?
En general, los problemas de diseño se solapan con el CAD y el TRIZ.
Dibujo en papel, por lo que me resulta más cómodo, a veces necesito hasta 50 hojas hasta que se hace una estructura clara. Puede ciertamente en spets.editores, pero cada uno de ellos para mí incómodo (limitado), imposible de realizar un vuelo de la fantasía, en definitiva, ralentizar el trabajo.
- ru.wikipedia.org
Tengo la opción más sencilla
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
¿qué se entiende por estructura?
ZS: A mí me enseñaron así:
1. Todo lo que se puede hacer en una función está en una función.
2. el goto es un pecado
3. Todas las condiciones deben ser mínimas y no debe haber ningún solapamiento en una condición
4. 3. sangría
5. hay que escribir de tal manera que otros puedan leerlo después de ti
6. nombres de variables claros y significativos
7. comentarios, pero sin exagerar
así, pero no del todo así: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
¿Existe algún tipo de literatura, por ejemplo?
En general, los problemas de diseño se solapan con el CAD y el TRIZ.
Dibujo en papel, me resulta más cómodo, a veces se gastan hasta 50 hojas hasta que surge una estructura clara. Se puede, por supuesto, utilizar editores especiales, pero cada uno de ellos es incómodo para mí (limitado), es imposible realizar un vuelo de la fantasía, en definitiva, ralentizan el trabajo.
El CAD no es exactamente lo mismo, pero es diseño asistido por ordenador.
Antes de escribir un programa, me enseñaron a hacer un esquema en papel, un lenguaje simplificado de algo, pero no estoy acostumbrado.
Por orden de llegada :). ¿Por qué no empiezas diciéndonos cómo es para ti?
Bueno, sospechaba que ese sería el caso... ))
De acuerdo, no tengo mucho que ocultar (en términos de estructuración), no tengo miedo a la discusión.
Pero no le recomiendo que asuma inmediatamente o critique apresuradamente - no asumo la "ejemplaridad" o incluso cualquier tipo de armonía en mis decisiones - en su masa, no están especialmente bien fundadas y generadas por los mismos factores "religiosos" - hábitos, "verdades de libro", artículos del foro, muestras de entrega de terminales estándar y otra basura agregada espontáneamente en la cabeza. Tengo algunos hallazgos, pero nada demasiado serio.
Para empezar, me gustaría proponer un par de términos convenientes, para que haya menos confusión (sospecho que habrá mucha).
1) Estructura física del proyecto: La organización de archivos, carpetas y otras entidades visibles en la vista "exterior" del proyecto.
2) Estructura lógica del proyecto: Organización de todas las cosas "internas" del software - variables, funciones, clases, protocolos, etc.
-----------------
La estructura física de mis proyectos mql es muy simple y primitiva. Intento hacerlo conscientemente, para reducir la confusión y minimizar las consecuencias de una posible confusión.
Por regla general (para uno de tamaño medio) se trata de un conjunto de archivos .mqh (ordenados en carpetas adecuadas) + un archivo mq5.
// Si el sistema es multihilo (por ejemplo, en el caso más simple, el Asesor Experto + indicadores) - entonces el número de archivos mq5 corresponde al número de programas en el proyecto.
Trato de no usar libs (.ex5) // Decisión muy controvertida, pero lo hago para minimizar los problemas en tiempo de ejecución.
--
Me abstendré de comentar las estructuras lógicas de los proyectos por el momento: el tema es muy grande y necesito tomar aliento... :)
El CAD no es exactamente lo mismo, pero es diseño asistido por ordenador.
Me enseñaron a esbozar un lenguaje simplificado de algo antes de escribir un programa, pero nunca me acostumbré a ello.
Intento visualizar el problema en su conjunto e identificar los principales objetos que lo componen.
Luego descompongo los objetos en sus componentes y busco las intersecciones en los componentes, y entonces aparecen los objetos antecesores.
Así es.
Si encuentro algunas entidades en el proyecto, que ya han sido encontradas, intento utilizar código antiguo y verificado.
Si se trata de diseño, basta con dejar de pelearse y adoptar el estilo MQ, pues con un solo clic de un botón de estilización todos tendrán el mismo estilo y todo será comprensible para todos.
Trato de no usar libs (.ex5). // Una solución muy controvertida, pero lo hago para minimizar los problemas de ejecución.
Intento visualizar la tarea como un todo, e identificar los principales objetos que la componen.
Luego divido los objetos en componentes, busco las intersecciones en los componentes y entonces aparecen los objetos antecesores.
Así es.
Si encuentro entidades objeto en un proyecto que he visto antes, intento incluir el antiguo código verificado.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Desde los programas más sencillos hasta los paquetes de software más complejos.
--
Insto a los profesionales a que apoyen este hilo.
Comprendo la inmensidad de un tema y su "carga religiosa"(*), y en consecuencia el posible conflicto caótico y potencial de una rama.
No obstante, pido apoyo, ya que todo el mundo puede beneficiarse: las ideas sensatas (con gran potencial) se encuentran a menudo en montones de basura, sólo hay que ser capaz de darse cuenta y, a tiempo, "hacerse con ellas".
----
(*) Por "carga religiosa" en este contexto entiendo el hecho de que las estructuras de los programas suelen ser construidas por los programadores sobre la base de hábitos, tradiciones y fuentes literarias, pero en absoluto sobre la base del sentido común y de las conveniencias reales esperadas para uno mismo y para otras personas (por ejemplo, futuros coautores).