Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
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.
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...
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...
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.
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).
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 ;)
...
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é. )
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 :
Ensuite, enlevez le "tinsel" graphique. Moins la couleur, moins l'indentation (positionnement relatif).
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.