¿Programación de la puesta de sol? - página 17

Nuevo comentario
 
Alexandr Andreev:

Por supuesto, es más fácil analizar el código conociendo el esquema que no conociendo el esquema.

Técnicamente sería incluso conveniente tener algún tipo de visualizador de código... especialmente si una no anula a la otra sino que la complementa.

Estoy de acuerdo.
 
Así que hemos llegado a la conclusión de que, aunque un caballo trabaje más en una granja colectiva, no sirve de nada sin un buen mozo de cuadra.
 
Pero hay que trabajar muy bien la usabilidad de todo ello. Y entender qué es lo que más se necesita. Es decir, no tiene sentido mostrar todo el lío de todas las interrelaciones, porque puede haber 20 herencias (en profundidad) del objeto con muchos anexos, recargas. Pero para ver dónde se menciona este objeto en las estructuras de los padres o dónde se inicializa si hemos escrito la inicialización detallada externa del objeto en el código analizado. O crear rápidamente una nueva entidad intermedia con la recarga de ciertas funciones y entender que no cometiste errores en las principales. Aunque normalmente esta tarea es gestionada por la búsqueda o el compilador
 
Alexandr Andreev:

Por supuesto, es más fácil analizar el código conociendo el esquema que no conociendo el esquema.

Técnicamente sería incluso conveniente tener algún tipo de visualizador de código... especialmente si una no anula a la otra sino que la complementa.

Pero, ¿por qué no hacer un visualizador de código completo que sea autosuficiente?

inventar un lenguaje gráfico para la representación del código, pensar en una buena navegación en él, decidir la prioridad de la información a mostrar (la información más importante requiere menos esfuerzos para mostrarla, la menos importante al contrario). También es necesario un análisis exhaustivo del código.

Seguro que no será fácil. De acuerdo, sé que es poco probable que llegue a aplicarse...

 
Aliaksandr Hryshyn:

¿Por qué no hacer un visualizador de código completo que sea autosuficiente?

Piensa en un lenguaje gráfico para la presentación del código, piensa en una buena navegación en él, decide la prioridad de la información mostrada (la información más importante requiere menos esfuerzo para mostrarla, la menos importante, al contrario). También es necesario un análisis exhaustivo del código.

Seguro que no será fácil. De acuerdo, sé que es poco probable que llegue a aplicarse...

Hay programas como el de diseño 3D para refinerías de petróleo. Tienen un diagrama de conexiones de tuberías. Para los ingenieros de procesos experimentados, es más fácil leer un montón de dibujos que un solo diagrama "visual", pero se acostumbran a ello después de un tiempo. Quiero decir que el código complicado seguirá siendo difícil de comprender en caso de visualización. Si se siguen todas las reglas, el código es bastante fácil de leer en su forma original.
 
Aliaksandr Hryshyn:

¿Por qué no hacer un visualizador de código completo que sea autosuficiente?

Piensa en un lenguaje gráfico para la representación del código, piensa en una buena navegación en él, decide la prioridad de la información mostrada (la información más importante requiere menos esfuerzo para mostrarla, la menos importante, al contrario). También es necesario un análisis exhaustivo del código.

Seguro que no será fácil. De acuerdo, sé que es poco probable que llegue a aplicarse...

Con la posibilidad de crear mis propias configuraciones con mi propio código y diseño visual, y usar plantillas de diseño visual ya hechas de otros, se llama pereza escribir un par de líneas)))

En programación, mi primer lugar de uso es probablemente la recarga de funciones. Pero en el código todo es muy breve de todos modos, escribir el nuevo nombre, escribir de dónde heredamos (y normalmente es una plantilla), escribir qué y con qué lo reemplazamos. ¡Eso es todo!

Creo que estas peculiaridades se convertirán rápidamente en una enorme biblioteca y será difícil recordarlas todas.

 
Реter Konow:
Sí, pero su dirección es correcta. La codificación es un canal estrecho para aprovechar el potencial del cerebro. El patrón descrito por el código se entiende cientos de veces más que el mismo patrón percibido por los ojos. Imagina la rotación de una volea que en cada círculo se ralentiza y aumenta ligeramente el ángulo de inclinación. Describe este proceso con fórmulas en código y fílmalo con una cámara. Mide el tiempo que tarda el programador en darse cuenta de que es lo mismo.

Cada uno tiene sus propios enfoques. Personalmente, encuentro diagramas sólo ligeramente molestos) me gusta mucho más el enfoque de la programación literaria de Donald Knuth (traducido en ruso como "literate" por alguna razón) y la forma en que se implementa, por ejemplo, en el lenguaje R (R Markdown).

Te equivocas al escribir sobre un hilandero) Es un problema de mecánica sin resolver - no hay una fórmula general para el movimiento (incluso si se descuida la fricción).

Literate programming - Wikipedia
Literate programming - Wikipedia
  • en.wikipedia.org
The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of...
 
Aleksey Nikolayev:

Te equivocas al escribir sobre un spinner) Es un problema de mecánica sin resolver - no hay una fórmula general para el movimiento (incluso si se ignora la fricción).

Y la piedra celta también es una voluta )

 
Aleksey Nikolayev:

...

Te equivocas al escribir sobre un spinner) Es un problema de mecánica sin resolver - no hay una fórmula general para el movimiento (incluso si se descuida la fricción).

De alguna manera, no pensé en ello. )

 
Aleksey Mavrin:
Existen programas informáticos como el de diseño 3D para refinerías de petróleo. Tienen un diagrama de conexiones de tuberías. Para un ingeniero de procesos experimentado es más fácil leer un montón de dibujos que un solo diagrama "visual", luego se acostumbra. Quiero decir que el código complicado seguirá siendo difícil de comprender en caso de visualización. Si se siguen todas las reglas, el código es bastante fácil de leer en su forma original.

Se pregunta por qué las dos visualizaciones de códigos que aparecen a continuación se perciben de forma diferente:

//+------------------------------------------------------------------+
//| Initialization of the indicators                                 |
//+------------------------------------------------------------------+
bool CSampleExpert::InitIndicators(void)
  {
//--- create MACD indicator
   if(m_handle_macd==INVALID_HANDLE)
      if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating MACD indicator");
         return(false);
        }
//--- create EMA indicator and add it to collection
   if(m_handle_ema==INVALID_HANDLE)
      if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating EMA indicator");
         return(false);
        }
//--- succeed
   return(true);
  }

A continuación, retire el "oropel" gráfico. Menos el color, menos la sangría (posicionamiento relativo).

//Inicialización de los indicadores

bool CSampleExpert::InitIndicators(void)

{

//crear el indicador MACD

if(m_handle_macd==INVALID_HANDLE)

if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error al crear el indicador MACD");

return(false);

}

//crear el indicador EMA y añadirlo a la colección

if(m_handle_ema==INVALID_HANDLE)

if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error al crear el indicador EMA");

return(false);

}

/superar

return(true);

}

La legibilidad es notablemente peor. Esto sugiere que la representación gráfica puede mejorar notablemente la legibilidad. No me refiero específicamente a los diagramas, podría haber muchas opciones.
1...1011121314151617181920212223
Nuevo comentario