PureBasic

Ca dépend du type de programme à réaliser: Pour un programme avec une interface graphique, c'est assez difficile de ne pas utiliser de procédures. De même comme on ne sais pas dans quel ordre l'utilisateur va cliquer, on ne peut plus compter sur l'ordre de création des procédures. Donc dans ce cas, je fais une déclaration systématique de toute les procédures. Avec les panneau d'outil (l'explorateur de procédure) il est facile d'atteindre n'importe laquelle)
Mes habitudes de "vieux" (c..) de programmeur autodidacte élevé au Turbo Pascal 5.5, VB, Delphi, Perl et autre et autres bazar suivant font que j'utilise quelques "ficelles"

- Description du programme (ne pas oublier la date)
- Énumérations
- Constantes
- Variables globales
- Déclarations de procédures
- Procédures
- Boucle principale
- TODO liste
- Datas

La TODO liste est un gros bloc de commentaire dans lequel je met tout ce qui est à faire. Ensuite, je suffixe chaque ligne par un FAIT dès qu'un point est terminé. Quand il y a écrit FAIT devant toutes les lignes: une bière )

Quelques autres ficelles

- Les variables "poubelle" ont des noms explicites préfixées TMP_ ex: TMP_compteur
- Les variables et constantes ont un préfixe en majuscule, un "_ "et un suffixe en français (cela permet de les différencier facilement des mot-clés système)
- Les séparateur de champs sont collés comme en typo et suivi par un espace (ex: 10, 20, 30, "Hello")
- Les opérateur sont par contre encadrés par un espace ( a = a + 1)
- Si j'imbrique une fonction dans une autre, je l'écarte avec des espaces (a$ + Ltrim (b$) + " euros")
- Une seule instruction par ligne, sauf bloc de code éprouvé (for i = 1 to 10 : print i : next)
- Beaucoup de commentaires (de toute façon on n'imprime plus les codes source, et les espaces ne comptent pas pour le compilateur)
commentaire au dessus d'un bloc (avec plein de --- ) ou à la suite d'une ligne si c'est court
- Quand je remplace un bloc d'instruction par un nouveau 'mieux' je laisse un certain temps l'ancien bloc en commentaire au cas ou je doive y revenir.
- Deux caractères pour la tabulation, et pas de conversion en Tab (je laisse en espace)

J'utilise une foncte de caractère nomme DINA qui différencie bien le zéro et le O le un et le petit L etc

Voila ma contribution )

[Ajout]
Quand un bloc devient assez/trop long, j'ajoute au bloc de fermeture, un commentaire indiquant d'où il vient. Valable surtout quand il y a des imbrications. Dommage que l'EDI de PB ne puisse pas surligner les correspondances verticales, comme il le fait avec les ()

Petite habitude aussi, je met le mot-clé fermant immédiatement après le mot-clé ouvrant, puis je ramène le curseur entre les deux pour continuer la saisie du code. Ainsi je sais toujours où j'en suis dans les imbrications.

C'est d'ailleurs commode commode d'utiliser l'autocomplétion en tapant deux fois TAB, ce qui affiche immédiatement le mot-clé fermant s'il existe.

Moi j'ai changé 1000x ma façon de faire, alors... Et puis ça dépend du langage et du programmeur. Mais quand je reçois un code, j'aime bien le reformater à ma façon.


En ce qui concerne l'organisation du code:

Du Pascal j'avais gardé les procédures en haut du programme. Le Pascal oblige aussi à déclarer ses variables, c'est une bonne habitude que je n'utilise pas en BASIC.

De l'assembleur j'avais pris le truc de mettre les sous-routines (qui ne sont pas des procédures!) et les données en dessous du code principal; également l'utilisation des macros et des fichiers à inclure : comme le code assembleur peut rapidement devenir très long, même l'ascenseur devient inutilisable pour se déplacer! L'assembleur oblige également à déclarer ses variables (bien forcé pour savoir leur taille!). Je regrette l'assembleur 68000 qui est particulièrement clair et permet des trucs incroyables, grâce à de multiples modes d'adressage (je m'égare, désolé!).

Du développement web j'ai gardé la notion de projets, tout bien ranger dans un dossier principal, et des sous-dossiers par fonction, dont un pour le work in progress, avec les versions originales de tout, surtout les graphs.

J'ai souvent tenté de compiler les routines que j'utilise souvent dans des fichiers à inclure globaux pour tous les projets, genre tout ce qu'il faut pour les maths, les matrices, les chargements, etc. Mais on se retrouve toujours à faire des modifs, donc j'ai arrêté cette pratique qui m'obligeait à prendre en compte les cas particuliers dans un programme qui devrait être générique (et j'ai pas envie de faire des interfaces et du code spaghetti). Maintenant, je fais des includes spécifiques par projet, en me basant sur les précédents.


En ce qui concerne le formatage du code, je change parfois, en m'inspirant des pratiques des uns et des autres :

Il faut aérer! J'ai horreur des codes compacts qui ressemblent à des briques et où l'on n'arrive pas à distinguer les différentes parties du programme. Il faut mettre des séparations et ainsi on voit qu'il faut faire des regroupements. En gros ça impose du rangement, du classement! Le code source en ASCII ne prend pas de place, il ne faut donc pas hésiter à utiliser des grosses séparations bien claires, genre des "---------------" ou des "*****************".

Il faut utiliser les tabulations ou les espaces pour savoir le niveau d'imbrication du code.

Il faut commenter, surtout ce qui pourra paraître obscur dans quelques temps. Quelquefois, une simple opération peut devenir un vrai casse-tête en fonction du contexte. Avec l'expérience, on fait parfois des raccourcis qui sur le coup sont évidents et sur lesquels on bute quand on doit relire le code six mois plus tard.

Pour les noms de variables, comme Dobro j'utilise des variables temporaires : pour les boucles c'est souvent le "u" pour les entiers, le i, j, k, l, ou d'autres en fonction du contexte, genre x et y, ou u et v, a, b, c, d. Les noms de variables doivent être explicites, mais pas idiots. Je mets toujours mes noms de variables en minuscules, et mes labels et mes constantes en majuscules (ça me vient de l'assembleur). Ca me saoule, même si c'est plus joli, de mettre les premières lettres en majuscule, et aussi d'indiquer le type de la variable dans le nom. Normalement je sais le type des variables que j'utilise.

Pour les structures, j'utilise souvent un type à l'infinitif, et le même nom pour les tableaux et les listes mais au pluriel.

Dans les gros projets, je déclare les variables, les structures, les tableaux dans des fichiers à part. En gros, quand je dépasse une certaine taille, je scinde et procède à des regroupements.

J'essaye de limiter les imbrications de boucles. C'est mauvais pour tout. Il faut toujours essayer de "déplier" ses boucles.

Ensuite il y a les petits trucs pour embellir le code. Par exemple, je trouve plus "beau" de mettre un espace après chaque virgule.

Il y a encore beaucoup de choses. De toutes façons il suffit de voir quelques sources de gros projets pour voir que les pratiques finissent par se ressembler, mais à chacun de se trouver ses habitudes.

Ce topic deviens un recueil de bon trucs

comme un CODEX

j'ai presqu'envie de passer ce Topic en post-it , et le mettre en rubrique Débutants , pour le coup ...

Dobro a écrit :Ce topic deviens un recueil de bon trucs

comme un CODEX

j'ai presqu'envie de passer ce Topic en post-it , et le mettre en rubrique Débutants , pour le coup ...

C'est une bonne idée, Mr Dobro.

et je dis Merci

Le Soldat Inconnu a écrit :pour les routines, j'ai une base de données de fonction, et je fais du copier coller des fonction dont j'ai besoin

C'est pas vrai ?
j'me doute bien que tu copie/colles , sinon tu serais un mazo ^^
n'empêche que même si tu codes avec des gants de cuisines , tu nous sort de jolie soft et de belle routine

Cpl.Bator a écrit :n'empêche que même si tu codes avec des gants de cuisines , tu nous sort de jolie soft et de belle routine

Moi j'aurai dit a la barbare :p, mais c'est vrai que au vue de la méthode et des résultats on ne peut qu'applaudir.

Et bien moi ça ressemble à quelque chose du genre :

1. Les fonctions en vrac qui devraient être compilées en librairie avec TailBite. Fichier *.pbi
2. Le fichier de constantes
3. Les structures simples. Les structures avec uniquement des champs de type standards simple. (Byte, Caracter, Word, Long, Integer, Float, Quad, Double, String) Incluant les macros et/ou procédures de manipulation de ces structures.
4. Les structures Complexes. Les structures dont les champs sont mélangés avec des types standards simple et/ou les structures simples. Incluant les macros et/ou procédures de manipulation de ces structures.
5. La structure qui porte le nom du programme avec toutes les variables que le programme doit garder en mémoire pour travailler.

Le fichier principal (Nom du programme - Main.pb) ressemble à ceci :
Aucune variable globale, aucune déclaration de procédure. 1 seule structure qui contient toute les données du programme.

Voilà, c'est ma méthode de faire.

A+
Guimauve

Petit astuce pour lire la syntaxe d'une structure:
Se traduit par:

«Si la taille du voisin du cousin de Machin est supérieure à 160 alors on lui change son costar»

Salut à tous,

Que d'info dans ce sujet !
Bravo pour cette initiative.


[img]http://image_vrac.ecligne.net/entete_pure.jpg[/img]

J'aime décomposer en plusieurs fichier mon programme, cela me permet d'accéder très vite à la partie voulue.

Ici c'est la base d'un nouveau projet. On y trouve :
1_Prog : le programme principale
2_Variable_global : Les variables globales
3_Fenetre : les actions à faire suivant les zones réactives (je sais je ne suis pas clair)
4_Procedure : Toutes les procedures propres au programme
Fenetre_base : la definition de mes fenetres, les constantes, les gadgets
Fonction_Fenetre_base : les procedures communes à tous mes programmes (concernant les fenetre)
Fonction_base : Toutes les fonctions de base que j'utilise dans tous mes programmes (avant je travaillais avec des lib mais j'ai vite trouvé cela lourd)
Fonction_fenetre : Tiens c'est maintenant la même chose que Fonction_fenetre_base (l'évolution )

meme si les personnes ne changeront rien a leurs façon de programmer, il reste une solution.

avec the colorer de Dobro en plus d'ajouté de la couleur au code, et bien de le ranger toujours de la même façon.
comme sa quand ont poste nos codes ils ont de la couleurs et seront toujours bien ranger.
bien sur sa reste un plie a prendre

bonne ou mauvaise idée ?






@++

venom a écrit : avec the colorer de Dobro en plus d'ajouté de la couleur au code, et bien de le ranger toujours de la même façon.

que veut tu dire par "Ranger de la meme façon" ??

colorer se contente de coloré le code, meme si celui-ci est un code Spaguetti

et bien j'ai peut être mal compris le sujet mais je penser qu'ici ont parler de normalisé un code écrit en purebasic.

comme colorer permet de poster des couleurs sur du code phpbb en meme temps il remet en forme ce dernier

si je suis a coté c'est pas grave la fatigue est présente en ce moment





@++

venom a écrit : comme colorer permet de poster des couleurs sur du code phpbb en meme temps il remet en forme ce dernier

, il ne s'agit pas ici de parler d'indentation du code
mais d'astuces utilisées par chacun, pour structurer son code

c'est le coté Architectural qui est mis en avant ici ,

par exemple ceux qui preferent mettre les procedures au debut du code
pour avoir le plaisir de Scroller pendant 4 heures , leur longues liste de procedure avant d'atteindre la boucle principale


oui je sais les Signés c'est pas fait seulement pour la déco

ok d'accord je comprend mieux
oublier mes autres postes alors





@++

Salut, je n'ais pas parcourru de A à Z ce topic mais j'ais compris Grosso Modo de quoi ça parle

et éffectivement il faut créer une Norme de présentation

Mais faudrais pas s'étonner quant il n'y aura plus de code sur ce forum

il est donc prudent de lancer un sondage au préalable, et si il y a "une allimité" (c'est bien écrit ) mettre au point une forme de présentation dite "universelle"


pardonné moi si je ne suis pas dans le sujet