Bonnes manières de rédiger du code ?

**[Hugo]** · 27/10/2006, 15h43

Curiosité :

J'ai remarqué que les gens qui ont l'air de savoir programmer (pour ce que je peux en juger) ont souvent tendance à déclarer les variables une par une, genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
	string lecture;
	string val_vera;
	int nb_q;
	int type_q;
	int i;
	int nb_items;

Plutôt qu'en ligne, genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
int i, j, nb_q, type_q, nb_items, val_vera;

quelle en est la raison ? Lisibilité... ou autre chose ?

Plus généralement, je ne sais pas si cela existe, mais il me semble que ce serait intéressant d'avoir un doc ou un fil sur "les bonnes habitudes" en matière de rédaction de programme (avec le pourquoi de ces bonnes habitudes), bonnes habitudes au sens large, of course... ça pourrait éclairer les amateurs pas trop aiguisés comme votre serviteur... et puis ce serait une manière originale de parler de programmation : par la forme plus que par le fond, et si les magiciens du C++ peuvent faire le lien entre les deux, ce serait un outil pédagogique sympa... ou peut-être que je dis des bêtises....

Hugo

**zooro** · 27/10/2006, 15h46

Salut,

Déclaration en ligne ? Pas très lisible ça, surtout s'il y a des pointeurs dans le lot.
Une déclaration par ligne, c'est mieux, et en plus ça te permet de commenter un peu tes déclarations

Jette un oeil ici : http://emmanuel-delahaye.developpez.com/codage.htm

**b Oo** · 27/10/2006, 15h47

Salut,
il vaut mieux déclarer une variable par ligne car :
1. c'est plus lisible
2. si tu veux rajouter un commentaire c'est plus simple
3. il faut initialiser le plus possible les variables, donc c'est mieux quand il n'y a qu'une variable par ligne !

EDIT :
MDR

J'ai voulu être trop rapide et j'avais ecris l'inverse !

**[Hugo]** · 27/10/2006, 15h48

Salut,

Merci pour vos judicieuses réponses

, je vais peut-être finir par écrire proprement un jour

,

Hugo

**zooro** · 27/10/2006, 15h49

Envoyé par b Oo

Salut,
il vaut mieux déclarer les variables les unes à la suite des autres car :
1. c'est plus lisible
2. si tu veux rajouter un commentaire c'est plus simple
3. il faut initialiser le plus possible les variables !

Et en plus, ça atteint la Force 2 sur l'échelle du goret !

**Matthieu Brucher** · 27/10/2006, 15h51

http://c.developpez.com/livres/#L2744071447

**bolhrak** · 27/10/2006, 15h51

Pour la déclaration des variables j'y vois principalement deux raisons :
- la lisibilité
- si tu souhaites ajouter un commentaire pour expliquer à quoi sert ta variable ou pour générer de la doc type doxygen par exemple.

Après pour ce qui est de la "bonne manière" de rédiger du code, il n'y en a pas vraiment qu'une seule, chaque boîte a ses procédures qualités (dont fait partie des trucs aussi débiles que le nombre de caractères d'indentation), et c'est plus ou moins laissé à l'appréciation des gens du moment qu'elles respectent certains principes de base. En vrac comme ça je pense déjà à ce qui suit :

- lisibilité, donc éviter de trop imbriquer les appels, ou alors sauter des lignes entre chaque appel, ça change rien pour el compilo mais pour le lecteur si
- la déclaration des vraiables dont on parlait plus tôt.
- ne déclarer les variables que si on est sûr de les utiliser et au moment où on les utilise.
- commentaires expliquant POURQUOI on fait les choses de cette manière, et non pas COMMENT on les fait (le code suffit normalement pour le COMMENT sinon c'est qu'il est mal rédigé :p).

PS : ouch le nombre de messages le temps de rédiger

mat.M · 27/10/2006, 15h54

Déclarer les variables les unes à la suite des autres c'était valable du temps des systèmes avec peu de mémoire ou pour l'embarqué quand tu as peu de RAM...
maintenant avec les supers environnement de développement cela ne vaut plus la peine et une déclaration par ligne améliore la lisibilité du code source.

**Jean-Marc.Bourguet** · 27/10/2006, 16h03

Envoyé par mat.M

Déclarer les variables les unes à la suite des autres c'était valable du temps des systèmes avec peu de mémoire ou pour l'embarqué quand tu as peu de RAM...

Je ne vois vraiment pas le rapport.

Je verrais plutôt le rapport avec les terminaux à 24 lignes de 80 caractères.

**Jean-Marc.Bourguet** · 27/10/2006, 16h04

Attention quand on mets plusieurs variables sur une ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int* p, i;

définit un pointeur et un int.

**[Hugo]** · 27/10/2006, 16h07

Miles,

Merci pour la réf ! je viens de commander...

Hugo

**spidermario** · 03/11/2006, 16h35

Envoyé par Jean-Marc.Bourguet

Attention quand on mets plusieurs variables sur une ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int* p, i;

définit un pointeur et un int.

Faux,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int* a,b;

définit deux pointeurs, c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int *a,b;

qui définit un pointeur et un int.

**koala01** · 27/10/2006, 16h47

Salut,

Envoyé par mat.M

Déclarer les variables les unes à la suite des autres c'était valable du temps des systèmes avec peu de mémoire ou pour l'embarqué quand tu as peu de RAM...
maintenant avec les supers environnement de développement cela ne vaut plus la peine et une déclaration par ligne améliore la lisibilité du code source.

Heuuu, essayerais tu de faire croire que, le fait de rajouter un ou deux caractère apres chaque variable (selon le système d'exploitation) va REELLEMENT influer sur la mémoire????

D'autant plus que ces caractères ne sont pas pris en compte dans l'exécutable

La longueur de ton code source et la complexité totale du projet seront bien plus importantes dans l'utilisation de la mémoire que "simplement" quelques caracètres par ci par là

[Hugo]==> Quand j'étais ambulancier, on avait l'habitude de dire que dans la vie, on ne peut etre sur de rien...

L'écriture d'une variable par ligne va dan ce sens... Tout comme l'indentation du code, le choix de noms de variables et de fonctions en relation avec leur utilité/leur but etc.

L'idée est qu'un code qui peut te parraitre limpide au moment où tu l'écris risque de te sembler beaucoup plus ténébreux dans une semaine, un mois ou ...quelques années...

Meme si c'est toi qui l'a écrit

... alors, penses à la difficulté que cela peut représenter pour ceux qui ne l'ont pas écrit

Et tout le problème est là, à vrai dire...

Or, les raisons qui te feront laisser un code de coté sont multiples:
Que tu partes une semaine en vacances,
que tu laisse passer le week end (parce que tu as congé),
que le gamin se fasse une ottite ou se casse le bras,
que tu découvre un "bug" resté bien planqué pendant des années,
que tu souhaites, à l'usage, de rajouter certaines capacités au programme, j'en passe, et des meilleures ... sont autant de raisons qui te feront "replonger dans le code" plus tard...

En écrivant toutes les variables sur une meme ligne, non seulement, tu perd l'occasion de mettre un petit commentaire sur son utilité, mais, en plus, lors d'une relecture "longtemps" (ce qui peut n'etre qu'une semaine) plus tard, les déclarations étant "noyées" dans le reste du code, tu risques encore "d'occulter" le fait que telle ou telle variable a été déclarée... Avec le résultat que tu te posera la question de savoir d'ou elle vient.

Et, bien évidemment, ce qui est déjà important pour toi, "codeur occasionnel unique", devient crucial dés le moment où toute une équipe est susceptible de poser les yeux sur le code, et dois le comprendre, de préférence dans un délais le plus court possible

Quant à savoir s'il y a réellement une "liste de bienséance" du codage, à moins bien sur que tu ne travailles dans une société qui oblige les gens à coder d'une certaine manière, l'idée générale que tu dois garder en tete est de rester le plus lisible possible...

En vrac, on peut citer:
-une déclaration de variable par ligne
-une instruction par ligne
-des tests aussi simples que possible
-choisir des noms de variables et de fonctions aussi "parlant" que possible
-indenter le code de manière à présenter visuellement les différents blocs d'instructions
-éviter les instructions "goto", de manière à ce que le code soit, le plus possible, lisible "de haut en bas et de gauche à droite"
-etc...

**[Hugo]** · 27/10/2006, 16h53

koala,

Merci

!
J'appartiens à la caste des gens qui codent un peu pour leur plaisir, à l'occasion (mon domaine c'est les matériaux...) et qui se forment un peu sur le tas... autant dire que les occasions de prendre de mauvaises habitudes sont abondantes (ou d'en prendre de bonnes bien rares). La seule chose que j'ai pour moi, je pense, c'est d'être conscient que j'ai des limites que je touche vite du doigt

,

Hugo

**gege2061** · 28/10/2006, 10h38

Envoyé par [Hugo]

Plus généralement, je ne sais pas si cela existe, mais il me semble que ce serait intéressant d'avoir un doc ou un fil sur "les bonnes habitudes" en matière de rédaction de programme (avec le pourquoi de ces bonnes habitudes), bonnes habitudes au sens large, of course... ça pourrait éclairer les amateurs pas trop aiguisés comme votre serviteur... et puis ce serait une manière originale de parler de programmation : par la forme plus que par le fond, et si les magiciens du C++ peuvent faire le lien entre les deux, ce serait un outil pédagogique sympa... ou peut-être que je dis des bêtises....

Guide de style pour bien coder, vous pouvez prendre contact avec l'auteur si vous souhaitez le compléter (en particulier au niveau des langages)

**[Hugo]** · 28/10/2006, 11h02

Merci pour ce lien !!!

Hugo

**Luc Hermitte** · 28/10/2006, 16h18

NB: Ces règles ne sont que des règles stylistiques, des règles sur la forme. Le genre de règles qui uniformisent le look du code dans un projet -- et d'un projet à l'autre, ces règles peuvent changer.

Le C++ demande quantité d'autres règles plus ... axées sur la qualité du code, sur le fond en somme. Le bouquin de H.Sutter et A.Alexandrescu est très bien pour cela -- à ce sujet, je me demande bien comment on est passés de 101 règles en VO à 100 en VF..

Il y a peu, sur le wiki d'ASL je suis tombé sur une page à ce sujet. Il y avait trois liens interessants:
- le bouquin d'Herb et Andrei
- un bouquin (dont le lien était erroné, mais qui doit se retrouver facilement avec google) sur des règles de codage en C++
- un lien vers le PDF de Stepanov au sujet de ses notes sur la programmation -- je n'en suis qu'à une 20aine de pages sur plus de 200, et cela m'a déjà l'air d'être un document des plus interressants