Ordre et méthode

ArseneDeGallium Messages postés 6 Date d'inscription dimanche 4 août 2002 Statut Membre Dernière intervention 12 avril 2005 - 11 avril 2005 à 16:18
ArseneDeGallium Messages postés 6 Date d'inscription dimanche 4 août 2002 Statut Membre Dernière intervention 12 avril 2005 - 12 avril 2005 à 08:37
Bonjour


En regardant les sources publiées sur ce site, je m’aperçois que beaucoup d’entre vous oubli que programmer c’est aussi de l’ordre et de la méthode. Certes la plupart des programmes fonctionnent mais sont totalement incompréhensible. L’objectif de ce site n’est-il pas d’expliquer aux débutants les joies de la programmation et aux autres les astuces et les algorithmes souvent étonnants que vous avez patiemment concocté.


Lorsque l’on voit ceci :


For i = 1 To 6


For j 1 To 8<?xml:namespace prefix o ns = "urn:schemas-microsoft-com:office:office" />


cl = Val(Mid(chaine, i * 8 - 8 + j, 1))


If j / 2 <> Int(j / 2) Then


fa(i, cl) = c(i, j)


Else: co(i, cl) = c(i, j)


End If


Next


Next


Bonjour la lisibilité !


alors que :


For i= 1 To 6


For j= 1 To 8


Cotel= Val(Mid(chaine, i * 8 - 8 + j, 1))


If j / 2 <> Int(j / 2) Then


face(i, cl) = c(i, j)


Else


coin(i, cl) = c(i, j)


End If


Next j


Next i


Me semble plus clair


Chaque instruction est découpée. Il est facile de rajouter ou d’enlever des éléments. L’indentation (Décalage) permet une lecture aisée. De même face, coin, cote1 est plus lisible que fa, co, c1. Les variables i, j, k sont dans ce cas réservées aux boucles For/Next, habitude des premiers Basic mais dans VB le nom des variables peut être compréhensif.


Une bonne habitude est de formater les noms des différents éléments du programme suivant leur type : Par exemple :


ScoreJoueur pour une variable


Score_Joueur pour une routine


Aff_ScoreJoueur pour un objet (un Label par exemple)


En mettant des majuscules, la vérification lors de la saisie sera automatique. En effet l’éditeur VB mettra automatiquement les majuscules lorsque vous saisirez votre ligne de programmation en minuscule. Cette astuce évite de nombreuses « Syntax Error » et vous saurez à la lecture du nom à quel objet vous avez à faire.


Autre point important : vous programmez en VB pas en Basic ZX81 alors les GOTO sont à bannir. Utilisez des sub routines rendra votre programme plus clair et compréhensible. De plus celles-ci peuvent être utilisées à différents endroits du programme.





Pour résumer :


1 ligne par instruction


Indenter les lignes logiquement


Eviter les suites d’instruction séparées par « : »


Utilisez des noms clairs


Bannir les GOTO, LEN


En suivant ces quelques conseils, tous les passionnés de programmation, que vous êtes, pourront relire vos programmes. Votre tâche sera également simplifiée lorsque vous serez amené à reprendre votre programme pour le modifier plusieurs mois après l’avoir écrit.


N’oubliez jamais que ce n’est pas par ce que ça marche que vous avez bien travaillé. Un bon logiciel se reconnaît aussi à sa facilité d’évolution et de mise à jour.

A de Gallium

6 réponses

cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 41
11 avril 2005 à 19:13
JE suis en partie d'accord avec toi, mais en partie seulement, et même
si certains code ne donnent vraiment pas envie de s'y plonger dedant.

Si je te rejoint sur quelques points, sache que l'identation comme tu
la présente n'est pas du tout claire pour certains programmeurs (je ne
fais pas partie de cela, mais j'en connais au moins 4 sur une douzaine,
c'est déjà pas mal, et c'est un rude combat tous les jours).



En fait chaque personne à sa façon de coder. Personnellement les
majuscules pour la première lettre des variables (de chaque mot même)
c'est uniquement reservé aux variables globales (privées et publiques).
Tout en majuscule c'est des constantes, énumérations, ...

Les variables locales à une procédure sont obligatoirement tout en minuscule.



Le nom des procédures à la première lettre de chaque mot en majuscule.

L'appel des procedure (sub ou fonction) se fait toujours par le nom
suivi des parathèses, utilisation du mot clé call si nécessaire (même
si c'est pas propre pour certains)

.........................

.......................



Quant aux débutants, il faut pas leur en vouloir (on y est tous
passer), quand on sais pas encore ce que le mot programmer veut dire on
ne peut exiger d'eux rigueur et methode d'autant plus que VB permet de
programmer àLaMortMoiLeNoeud (d'ailleur on reconnait facilement les
débutants venant du C).

T'inquiete pas, quand-ils auront buter sur un bug pendant 2 jours
pour une simple virgule mal placée, ils y viendront tous seul à la
rigueur et la méthode.



Un peu de souplesse, laisse les débutants debuter et les passionés se passioner.



Et puis si tout le monde coder correctement, VBFrance n'existerait pas, et avoue que ce serait dommage quand même.




<hr size="2" width="100%">Si le cerveau était assez simple pour que nous puissions le comprendre,

nous serions assez bête pour ne pas le comprendre malgré tout.
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 41
11 avril 2005 à 19:15
PS : ne pas regarder les fautes d'haurtograffes. Je suis pas en forme ce soir.




<hr size="2" width="100%">Si le cerveau était assez simple pour que nous puissions le comprendre,

nous serions assez bête pour ne pas le comprendre malgré tout.
0
cs_CanisLupus Messages postés 3757 Date d'inscription mardi 23 septembre 2003 Statut Membre Dernière intervention 13 mars 2006 18
11 avril 2005 à 21:00
Salut,

Je suis bien OK avec ce que ArseneDeGallium appelle "indentation".
Pour le reste, majuscules, minuscules, etc..., enfin le nommage des variables, contrôles et autres objets, je ne suis pas d'accord. Il existe 1001 manières de nommer.Perso, je préfère utiliser les préfixes et les noms explicites, par ex cb_Quitter commandbutton qui permet de quitter; s_Buffer une variable qui sert à réceptionner une chaine ; etc... ou sinon que des noms explicites (par ex, un cote1 n'est pas plus explicite qu'un c1, j'aurais préféré un cote_horizontale ou cote_verticale, ...).
Et puis, surtout, tous les 2, vous oubliez une chose très importante pour pouvoir relire un code : LES COMMENTAIRES , quelle que soit la manière de coder.
Il ne s'agit pas bien sûr d'écrire des trucs comme :
'affectation de la valeur 1 à la variable int_Truc
int_Truc = 1
ça serait ridicule
mais, il est bon de savoir ce que fait une partie de code ou une fonction.

Casy > je viens du C et d'ailleurs je continue à programmer en C pour le fun ou pour des applis pointues. Tu as réussi à me reconnaitre ?

Loup Gris
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 41
11 avril 2005 à 21:23
J'ai oublier de parler des commentaires et pourtant c'etait mon
intention première d'appuyer très fortement sur ce point. Quand je dit
que je suis pas en forme ce soir



Oui, il ya 1001 façon de nommer, c'est ce que j'ai dit -->
En fait chaque personne à sa façon de coder




Canis > je ne t'ai pas reconnu particulièrement
je parlais en général (et des débutants, je pense que tu as dépassé ce
stade).



Je parlais surtout de mon expérience avec les stagiaires et autres
intérimaires que l'on peut recevoir temps en temps au boulot. Ceux qui
connaissent le C même seulement scolairement ont généralement déjà une
certaine rigueur dans le codage, un raisonnement pas trop mal construit
face au problème et surtout ils commencent pas par foncer tete baissée
de le code (avec VB on peut tout faire! oui surtout le pire). Et une
bonne analyse du problème avant de commencer à coder, c'est 50% du
programme de déjà fait avant même de commencer.

Autrement Canis,
oui je t'ai reconnu dans ta façon de nommer les variables. J'ai la même
en C mais pas en VB. Et puis tu as oublier la plus importante : pXXXX
pour les pointeurs

(Perso moi c'est cmdQuitter )




<hr size="2" width="100%">Si le cerveau était assez simple pour que nous puissions le comprendre,

nous serions assez bête pour ne pas le comprendre malgré tout.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cs_CanisLupus Messages postés 3757 Date d'inscription mardi 23 septembre 2003 Statut Membre Dernière intervention 13 mars 2006 18
11 avril 2005 à 23:20
casy, je crois qu'on est sur la même longueur d'onde. Comme toi, je n'ai pas la même façon de coder et de nommer en C qu'en VB ou en d'autres langages (quoique j'essaie de rester cohérent) et même pire, quand je réponds sur le forum, j'essaie de comprendre et d'utiliser la même façon de coder que le demandeur tout en glissant quelques unes de mes idées de structuration. Le tout est de se faire comprendre.
Finalement, je pense qu'en prog, il ne faut pas être psycho-rigide mais plutôt caméléon. N'est ce pas ArseneDeGallium ?
J'ai bossé pour plein de boites et, dans chaque, il y avait des conventions de développement et de nommage différentes, au gré des chefs de projet. Il m'est même arrivé de bosser pour la même boite à quelques mois d'intervalle avec des conventions différentes.
Et je ne parle pas des chefs de projets qui viennent du COBOL, voire de CLIPPER et DBxx, c'est les pires. Ils ont oublié que le monde a touné et évolué sans eux.(Petite vengeance ).

En tous cas, nombreux sont ceux qui ont voulu imposer une méthode de prog universelle et aucun n'a réussi.

Maintenant, il est vrai qu'en vb6, il y a des choses à respecter :
set obj = nothing pour libérer la mémoire
et le célèbre doevents dans les boucles pour éviter de monopoliser la mémoire

Loup Gris
0
ArseneDeGallium Messages postés 6 Date d'inscription dimanche 4 août 2002 Statut Membre Dernière intervention 12 avril 2005
12 avril 2005 à 08:37
Bonjour
Je suis d'accord avec vous et mon message n'avait d'autres but que d'ouvrir le débat. Chacun utilise la méthode qu'il souhaite mais il faut reconnaitre que certain sont quasiment illisibles. Concernant les commentaires c'est tellement évident que j'ai oublié d'en parler. Il faut aussi faire la différence entre la programmation de loisir et la programmation professionnelle qui demande une approche plus rigoureuse.
Il n'était pas dans mes intentions de faire quelques reproches que se soit aux débutants et je suis d'accord avec Casy concernant le débogage.
CanisLupus, je ne souhaite pas imposer quoi que se soit, il s'agit de quelques remarques suite à la lecture d'un code récupéré sur ce site et particulièrement alambiqué et incompréhensible.

A de Gallium
0