réflexions à 5h du matin (voir main.c)
This commit is contained in:
parent
5c18d2416e
commit
5d9e70b03d
GPG Key ID:
FB3115C340E057E3
|
|
@ -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);
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
67
src/main.c
67
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)
|
||||
*/
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue