Methode et beauté du code

[Backup]

Tiens, je me demande si on pourrait coder n'importe quelle routine sans goto. En tout cas, en ASM, il est OBLIGATOIRE !!!!!

en ASM il ne s'agit plus de "GOTO"
mais de "JMP"

on parle ici du Purebasic

je pense qu'on peut coder sans Goto, mais le Goto apporte une facilité bien pratique

[Robrock55]

J'avais lu quelque part que le goto/gosub pouvait être évité dans tous les cas si on gérait parfaitement les boucles.
Votre avis ? Personnellement j'ai testé, mais ca me fait un code hyper lourd :s Mais je ne suis qu'un vulgaire débutant, donc je ne gère surement pas parfaitement les boucles

[Ar-S]

J'aime les Goto même si j'en utilise le moins possible.

[Le psychopathe]

J'avais lu quelque part que le goto/gosub pouvait être évité dans tous les cas si on gérait parfaitement les boucles.
Votre avis ? Personnellement j'ai testé, mais ca me fait un code hyper lourd :s Mais je ne suis qu'un vulgaire débutant, donc je ne gère surement pas parfaitement les boucles

C'est juste une question de logique, il faut repensser son code de temps de temps
Mais je confirme le goto c'est à éviter dès que tu as un certain niveau.
@+

[dayvid]

Il parais que celui qui utilise sa dans c'est code est a bannir
enfin je veut dire que sa ne ce fait pas, bref va savoir pourquoi
sa doit pas faire très pros peut être mais n'empêche que c'est pratique

[Ar-S]

Les goto marchent bien, c'est juste qu'il faut les "éviter" car tu peux planter ton programme facilement si tu ne les gèrent pas bien.
Genre un goto intra/extra procédure et "pouuuf"

[GeBonet]

Bonsoir,
Au même titre, les gosub marchent très bien si on n'oublie pas les return et/ou qu'on gèrent bien si il y a divers points d'entrés.
On peut facilement assimilé une "sous routine machin" avec sont "return" à une "procédure machin"... La grande différence c'est que l'on ne peux pas vraiment isoler les variables... Rien de vraiment local, là on est vraiment dans une salle commune séparé par de simples rideaux et encore
Donc avoir une gestion très rigoureuse des variables. Et difficile de faire de la récursivité !

A mon humble avis, en fait d'organisation il y en a de multiple... Pouvant souvent être dépendante de ce que l'on développe !
Avec les IDE qui permettent de plier/déplier, de mettre des repères etc... Un très gros code en un bloc, a la Gnozal peut se faire et ne gène pas vraiment...
Pour moi la seule vraie règle à vraiment respecter c'est :
C'est de commenter ce que l'on fait. Pour sois même et pour les autres !
De rappeler l'objet de chaque "procedure", sous routine, grosse "Macro".
Un code DOIT pouvoir être repris plusieurs mois, voir même années après.
Même par un "successeur" qui devra comprendre les principes de ce que l'on a voulu faire !
Il ne doit pas devoir être nécessaire de toujours tout recommencer par manque de lisibilité !
Et c'est loin de ce que l'on fait habituellement, moi y compris, on se laisse entrainer par son code en négligeant cette partie là !

Et si il doit y avoir des règles de style alors pour moi, elle serais proche de celle-ci !
0- Entête avec :
-- Titre, version d'origine, dernière modification, date, auteurs....
1- Fixer l'endroit d’où l'on démarre si on utilise des répertoires liés à l'application dans le répertoire ou elle se trouve.
-- Style : Rep$=GetPathPart(ProgramFilename()) ; Répertoire actuel du programme.
---------- SetCurrentDirectory(Rep$) ; Permet de stabiliser le répertoire...
2- Énumérations
3- les structures
4- Les globales
5- Macros & Procédures standard
-
6- Les includes particulières et spécifiques
7- Déclaration des procédures spécifiques
-
8- Corps du programme
-
9- Les procédures spécifiques...

Étant entendus que tout ce qui se trouve de 0 à 5 peut faire partie d'un Include standard.
Pour pas se répéter et garder ses habitudes... Les particularités c'est pour de 6 à 9...

Mais évidement tout ça n'est qu'un avis comme un autre !

[Warkering]

Personnellement, j'utilise cette structure pour mes codes :

Code : Tout sélectionner

;Ici l'entête

;---- Constantes / Énumérations ----

Toutes les énumérations, ensuite les constantes.

;---- Variables ----

Déclarations des variables

;---- Déclarations ----

Déclarations des procédures, ...

;---- Initialisation ----

Charger les préférences, initialiser les variables, ouvrir la fenêtre, ...

;---- Programme / Boucle principale ----

On fait un gros Repeat, ...

;---- Fermeture ----

On ferme la fenêtre, fichiers, sauvegarde des préférences, ...

;---- Procédures ----

On fait nos procédure précédemment déclarées.

Bien sûr, quelque fois des modifications s'imposent, mais c'est grosso modo mon modèle.

Aussi, j'allonge normalement les traits d'unions après un commentaire de séparation jusqu'à la barre des 80 caractères, pour une meilleure visibilité. Mais encore une fois, c'est personnel.

[Emperor]

En ce qui me concerne, j'aime bien les fichiers courts, donc dans mes projets j'ai plusieurs fichiers.

Le principal, main.pb, se structure comme suit:

Code : Tout sélectionner

xincludefile "headers.pbi" ;lorsqu'il y a plusieurs headers, je les regroupe dans un fichier pour éviter d'avoir une longue liste
; et donc un long fichier main

; procédures d'initialisation
; ... ...

; déclarations de variables et de structures
; ... ...

; ouverture de la fenêtre principale (s'il y a lieu)
openMainWin()

; boucle d'événements
repeat
    EVENT = waitwindowevent()
    whichWindow = eventWindow() ; s'il y a plusieurs fenêtres
    select whichWindow
        case #main ;la fenêtre principale porte toujours l'handle #main
              select EVENT
                   case #kekchose
                   ; blablabla...
                   case #pb_event_closewindow
                       closewindow(#main)
                       break
              endselect
    endselect
forever

; fonctions de fermeture (s'il y a lieu)
end  

J'ai toujours un fichier enum.pbi qui contient les énumérations de constantes, la déclaration de constantes, de variables globales, macros et prototypes s'il y a lieu. Aussi un fichier main.pbi qui contient la déclaration de la procédure openMainWin et des fonctions reliées à la fenêtre principale.
Un fichier par fenêtre, dont chacun contient les fonctions en lien avec cette fenêtre.

De plus, j'évite les goto et gosub (habitude que j'ai pris car j'étais fatigué de voyager dans mon code spaghetti :p )

Voilà ça ressemble à ca. Malgré tout, je parviens à me retrouver dans ce bordel de fichiers hahaha

[graph100]

Pour ma part j'essaye de plus en plus de faire des codes lisibles avec une grande facilité, et extrêmement commentés.

J'utilise la technique du super oignon : mon code complètement refermé ne sort pas de ma fenêtre Purebasic : l'ascenseur n'est pas présent.
De plus, je dois pouvoir déplier deux parties de mon code très éloignées, mais en les affichant proche, avec le pliage, ce qui permet de travailler sur des endroits différents.

Quand je reprend mon code, la seule instruction visible est le END principal du programme, (je n'ai généralement qu'un seul point de fermeture du programme).
Tout le reste est les commentaires décrivant le contenu des pliages.

Chaque niveau de pliage est décrit par un commentaire qui explique quel est le but général du code plié.
Bien sur, plus les pliages descendent dans le code, plus l'explication est pointue. Je ne commente pas chaque ligne de code, car je pense que certains bloc de code ne peuvent
conduisent à une seule fonction qui est indiquée sur le pliage.

Sinon, pour ce qui est de l'organisation générale des déclarations et procédure, je fais comme pas mal de gens d'après ce que j'ai lu (je n'ai toujours pas compris l’intérêt de déclarer
les procédures en bas du code :

pour un programme fenestré :

Code : Tout sélectionner

;######################################
; programme : 
; version : 
; description : 
; détails :
; ajouts prévus :
; auteur :
;######################################

;{ structure et variables globales

;{ Divers plugin (image, audio, database)



;{ Procédures

   ;{ Déclaration si nécessaire


   ;{ procédures pour Fonction 1
   
   procédure nécessaire pour la principale
   
   procédure principale de la fonction
   
   ;}

   etc ...

;}



;{ lecture des passages de paramètre (si besoin)

;{ lecture des préférences (si besoin)



;{ Ouverture de la fenêtre principale + initialisation de certaines variables

;{ boucle principale

Repeat
	event = WaitWindowEvent(100)
	
	;{ event gadget
	
Until event = #PB_Event_CloseWindow

;}


;{ sauvegarde des paramètres et fermeture de la fenetre

End


;{ DATA SECTION

Les fenêtres :

Certains font des procédures spéciales pour déclarer les fenêtres, je trouve ça inutile et cela rend le code confus.

Généralement, je déclare ma fenêtre principale avant la boucle principale, puis je fais une procédure principale pour chaque nouvelle fenêtre créée,
avec la boucle gérant la fenêtre dans cette même procédure.
Lorsque j'utilise des gadgets statiques, je les nomme en utilisant le numéro de la fenêtre comme chiffre des centaines, ce qui permet de bien savoir ou on en est.


Les variables et constantes :

J'essaye de trouver le nom le plus descriptif possible pour les variables d'utilisation longues, comme :

Code : Tout sélectionner

DOSSIER_UTILISE_EN_DERNIER = GetPathPart(fichier$)

Je n'utilise les majuscules que comme moyen visuel de démarquer certaines variables globales.

variables utilisées dans les itérations : a, b, c, i, j, k
variables à usage très court : tmp_nom_d_utilisation


Pour ce qui est des Goto et Gosub, je ne crois pas en avoir utilisé un seul depuis mon tout début en programmation Purebasic, lorsque je ne connaissais pas toute les boucles.
Je n'en ai jamais ressenti le besoin. J'ai le sentiment que cela ne ferais qu'embrouiller mon code au possible


voila, je pense avoir pas trop mal décrit la présentation de mes derniers gros programmes structurés
parce que pour les bouts de code de test, c'est la joyeuse anarchie , je ne met en forme que si ça dépasse le stade du test et de l'idée

[blendman]

salut

Un truc important aussi et que je remarque souvent dans certains projets dont on peut avoir les sources, c'est que le rangement du dossier dans lequel on travaille est aussi important que l'organisation des fichiers et du code dans ces fichiers .

Pour les petits projets ou codes courts (- de 500 lignes), en général, je mets tout sur un unique fichier, et c'est organisé de cette manière :

Code : Tout sélectionner

; Infos

; constantes, enumeration
; structures
; variables, globales
; déclaration des procédures

; initialisation (loading des ressources (images..), openwindow, sprite..)
; Procédures et macros

repeat
forever/until...

; save preferences / ou autres
; datas 

Pour les gros projets (plus de 500 ou 1000 lignes), j'organise à peu près de la même manière sauf que je découpe en plusieurs fichiers.
J'ai un fichier principal qui s'appelle "nom_du_programme.pb" ou "main.pb" et il est seul dans le répertoire avec d'autres répertoires nécessaires pour le projet.
J'organise donc mon dossier de travail de la manière suivante, l'avantage c'est que l'on sait tout de suite quel est le fichier principal du projet et comment il est organisé (en l'ouvrant) :

Code : Tout sélectionner

nom_du_programme_version.exe
nom_du_programme.pb
dossier "data" (contenant les images, sons, textes..)
dossier "include" contenant les fichiers *.pb spécifiques au projet dont j'ai besoin en include
dossier "lib" contenant les autres fichiers *.pb  non spécifiques mais nécessaire au projet (fichier math.pb, fichier encrypt.pb, extsprite3D.pb, etc..)
dossier "doc" : contenant la documentation si besoin du projet.

Le fichier "nom_du_programme.pb" ou "main.pb" ressemble à ça :

Code : Tout sélectionner

; XIncludeFile "include\NOM_DU_PROJET_Infos.pb" ; en général, je commente cette ligne, car ce n'est que du texte informatif

XIncludeFile "include\NOM_DU_PROJET_enumeration.pb"
XIncludeFile "include\NOM_DU_PROJET_structures.pb"

XIncludeFile "include\NOM_DU_PROJET_variables.pb"
XIncludeFile "include\NOM_DU_PROJET_declare.pb"

; XIncludeFile "include\NOM_DU_PROJET_localisation.pb" ; dictionnaire pour la langue, en option
; XIncludeFile "lib\NOM_DU_PROJET_lib.pbi" ; les lib si j'en utilise, toujours les mêmes sur les autres projets.

XIncludeFile "include\NOM_DU_PROJET_init.pb" ; initkeyboard(), initsprite() usejpgdecoder()..
XIncludeFile "include\NOM_DU_PROJET_Images.pb" ; chargement des images si besoin (pour du logiciel avec imagegadgets
XIncludeFile "include\NOM_DU_PROJET_Window.pb" ; openwindow, createmenu, gadget..
XIncludeFile "include\NOM_DU_PROJET_Sprites.pb" ; loadsprite...
XIncludeFile "include\NOM_DU_PROJET_initialisation.pb" ; on initialise ce qui est nécessaire (la map pour un jeu, les brush ou le canvas pour un soft de dessin...

XIncludeFile "include\NOM_DU_PROJET_Procedure.pb" ; les procédures & macros classées par catégorie
XIncludeFile "include\NOM_DU_PROJET_event.pb" ; le code de la boucle principale avec une procedure event()

Repeat
  event()
ForEver/Until...

; XIncludeFile "include\NOM_DU_PROJET_close.pb" ; sauvegarde préférences...
; XIncludeFile "include\NOM_DU_PROJET_datas.pb" ; les datas

Voilà en gros comment j'essaie de m'organiser sur de gros projets.

Par exemple, je travaille sur 3 "gros" projets (plus de 2000 lignes de codes chacun, dont 3arks qui fait environ 6 à 7000 lignes (gulp)).
Alors, je suis obligé de m'organiser avec des "petits" fichiers, car sinon, ça devient vite très compliqué de s'y retrouver.

Enfin, j'essaie de créer des procédure ou constante ou variable avec des noms très facile à comprendre comme :

Code : Tout sélectionner

PaintWithBrush()
DeleteSprite()

#_S_sol ; constante utilisée pour un sprite (_S) de sol
#IG_previewBrush : constante utilisée pour un imagegadget (IG) qui montrera le preview du brush utilisé (dans animatoon)

J'essaie aussi d'organiser chaque fichier pour que ce soit à peu près bien rangé (je ne l'ai pas fait au début sur 3Arks et Ombre m'a dit que c'était le bazar, depuis, je fais gaffe ).

Par exemple, sur mon éditeur de map (3arks), j'ai rangé mon fichier procédure de la manière suivante :

Code : Tout sélectionner

;{ open, save, create, menu
;{ UI, Interface, mouse
;{ event
;{ draw 
;{ update

Voiloutch.

[mad]

Bonsoir, pour ma part voici mon modèle de base qui couvre les besoins de lisibilité.
En effet j'enlève par exemple dans le cadre d'une librairie ou d'un include la partie "Execution du code".

Vous aurez remarqué que les procédures sont en dessous de l’exécution du code. En effet je préfère question performance, que, une fois compilé, mon programme fasse des jump's (JMP) sur les fonctions que de lire d'abord tout les labels.

Autre point intéressant, c'est ce modèle est compatible avec l'onglet procédure situé sur la droite de l'IDE PB.

Bref voici mon modèle si je peux contribuer a quelques choses ...

Code : Tout sélectionner

;-----------------------------------------------------------------------------------
;
; Modèle PUREBASIC : 2.6
;
;-----------------------------------------------------------------------------------
;
;-
;
; Titre du programme  : 
;- Auteur              :  
;- Version             :  0
;- Date de création    :
;- Date de modification :
;
; Commentaires et remarques :
; ---------------------------
;
;
;
;
;
;-
;-----------------------------------------------------------------------------------

;-----------------------------------------------------------------------------------
;- Comportement et directives de compilation (pour le compilateur)
;-----------------------------------------------------------------------------------

EnableExplicit
;EnableASM

;-----------------------------------------------------------------------------------
;- Définition des Structures
;-----------------------------------------------------------------------------------

Structure renseignementApplication
    titreApplication.s
    versionApplication.s
    titreApplicationGlobal.s    
EndStructure

;-----------------------------------------------------------------------------------
;- Définition des constantes
;-----------------------------------------------------------------------------------
#MAD_modele_fichier = 2.6
#MAD_date_modele_fichier = "11/08/2010"

;-----------------------------------------------------------------------------------
;- Définition des variables
;-----------------------------------------------------------------------------------

Global infosApp.renseignementApplication
    infosApp\titreApplication = "ND-Faciliti XXXXXXXXXXXXXXXXXXXX"
    infosApp\versionApplication = Str(#PB_Editor_BuildCount) +"."+ Str(#PB_Editor_CompileCount)
    infosApp\titreApplicationGlobal =  infosApp\titreApplication + " v" +  infosApp\versionApplication

;-----------------------------------------------------------------------------------
;- Ajout de données (DATASECTION)
;-----------------------------------------------------------------------------------
DataSection

EndDataSection
;-----------------------------------------------------------------------------------
;- Déclaration des procédures
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- Ajout de modules
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- Définition des Objets
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- Appel de pile / Initialisation de module (initNetwork())
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- Execution du code
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- Définition des Fonctions
;-----------------------------------------------------------------------------------


;-----------------------------------------------------------------------------------
;- FIN
;-----------------------------------------------------------------------------------

[cdurand]

Bonjour,
Je me demandais s'il existait une options dans PureBasic que je n'aurais pas trouvée et qui permettrait de corriger le nom de mes variables après la frappe en y mettant les majuscules comme dans leur déclaration.

Par exemple lorsque je déclare

Global MonNumero.i

PB pourrait-il me corriger "monnumero" en "MonNumero" quand je le tape dans le code (comme dans Visual Studio par exemple)

Même chose pour les procédures.

C'est vrai qu'il y a la saisie automatique qui propose le nom des variables et des procédures, mais si je ne valide pas avec TAB, ma variable restera mal écrite, c'est moche.
Comme PB le fait pour les fonction qu'il connaît, je me dis qu'il doit pouvoir le faire pour le reste non ?

Merci.

Dudule.

[Backup]

Certain éditeur le font automatiquement , Japbe Par exemple

http://gnozal.ucoz.com/

[microdevweb]

Pour ma part,
Je suis Autodidacte mais j'ai travaillé en pro sur un très très gros Project. (Langage Windev Base de donnée 2500 Fichiers développeur 6 temps 18 mois pour une gérant +de 100.000 clients et du personnel de 3000 personnes).
Voici les directives des chefs de project
Les variables local tel-quel Nom ect... les globales gNom ect... le code très peux de I,R,Y,T des variables explicites dans sa langue Nom_Dossier, Nom_client sauf pour les coordonnée pixel x,y,z et les compteur N,R ect. Un max de procédures explicite par leur seul nom
si_client_existe() une fois le programme livré. Des path (en début de programme) de la version ce qui à été modifié supprimé ajouté On ne supprimais pas un code mais on le mettait en commentaire. Toutes les procédures ou fonctions (différence dans Windev) pouvant être utilisée plusieurs fois devaient être accompagnée d'une aide (leur utilité, les variables à passé en paramètre ect) Ainsi avant de faire une routine on regardais dans les routines si cela n'existai pas déjà.Voila une méthode Ne jamais oublier que demain on peux devoir revenir sur son code.... Et alors ... que voulais t'on donc faire.. Mieux vaux perdre 5 minutes à commenter que 1 journée à décrypter

Petite remarque: Dommage que dans pb on ne soit pas obliger de déclarer les variables (ou que comme dans certaines versions de Basic on puisse activer cette option)