From 5d9e70b03d77bb3732bc2a65a47f3f2fa5ebed6f Mon Sep 17 00:00:00 2001 From: Jean Sirmai Date: Tue, 9 Jul 2024 05:00:44 +0200 Subject: [PATCH] =?UTF-8?q?r=C3=A9flexions=20=C3=A0=205h=20du=20matin=20?= =?UTF-8?q?=20(voir=20main.c)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- include/parse.h | 3 --- src/main.c | 67 ++++++++++++++++++++++++++++++++++++++----------- 2 files changed, 52 insertions(+), 18 deletions(-) diff --git a/include/parse.h b/include/parse.h index dc0e09f..d12d8a4 100644 --- a/include/parse.h +++ b/include/parse.h @@ -41,9 +41,6 @@ bool model_get_next_arrow(struct arrow_t *new_arrow, char dimension); long model_get_state_arrows_count(const char *state_id); -bool model_get_next_arrow(struct arrow_t *new_arrow, - const char *state_id, - char dimension); diff --git a/src/main.c b/src/main.c index 40ef644..2d680fe 100644 --- a/src/main.c +++ b/src/main.c @@ -32,15 +32,51 @@ #include "../include/callbacks.h" -/* https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel - * https://en.wikipedia.org/wiki/Multitier_architecture +/* La question < Comment renommer les fonctions ? > + * dépend d'au moins deux questions et d'au moins deux règles : * - * Quel modèle pour l'organisation du client gem-graph ? * - * Quelles structures apparaissent bien individualisables dès aujourd'hui ? - * Quelles structures (encore à peine ébauchées) ont un développement prévisible ? - * Quelles interfaces peut-on prévoir, vers quels modules à venir, - * afin de garder un code aussi simple et adaptable que possible ? + * > Quel modèle pour l'organisation du client gem-graph ? + * https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel + * https://en.wikipedia.org/wiki/Multitier_architecture + * + * > Quelles structures sont suffisamment individualisées dès aujourd'hui, + * ou ont un développement suffisamment prévisible (modules, interfaces) + * pour qu'on puisse décider de les renommer + * (et comment classer et nommer les autres) ? + * + * + * > Ici, les noms doivent être "human-readable" ET "machine-readable. + * + * > Toute fonction utilisée par un autre module doit + * - commencer D'ABORD par le nom de ce module, + * - indiquer ENSUITE sa nature (get, set, print,...) + * - et ENFIN son objet (STATE, RULES,...) + * + * ex: widget_get_RULES_page() + * automat_set_STATE_RULES_DATA() + * on_save_CURRENT_MODEL_before_editing() + * model_get_DIM_VALUE() + * model_get_NEXT_ARROW() + * + * 'on_' == callback ('on_' est un alias de 'callbacks') + * 'model' == parse ('model' est un alias de 'parse') + * + * + * > selon ces règles, get_user_tree_model() + * devrait être renommé : tree_get_USER_TREE_MODEL() + * + * > si, comme c'est prévisible, 'state.c' devient un dossier contenant : + * les fichiers 'controls.c', 'camera.c', 'contrasts.c' et d'autres + * alors, get_ZOOM_box() + * devrait être renommé : state_camera_get_ZOOM_box() + * + * + * >>> nous devons nous choisir des règles de renommage des fonctions qui + * soient conformes aux 'bonnes pratiques' du 'génie logiciel' + * ET soient les plus pertinentes possibles pour notre cas particulier. + * + * (2024-07-09 5h00) * * * 1) Les structures hiérarchiques. @@ -90,7 +126,8 @@ * * Tous les callbacks sont dans le fichier 'src/callbacks.c' * et leur nom commence par: 'on_' - * (aucun autre nom de fonction ne commence par 'on_'). + * (aucun autre nom de fonction ne commence par 'on_') ('on_' est un alias). + * * S'ils deviennent trop nombreux, ils seront répartis * dans des fichiers regroupés dans un dossier: 'src/callbacks.c'. * (ou 'src/callbacks' ?) @@ -125,8 +162,8 @@ * * * Les préférences des utilisateurs devront être prises en compte. - * leur recueil et leur mémorisation seront probablement des fonctions centrales - * mais leur mise en oeuvre suivra probalement la voie hiérarchique. + * Leur recueil et leur mémorisation seront probablement des fonctions centrales + * mais leur mise en oeuvre suivra probalement les voies hiérarchiques. * * On peut prévoir des préférences concernant l'apparence des widgets, * les traductions, les 'disabilities'; etc. @@ -137,15 +174,15 @@ * Comment optimiser ? * ------------------- * - * Modularité - * (définir les interfaces entre modules tôt et précisément) - * Commenter, faire tester (pas trop tôt, pas trop tard) - * Tests graphiques, tests unaires, profiling + * Modularité <> définir les interfaces entre modules tôt et précisément + * Commenter <> faire tester (pas trop tôt, pas trop tard) + * Tester <> tests graphiques, unaires, profiling... */ /* L I S T E D E S F I C H I E R S A R E N O M M E R */ +/* (en cours, 2024-07-09 5h00) */ /* Tous les callbacks sont dans le fichier 'src/callbacks.c' * et leur nom commence par: 'on_' @@ -177,7 +214,7 @@ * * * - * (en cours - 2024-07-08 7h50) + * (en cours - 2024-07-09 5h00) */