Programmation du coucher du soleil ? - page 17

[Реter Konow]

Alexandr Andreev:

Bien sûr, il est plus facile d'analyser le code en connaissant le schéma que de ne pas le connaître.

Techniquement, il serait même pratique d'avoir une sorte de visualisateur de code... surtout si l'un n'annule pas l'autre mais le complète.

Je suis d'accord.

[Konstantin Nikitin]

Nous sommes donc arrivés à la conclusion que, même si un cheval travaille davantage dans une ferme collective, il n'est d'aucune utilité sans un bon panseur.

[Alexandr Andreev]

Mais il faut bien réfléchir à la facilité d'utilisation de tout cela. Et comprendre ce qui est le plus souvent nécessaire. C'est-à-dire que cela n'a pas de sens de montrer tout le désordre de toutes les interrelations, parce qu'il peut y avoir 20 héritages (en profondeur) de l'objet avec de nombreux attachements, rechargements. Mais pour voir où cet objet est mentionné dans les structures parentes ou où il est initialisé si nous avons une initialisation externe détaillée de l'objet dans le code analysé. Ou bien créer rapidement une nouvelle entité intermédiaire avec le rechargement de certaines fonctions et comprendre que vous n'avez pas fait d'erreurs dans celles du parent. Bien qu'habituellement cette tâche soit gérée par la recherche ou le compilateur

[Aliaksandr Hryshyn]

Alexandr Andreev:

Bien sûr, il est plus facile d'analyser le code en connaissant le schéma que de ne pas le connaître.

Techniquement, il serait même pratique d'avoir une sorte de visualisateur de code... surtout si l'un n'annule pas l'autre mais le complète.

Mais pourquoi ne pas créer un visualiseur de code à part entière qui se suffirait à lui-même ?

Pensez à un langage graphique agréable pour la représentation du code, à une bonne navigation dans celui-ci, décidez de la priorité des informations à afficher (les informations plus importantes nécessitent moins d'efforts pour les afficher, les moins importantes au contraire). Vous devez également procéder à une analyse approfondie du code.

Ce ne sera pas facile, c'est sûr. OK, je sais qu'il est peu probable que cela soit mis en oeuvre...

[Aleksey Mavrin]

Aliaksandr Hryshyn:

Pourquoi ne pas créer un visualiseur de code à part entière qui se suffise à lui-même ?

Pensez à un langage graphique pour la représentation du code, pensez à une bonne navigation dans celui-ci, décidez de la priorité des informations affichées (les informations plus importantes demandent moins d'effort d'affichage, les moins importantes - au contraire). Vous devez également procéder à une analyse approfondie du code.

Ce ne sera pas facile. OK, je sais qu'il est peu probable que cela se concrétise...

Il existe des programmes comme la conception 3D pour les raffineries de pétrole. Ils disposent d'un schéma des raccords de tuyauterie. Pour les ingénieurs de procédés expérimentés, il est plus facile de lire une pile de dessins qu'un seul diagramme "visuel", mais ils s'y habituent au bout d'un moment. Je veux dire que le code compliqué sera toujours difficile à comprendre en cas de visualisation. Si vous suivez toutes les règles, le code est assez facile à lire dans sa forme originale.

[Alexandr Andreev]

Aliaksandr Hryshyn:

Pourquoi ne pas créer un visualiseur de code à part entière qui se suffise à lui-même ?

Pensez à un langage graphique pour la représentation du code, pensez à une bonne navigation dans celui-ci, décidez de la priorité des informations à afficher (les informations plus importantes demandent moins d'effort d'affichage, les moins importantes - au contraire). Vous devez également procéder à une analyse approfondie du code.

Ce ne sera pas facile. Ok, je sais qu'il est peu probable que cela soit mis en oeuvre...

Avec la possibilité de créer mes propres paramètres avec mon propre code et ma propre conception visuelle, et d'utiliser les modèles de conception visuelle prêts à l'emploi des autres, cela s'appelle de la paresse d'écrire quelques lignes))).

En programmation, le premier endroit que j'utilise est probablement le rechargement des fonctions. Mais dans le code, tout est très bref de toute façon, on écrit le nouveau nom, on écrit d'où on hérite (et en général c'est un template), on écrit ce qu'on remplace et par quoi on le remplace. C'est tout !

Je pense que ces bizarreries vont rapidement devenir une énorme bibliothèque et qu'il sera difficile de s'en souvenir.

[Aleksey Nikolayev]

Реter Konow:
Oui, mais sa direction est correcte. Le codage est une voie étroite pour exploiter le potentiel du cerveau. Le motif décrit par le code est compris des centaines de fois plus longtemps que le même motif perçu par les yeux. Imaginez la rotation d'une volée qui, à chaque cercle, ralentit et augmente légèrement l'angle d'inclinaison. Décrire ce processus avec des formules en code et le filmer sur une caméra. Mesurez le temps qu'il faut au programmeur pour se rendre compte que c'est la même chose.

Chacun a sa propre approche. Personnellement, je trouve que les diagrammes ne sont que légèrement ennuyeux) J'aime beaucoup plus l'approche de la programmation littéraire de Donald Knuth (traduite en russe par "lettrée" pour une raison quelconque) et la façon dont elle est mise en œuvre, par exemple, dans le langage R (R Markdown).

C'est un problème de mécanique non résolu - il n'existe pas de formule générale pour le mouvement (même si l'on néglige la friction).

[TheXpert]

Aleksey Nikolayev:

C'est un problème de mécanique non résolu - il n'y a pas de formule générale pour le mouvement (même si l'on ignore la friction).

Et la pierre celtique est aussi une volute ;)

[Реter Konow]

Aleksey Nikolayev:

...

C'est un problème de mécanique non résolu - il n'y a pas de formule générale pour le mouvement (même si l'on néglige la friction).

Je n'y ai pas pensé. )

[Aliaksandr Hryshyn]

Aleksey Mavrin:
Il existe des logiciels tels que la conception 3D pour les raffineries de pétrole. Ils disposent d'un schéma des raccords de tuyauterie. Il est plus facile pour un ingénieur des procédés expérimenté de lire une pile de dessins qu'un seul diagramme "visuel", puis il s'y habitue. Je veux dire que le code compliqué sera toujours difficile à comprendre en cas de visualisation. Si vous suivez toutes les règles, le code est assez facile à lire dans sa forme originale.

Vous vous demandez pourquoi les deux affichages de code ci-dessous sont perçus différemment :

//+------------------------------------------------------------------+
//| 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);
  }

Ensuite, enlevez le "tinsel" graphique. Moins la couleur, moins l'indentation (positionnement relatif).

//Initialisation des indicateurs

bool CSampleExpert::InitIndicators(void)

{

//créer un indicateur MACD

si(m_handle_macd==INVALID_HANDLE)

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

{

printf("Erreur lors de la création de l'indicateur MACD") ;

retour (faux) ;

}

//créer l'indicateur EMA et l'ajouter à la collection

si(m_handle_ema==INVALID_HANDLE)

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

{

printf("Erreur lors de la création de l'indicateur EMA") ;

retour (faux) ;

}

/succès

retour (vrai) ;

}

La lisibilité est nettement moins bonne. Cela suggère que la représentation graphique peut améliorer sensiblement la lisibilité. Je ne parle pas spécifiquement des diagrammes, il pourrait y avoir de nombreuses options.