Discussion :

[[Hugo]]

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]

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]

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]]

Salut,

Merci pour vos judicieuses réponses , je vais peut-être finir par écrire proprement un jour ,

Hugo

[zooro]

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]

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

[bolhrak]

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]

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]

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]

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]]

Miles,

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

Hugo

[koala01]

Salut,

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]]

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]

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]]

Merci pour ce lien !!!

Hugo

[Luc Hermitte]

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

[[Hugo]]

Le sutter devrait être bientôt dans ma boite...

Hugo

[[Hugo]]

à ce sujet, je me demande bien comment on est passés de 101 règles en VO à 100 en VF.

A combien commence la numérotation en anglais ? Ca démarre bizarrement à 0 en français...

Hugo

[Luc Hermitte]

De 0 à 100. Ce qui fait bien 101 règles quand on sait faire des boucles en C et dérivés.

[koala01]

A combien commence la numérotation en anglais ? Ca démarre bizarrement à 0 en français...
Hugo

Normalement, le 0 n'existe pas, car c'est une pure vue de l'esprit...

Tu ne sauras jamais me montrer... 0 quoi que ce soit

Au départ, la numérotation arabe (car nos chiffres sont des chiffres arabes, rappelons-le ) laissait simplement un espace quand il s'agissait d'indiquer... qu'il n'y avait pas d'unité, de dizaine ou de...

Le zero n'a été inventé que pour permettre la représentation visuelle de cet espace qui, par moments, n'était pas si visible que cela (y en a-t-il?, n'y en aurait-il pas deux, ou trois???)

Si on reste dans le pur domaine du C et du C++ (car d'autres langages commencent effectivement à compter à 1 ), il se fait que, quand on utilise un tableau du genre de

Code :

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

 int tab[10]

tab représente un pointeur sur le tableau, mais représente tout autant l'adresse à laquelle se trouve le premier élément...

Or, vu que ce qui se trouve entre crochet représente, quelque part, l'écart entre le début du tableau et l'élément du tableau... on se retrouve avec un décalage supplémentaire de 1...

Si les traducteurs ont commencé à compter à 0, ils ont sans doute suivi, à tord, cette habitude propre au C et au C++, et ont sans doute oublié que la regle 0 était en fait la premiere, et que donc, si la dernière avait le numéro 100, elle était en fait la 101eme