Ma question est toute bête.
Dobro m'a déjà donné quelques pistes mais, comment vous gérez vos fichiers de programmes ?
pour ma part (je ne sais pas si c'est comme ça qu'il faut faire)
j'ai un fichier main.pb dans lequel je fais tout les includefile() et la boucle principal du programme
ensuite a côté j'ai un fichier part partie distinct
par exemple sound.pb (pour toute les procedures s'occupante du son) ou menu.pb pour ce qui gère le menu etc... J'ai facilement une bonne dizaine de fichier différent. Et cerain sont même partagé entre 2 programmes. Par exemple le Jeu et l'editeur.'main.pb et main_editor.pb)
Ensuite dans chaque fichier...je declare au debut les variables et les structures qui concerne la partit concerné, puis mes procédures/macro etc....
Et j'ai peu besoin de declarer mes fonctions.
Est ce une bonne méthode ? comme faites vous ?
Structure des fichiers dans un programme pb
je ne sais pas si on peut parler de bonne ou mauvaise méthode, mais simplement de façon de faire propre. Personnellement je 'n'utilise que très peu les includes, uniquement pour des sous programmes spécifiques. En fait je me retrouve presque toujours avec de gros fichiers *.pb car j'y colle tout. Ca me paraît plus simple à gérer. Ainsi je ne rispque pas d'oublier de charger un fichier avant de compiler. De là à savoir ce qui est le mieux...
Quand tous les glands seront tombés, les feuilles dispersées, la vigueur retombée... Dans la morne solitude, ancré au coeur de ses racines, c'est de sa force maturité qu'il renaîtra en pleine magnificence...Jacobus.
Dans mon cas le fichier Main.pb ressemble à ceci :
Le programme, qui est un énorme problème, est divisé en un large paquet de petits problèmes. Et chaque petit problème est contenu dans une structure de donnée et le problème est résolu à chaque fois comme s'il s'agissait d'un cas général, et ce même s'il s'agit d'un cas particulier.
Le premier IncludeFile est la définition des constantes et Data.
Les autres IncludeFile, 1 par structure, contiennent les macros et les procédures qui manipulent la structure en question. D'ordinaire les structures qui n'ont que des champs standard arrive en premier, celle qui ont des champs imbriqués en 2e et celle qui on des champs imbriqués dans champs imbriqués en 3e et ainsi de suite.
Le dernier IncludeFile est toujours la définition de la structure principale du programme avec toute les variables que le programme contient à l'exception des compteurs et de quelques variables locales. Il contient toute les macros et les procédures qui manipule la structure en plus des 3 procédures présentées plus haut avec 1 seul paramètre qui est un pointeur sur la structure qui porte le même nom que le programme et qui contient tout de manière imbriqué. Exemple de la structure principale de l'horloge Digital (Trucs et astuces) :
Un autre point important, ce qui est possible de faire dans le code mais qui est très mauvais à mon sens :
- 2 Instructions ou plus sur la même ligne.
- Variables Globales.
- Variables créé à la volée.
- Le chemin d'accès aux structures de donnée partout dans le code. (Donc pas de With/EndWith)
- Goto/Gosub/Return
- 2 ProcedureReturn ou plus par procedure (1 seul c'est suffisant)
- IncludeFile ou XIncludeFile en plein milieu d'un code.
Ce qui est toléré :
- Extends sur une structure ou une interface. (Dans mon cas je m'arrange pour que ça n'arrive pas)
Implicitement, les mots clé EnableExplicit et Define ne sont jamais utilisés.
Les avantages :
- C'est plus facile à écrire et surtout à débogguer
- C'est plus facile à modifier et à mettre à jour
- Le programme est plus rapide et plus constant dans exécution.
- On peut inclure une partie d'un programme dans un autre facilement.
Les inconvéniants :
- Comprendre le fonctionnement des pointeurs.
- Comprendre le fonctionnement des structures.
- Une auto-discipline de fer. (C'est le point le plus important !)
La technique en question s'appel : Programmation Basée Objet. Cette technique est à l'origine de la Programmation Orienté Objet. C'est de cette manière que les objets était programmés avant l'apparition des Classes en C. (L'apparition du C++, plutôt)
Et avant que les gens se mettent à me lancer des pierres : Ce standard n'engage que moi
Et je suis un des seuls dans toute la communauté PB à écrire le code avec ce standard. (TRÈS TRÈS TRÈS RIGIDE)
A+
Guimauve
Code : Tout sélectionner
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; Nom du projet : Le nom du projet ici
; Fichier : Source principal
; Version : 0.0.0
; Programmation : À compléter
; Programmé par : Guimauve
; Date : 13-03-2007
; Mise à jour : 13-03-2007
; Codé avec PureBasic V4.02
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
IncludeFile ""
IncludeFile ""
IncludeFile ""
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Routine de vérification au lancement du programme <<<<<
StartCheckup(...)
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Ouverture de la fenètre principale du programme <<<<<
FenetrePrincipale(...)
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< La gestion des évènements <<<<<
GestionEvenement(...)
; <<<<<<<<<<<<<<<<<<<<<<<<
; <<<< FIN DU FICHIER <<<<
; <<<<<<<<<<<<<<<<<<<<<<<<Le premier IncludeFile est la définition des constantes et Data.
Les autres IncludeFile, 1 par structure, contiennent les macros et les procédures qui manipulent la structure en question. D'ordinaire les structures qui n'ont que des champs standard arrive en premier, celle qui ont des champs imbriqués en 2e et celle qui on des champs imbriqués dans champs imbriqués en 3e et ainsi de suite.
Le dernier IncludeFile est toujours la définition de la structure principale du programme avec toute les variables que le programme contient à l'exception des compteurs et de quelques variables locales. Il contient toute les macros et les procédures qui manipule la structure en plus des 3 procédures présentées plus haut avec 1 seul paramètre qui est un pointeur sur la structure qui porte le même nom que le programme et qui contient tout de manière imbriqué. Exemple de la structure principale de l'horloge Digital (Trucs et astuces) :
Code : Tout sélectionner
Structure DigitalClock
ScreenW.w
ScreenH.w
Dial.Dial
Number.Number
DateText.DateText
LocalTime.LocalTime
StarField.StarField
EndStructure- 2 Instructions ou plus sur la même ligne.
- Variables Globales.
- Variables créé à la volée.
- Le chemin d'accès aux structures de donnée partout dans le code. (Donc pas de With/EndWith)
- Goto/Gosub/Return
- 2 ProcedureReturn ou plus par procedure (1 seul c'est suffisant)
- IncludeFile ou XIncludeFile en plein milieu d'un code.
Ce qui est toléré :
- Extends sur une structure ou une interface. (Dans mon cas je m'arrange pour que ça n'arrive pas)
Implicitement, les mots clé EnableExplicit et Define ne sont jamais utilisés.
Les avantages :
- C'est plus facile à écrire et surtout à débogguer
- C'est plus facile à modifier et à mettre à jour
- Le programme est plus rapide et plus constant dans exécution.
- On peut inclure une partie d'un programme dans un autre facilement.
Les inconvéniants :
- Comprendre le fonctionnement des pointeurs.
- Comprendre le fonctionnement des structures.
- Une auto-discipline de fer. (C'est le point le plus important !)
La technique en question s'appel : Programmation Basée Objet. Cette technique est à l'origine de la Programmation Orienté Objet. C'est de cette manière que les objets était programmés avant l'apparition des Classes en C. (L'apparition du C++, plutôt)
Et avant que les gens se mettent à me lancer des pierres : Ce standard n'engage que moi
Et je suis un des seuls dans toute la communauté PB à écrire le code avec ce standard. (TRÈS TRÈS TRÈS RIGIDE)
A+
Guimauve
-
Anonyme
On est pas mal à utilisé cette methode , Djes,Polux et moi même faison pareil ( j'aime le style de Djes 
) pour le dev de jeux.
un fichier main() qui charge les includes
un fichier pour les medias
un autre pour les procédures
un autre pour les structures et variable & constante
un autre pour des routines de bases ( maths )
Cette méthode simplifie pas mal la vie, exemple, lors du developpement d'un jeu quelquonque, les medias sont "libres", et , le jour on on veut un .pak, on a juste à remplacer le fichier des medias, et le tour et jouer. pas besoin de charcuté le fichier main() qui deviens vite un chantier inexploitable...
) pour le dev de jeux.un fichier main() qui charge les includes
un fichier pour les medias
un autre pour les procédures
un autre pour les structures et variable & constante
un autre pour des routines de bases ( maths )
Cette méthode simplifie pas mal la vie, exemple, lors du developpement d'un jeu quelquonque, les medias sont "libres", et , le jour on on veut un .pak, on a juste à remplacer le fichier des medias, et le tour et jouer. pas besoin de charcuté le fichier main() qui deviens vite un chantier inexploitable...
Quand je code propre ca a tendance à ressembler à ca
http://www.purebasic.fr/french/viewtopi ... 3535#53535
Et comme guimauve je crée un bloc de commentaires en début de fichier qui raconte la vide du code qu'y a en dessous comme les ajouts/modifications/supressions (dates + descrptions)
Dri
http://www.purebasic.fr/french/viewtopi ... 3535#53535
Et comme guimauve je crée un bloc de commentaires en début de fichier qui raconte la vide du code qu'y a en dessous comme les ajouts/modifications/supressions (dates + descrptions)
Dri
pour ma part j'evite les includes, qui sont autant d'oublis potentiel pour ma petite memoire 
(mais je reconnais que ça peut etre utile pour le partage d'une routine entre plusieurs prg ..)
et mon fichier prg ressemble a ça
completement a l'image de la programmation dites procedural,
qui a touché le Basic a l'époque du GFA de L'atari 520 !
avec utilisation de Sous-prg (label--return),en priorité (appelé "procedure "en GFA) ...
et les "procedures purebasic" comme on utilisait, les fonctions alors ....
(mais je reconnais que ça peut etre utile pour le partage d'une routine entre plusieurs prg ..
)et mon fichier prg ressemble a ça
completement a l'image de la programmation dites procedural,
qui a touché le Basic a l'époque du GFA de L'atari 520 !
avec utilisation de Sous-prg (label--return),en priorité (appelé "procedure "en GFA) ...
et les "procedures purebasic" comme on utilisait, les fonctions alors ....
Declarations
les procedures_declares
les constantes
les variables (et enumerations)
boucle principale
......
......
......
fin de boucle principale
END !!
Les Datas eventuel
.....
.....
....
fin des Datas eventuel
les sous-prg
....
....
....
....
fin des sous-prg
les procedures
.....
....
....
....
fin des procedures
