Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc.
Règles de structure. Le contenu est secondaire, la structure est primaire.
Mon "Panel" a la structure la plus simple : Événement -> Manipulation
Les événements sont également simples : pressions sur des boutons, sélections de listes, sélections de calendriers, mouvements de souris, etc.
Un problème typique pour commencer à concevoir : comment organiser (structurer) la gestion des événements dans un programme de sorte qu'il (le programme) puisse être développé plus avant et que, dans le même temps, la reprise de ce qui a déjà été fait soit minimale.
Voulez-vous discuter des options ?
Depuis la branche"bugs, bugs, questions" :
Un problème très typique du début de la conception : comment organiser (structurer) le traitement des événements dans un programme de façon à pouvoir le développer et en même temps refaire ce qui a déjà été fait avec un minimum d'effort.
Voulez-vous discuter des options ?
Y a-t-il de la littérature par exemple ?
En général, les questions de conception se recoupent avec la CAO et TRIZ.
Je dessine sur du papier, c'est plus pratique pour moi, parfois il faut jusqu'à 50 feuilles pour obtenir une structure claire. Peut certainement dans spets.editors, mais chacun d'eux pour moi inconfortable (limitée), impossible de réaliser une envolée de fantaisie, en bref, ralentir le travail.
- ru.wikipedia.org
J'ai l'option la plus simple
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
qu'entend-on par structure ?
ZS : On m'a appris de cette façon :
1) Tout ce que vous pouvez faire dans une fonction se trouve dans une fonction.
2. le goto est un péché
3. toutes les conditions doivent être minimales et il ne doit pas y avoir de chevauchement dans une même condition
4. 3. mettre en retrait
5. Il faut écrire de manière à ce que les autres puissent le lire après vous.
6. des noms de variables clairs et significatifs
7. des commentaires, mais n'en faites pas trop
comme ça, mais pas tout à fait comme ça : http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
Y a-t-il de la littérature par exemple ?
En général, les questions de conception se recoupent avec la CAO et TRIZ.
Je dessine sur papier, c'est plus pratique pour moi, parfois jusqu'à 50 feuilles sont passées jusqu'à ce qu'une structure claire émerge. Vous pouvez, bien sûr, utiliser des éditeurs spéciaux, mais chacun d'entre eux est peu pratique pour moi (limité), il est impossible de réaliser une envolée, bref ils ralentissent le travail.
La CAO n'est pas exactement la même chose, mais il s'agit de la conception assistée par ordinateur.
Avant d'écrire un programme, on m'a appris à faire un schéma sur papier, un langage algo simplifié, mais je n'en ai pas l'habitude.
Premier arrivé, premier servi :). Pourquoi ne pas commencer par nous dire à quoi cela ressemble pour vous ?
Eh bien, je me doutais que ce serait le cas... ))
Bon, je n'ai pas grand-chose à cacher (en termes de structuration), je n'ai pas peur de la discussion.
Mais je ne vous recommande pas de supposer immédiatement ou de critiquer hâtivement - je ne suppose pas que mes décisions soient "exemplaires" ou même d'une quelconque harmonie - dans leur masse, elles ne sont pas spécialement fondées et générées par les mêmes facteurs "religieux" - habitudes, "vérités livresques", articles de forum, échantillons de livraison terminale standard et autres déchets agrégés spontanément dans la tête. J'ai quelques constatations, mais rien de trop grave.
Pour commencer, j'aimerais proposer quelques termes pratiques, afin qu'il y ait moins de confusion (je soupçonne qu'il y en aura beaucoup).
1) Structure physique du projet : l'organisation des fichiers, des dossiers et des autres entités visibles de l'extérieur du projet.
2) Structure logique du projet : organisation de tous les éléments "internes" du logiciel - variables, fonctions, classes, protocoles, etc.
-----------------
La structure physique de mes projets mql est très simple et primitive. J'essaie consciemment de le faire, afin de réduire la confusion et de minimiser les conséquences d'une éventuelle confusion.
En règle générale (pour une entreprise de taille moyenne), il s'agit d'un ensemble de fichiers .mqh (classés dans des dossiers appropriés) + un fichier mq5.
// Si le système est multithread (par exemple, dans le cas le plus simple, le conseiller expert + indicateurs) - alors le nombre de fichiers mq5 correspond au nombre de programmes dans le projet.
J'essaie de ne pas utiliser de librairies (.ex5). // Décision très controversée, mais je le fais pour minimiser les problèmes d'exécution.
--
Je m'abstiendrai pour l'instant de tout commentaire sur les structures logiques des projets - le sujet est très vaste et j'ai besoin de reprendre mon souffle... :)
La CAO n'est pas tout à fait la même chose, mais il s'agit de la conception assistée par ordinateur.
On m'a appris à esquisser un langage d'algo simplifié avant d'écrire un programme, mais je n'en ai jamais pris l'habitude.
J'essaie de visualiser le problème dans son ensemble et d'identifier les principaux objets qui le composent.
Ensuite, je décompose les objets en leurs composants et je recherche les intersections dans les composants, puis les objets ancêtres apparaissent.
C'est comme ça.
Si je trouve des entités dans le projet, qui ont déjà été rencontrées, j'essaie d'utiliser un ancien code vérifié.
Si vous parlez de design, arrêtez de vous battre et adoptez le style MQ. En un clic sur un bouton de stylisme, vous aurez tous le même style et tout sera compréhensible pour tout le monde.
J'essaie de ne pas utiliser les librairies (.ex5). // Une solution très controversée, mais je le fais pour minimiser les problèmes d'exécution.
J'essaie de visualiser la tâche dans son ensemble et d'identifier les principaux objets qui la composent.
Ensuite, je divise les objets en composants, je recherche les intersections dans les composants, puis les objets ancêtres apparaissent.
C'est comme ça.
Si je trouve dans un projet des entités objets que j'ai déjà vues, j'essaie d'inclure l'ancien code vérifié.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Des programmes les plus simples aux logiciels les plus complexes.
--
J'invite les professionnels à soutenir ce fil.
Je comprends l'immensité d'un thème et sa "charge religieuse"(*), et par conséquent le caractère chaotique et potentiellement conflictuel d'une branche.
Je demande néanmoins un soutien, car tout le monde peut en bénéficier - les idées sensées (à fort potentiel) se trouvent souvent dans les tas d'ordures, il suffit d'être capable de les remarquer et de s'en "emparer" à temps.
----
(*) Par "chargé religieusement" dans ce contexte, j'entends le fait que les structures des programmes sont souvent construites par les programmeurs sur la base d'habitudes, de traditions et de sources littéraires, mais pas du tout sur la base du bon sens et des commodités réelles attendues pour soi-même et pour les autres (par exemple, les futurs co-auteurs).