La différence entre un bon et un mauvais programmeur...

James Kanze wrote:

Olivier Azeau wrote:

Justement non, le codage ne doit pas etre une "simple
formalité". C'est peut-etre vrai dans des contextes (que je ne
connais pas) ou on sépare les travaux d'analyse, de conception
et de codage sur des activités tellement distinctes qu'on
emploie des personnes différentes pour les réaliser.

Ce n'est pas nécessairement une question de personnel différent,
une personne peut porter (et porte, en général) plusieurs
châpeaux. Et la façon la plus sûre de ne pas faire une
conception rigueureuse, c'est de ne pas la séparer du codage. Au
minimum (et seulement dans des choses très simple), on écrit
d'abord la définition de la classe, avec la declaration des
fonctions publiques, les invariantes, et les pré- et
post-conditions des fonctions, avant d'ouvrir les sources dans
l'éditeur. Dès que les choses deviennent le moindre petit peu
compliquées, on commence par des diagrammes de classe et des
scénarios ; seulement quand on est sûr de son coup, on se met à
écrire du « code ».

C'est un dogme ou y-a-t-il une bonne justification ?

En C++, une telle séparation entre conception et codage ne
marche pas.

Elle se pratique couramment, tu veux dire. En fait, je n'ai
jamais vu du bon code écrit autrement.

Evidemment, commencer par faire quelques schemas de conception
pour éprouver quelques idées en les soumettant aux collegues
est une bonne chose mais vouloir définir toutes ses classes
sur le papier avant de passer au code n'est en général qu'une
perte de temps.

Qui travaille sur papier ? Il y a Rose, il y a Together, et il y
en a certainement d'autres. Est-ce qu'il existe une boîte
aujourd'hui qui ne s'en sert pas ?

"sur le papier" n'était qu'une façon de formuler les choses.
J'aurais pu tout aussi bien dire :
Vouloir définir toutes ses classes avec Rose avant de passer au code
n'est en général qu'une perte de temps.
J'ai déjà donné sur projet où j'avais fortement influencé une méthode de
travail "toutes les interfaces publiques décrites sous Rose et le code
de ces interfaces généré automatiquement en C++"
Non seulement je ne suggèrerai plus ce genre de choses mais je botterais
le derrière de toute personne qui le suggèrerait dans le cadre d'un
projet auquel je participe !

Et ce pour une raison simple : un travail de développement est
une activité fortement itérative ou l'on navigue en permanence
entre conception, codage et test.

Il peut y avoir des développements itératifs, tout dépend du
contexte. Mais même itératif, on suit la même schéma dans chaque
itération -- conception et définition de ce qu'on veut faire
d'abord, puis validation du concepte, puis codage et tests.

Je ne parle pas de process itératif avec un waterfall par itération.
Je parle de l'activité du développeur devant son écran. Je ne connais
personne qui soit capable d'écrire toutes ses classes dans une phase de
conception sans écrire une ligne de code puis dans un deuxième temps
d'écrire son code sans rajouter une classe ou déplacer des
responsabilités entre les classes.
Il existe surement des "êtres supérieurs" dont les neurones sont
connectées en forme de diagramme de classe ou de séquence mais chez le
commun des développeurs, la conception est raffinée pendant le codage.
C'est pour cela que je parle d'*activité* itérative : la meilleure
productivité chez la plupart des développeurs est obtenue avec quelque
chose comme (sur une période de quelques heures) :
- Je réfléchis à une ébauche de conception avec les classes principales
- Je code ces classes
- J'écris un test
- Je reviens sur le code des classes
- Je fais passer le test
- J'avance dans ma conception en rajoutant un comportement à mes classes
- Je modifie mon test en conséquence
- J'adapte mon code
- Je fais passer le test
- Je pense à une simplification de code : je l'essaye en modifiant le code
- Je fais passer le test
- Je me rends compte que la conception pourrait être plus claire en
rajoutant une classe : je la rajoute
- Je modifie mon test en conséquence
- J'adapte mon code
- Je fais passer le test
.....

Dans plusieurs cas, j'ai constaté une bonne efficacité avec un tel
comportement, et ce quel que soit l'effort porté sur la phase de
conception initiale...
Pour moi, il est clair que le meilleur moyen pour le commun des
développeurs d'arriver au code qui implémente le plus simplement
possible les fonctionnalités voulues c'est de naviguer en permanence
entre conception, code et test.

(et je connais même des personnes qui disent que l'écriture des tests
doit venir avant celle du code mais ceci est une autre histoire...)

J'ajouterais que la productivité maximale est obtenue en rajoutant à
tout ça des discussions avec les collègues pour avoir du feedback sur
les choix effectués.

Le code propre et lisible, on ne l'obtient jamais en sortant
directement d'une conception, mais en l'ayant travaillé
pendant un certain temps qui passe par des aller-retours avec
la conception.

Le code ne devient jamais plus lisible suite à des
modifications. Au plus, on espère qu'il ne devient pas moins
lisible.

C'est bien pour cela qu'il faut suffisamment le re-travailler pour le
rendre à nouveau lisible !

James Kanze wrote:

une réponse
qu'il faut coder bêtement, si on a bien dit que c'est parce
qu'on a reflechi sur ce qu'on avait à coder avant, marquera des
points positifs.

Pas si c'est moi qui fait passer l'entretien ;-)
(mais formulé comme ça il n'y aura pas non plus de points négatifs)

Celui qui veut sauter la phase de conception, et qui se met à
écrire du code sans savoir réelement ce qu'il doit faire, n'a
rien compris au développement dans un milieu industriel ou
commercial. De même quelqu'un qui ne prise pas la simplicité
dans son code.

Il est évident qu'il ne faut pas commencer du code sans savoir ce que
l'on doit faire mais ça c'est du niveau des spécifications.
Ce qui est tout à fait acceptable, et même souhaitable, c'est de
commencer à écrire du code sans savoir complètement *comment* on va le
faire, c'est à dire sans savoir à quoi ressembleront les classes et les
relations entre classes que l'on aura à la fin du codage.

James Kanze wrote:

Olivier Azeau wrote:

Fabien LE LEZ wrote:

On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu
<korch_ki_du@yahoo.fr>:

Le bon programmeur, il code, il compile, il exécute, ca
plante mais c'est un bon programmeur...;)

Le bon programmeur, il réfléchit, il réfléchit, il réfléchit,
il réfléchit, il réfléchit, il réfléchit, il code, ça compile
du premier coup (sauf fautes de frappe), et ça ne plante pas.

Tu as oublié : il sait expliquer a son patron pourquoi il réfléchit
autant ;-)

De plus en plus, c'est son patron qui l'exige. Dans pas mal de
boîtes où j'ai travaillé, il était pratiquement interdit de
commencer le codage sans une revue de la conception avant.

Une fois on m'a imposé de travailler comme cela. Une seule...

Dans ces boites, le patron explique-t-il pourquoi il exige cela ?
(autrement que par "la patron a toujours raison")

Olivier Azeau wrote:

James Kanze wrote:

Olivier Azeau wrote:

Fabien LE LEZ wrote:

On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu
<korch_ki_du@yahoo.fr>:

Le bon programmeur, il code, il compile, il exécute, ca
plante mais c'est un bon programmeur...;)

Le bon programmeur, il réfléchit, il réfléchit, il
réfléchit, il réfléchit, il réfléchit, il réfléchit, il
code, ça compile du premier coup (sauf fautes de frappe),
et ça ne plante pas.

Tu as oublié : il sait expliquer a son patron pourquoi il
réfléchit autant ;-)

De plus en plus, c'est son patron qui l'exige. Dans pas mal
de boîtes où j'ai travaillé, il était pratiquement interdit
de commencer le codage sans une revue de la conception avant.

Une fois on m'a imposé de travailler comme cela. Une seule...

Dans ces boites, le patron explique-t-il pourquoi il exige
cela ? (autrement que par "la patron a toujours raison")

Qu'est-ce qu'il y a à expliquer : dans ces boîtes-là, on voulait
la qualité, et c'est une façon assez efficace pour y arriver. Et
quand je dis « on », c'est le patron et les employeurs -- il n'y
avait pas de nous et eux (ce qui est en fait une chose encore
plus essentielle pour la qualité).

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Olivier Azeau wrote:

James Kanze wrote:

Olivier Azeau wrote:

Justement non, le codage ne doit pas etre une "simple
formalité". C'est peut-etre vrai dans des contextes (que
je ne connais pas) ou on sépare les travaux d'analyse, de
conception et de codage sur des activités tellement
distinctes qu'on emploie des personnes différentes pour
les réaliser.

Ce n'est pas nécessairement une question de personnel
différent, une personne peut porter (et porte, en général)
plusieurs châpeaux. Et la façon la plus sûre de ne pas faire
une conception rigueureuse, c'est de ne pas la séparer du
codage. Au minimum (et seulement dans des choses très
simple), on écrit d'abord la définition de la classe, avec la
declaration des fonctions publiques, les invariantes, et les
pré- et post-conditions des fonctions, avant d'ouvrir les
sources dans l'éditeur. Dès que les choses deviennent le
moindre petit peu compliquées, on commence par des diagrammes
de classe et des scénarios ; seulement quand on est sûr de
son coup, on se met à écrire du « code ».

C'est un dogme ou y-a-t-il une bonne justification ?

Disons que c'est un consensus parmi les experts du
développement. Un consensus sécondé par des mésures ; j'ai déjà
travaillé dans une boîte au moment qu'elle instituait cette
politique, j'ai vu le bond en avant que la qualité a fait, et ce
bond était mésurable, et mésuré -- le taux d'erreurs dans le
code livré s'est divisé par plusieurs ordres de magnitude, et le
temps de développement s'est notablement réduit.

En C++, une telle séparation entre conception et codage ne
marche pas.

Elle se pratique couramment, tu veux dire. En fait, je n'ai
jamais vu du bon code écrit autrement.

Evidemment, commencer par faire quelques schemas de
conception pour éprouver quelques idées en les soumettant
aux collegues est une bonne chose mais vouloir définir
toutes ses classes sur le papier avant de passer au code
n'est en général qu'une perte de temps.

Qui travaille sur papier ? Il y a Rose, il y a Together, et
il y en a certainement d'autres. Est-ce qu'il existe une
boîte aujourd'hui qui ne s'en sert pas ?

"sur le papier" n'était qu'une façon de formuler les choses.

Je m'en doutais un peu. Mais je ne savais pas trop répendre sans
te prendre à la lettre.

J'aurais pu tout aussi bien dire :
Vouloir définir toutes ses classes avec Rose avant de passer
au code n'est en général qu'une perte de temps.

Est-ce que tu as des mésures qui le démontre ? J'ai travaillé
dans beaucoup de boîtes, et j'ai vu l'introduction de Rose au
moins deux fois. Chaque fois avec une amélioration mésurable
dans la productivité des développeurs.

J'ai déjà donné sur projet où j'avais fortement influencé une
méthode de travail "toutes les interfaces publiques décrites
sous Rose et le code de ces interfaces généré automatiquement
en C++" Non seulement je ne suggèrerai plus ce genre de choses
mais je botterais le derrière de toute personne qui le
suggèrerait dans le cadre d'un projet auquel je participe !

Je ne connais pas ton projet, mais je peux dire que je l'ai vu
marcher de façon extrèmement efficace à plus 'une occasion.
Chaque fois qu'on s'est servi de Rose, pour dire.

Je ne suis pas sûr comprendre la position que tu argues. Est-ce
que tu essaies de dire que la conception ne sert à rien, et
qu'il vaut mieux écrire des classes sans savoir leur rôle dans
l'application, et les fonctions sans savoir exactement ce
qu'elles doivent faire, ou est-ce que tu argues qu'il faut
simplement éviter à tout prix de communiquer ces informations
aux autres ?

Enfin, pour revenir à l'histoire du début, une telle attitude
assurera que tu ne te feras jamais embauché dans une des boîtes
où j'ai eu des entretiens. Parce que la méthodologie commence à
faire ses preuves au point où les employeurs ne peuvent plus se
permettre de l'ignorer, et que des questions sur la façon qu'on
s'y adopte font partie de tous les entretiens d'embauche. La
dernière fois que j'ai eu un entretien où il n'en était pas
question doit dater de plus de dix ans. (En fait, on m'interroge
assez particulièrement là-dessus, parce que j'ai un CV qui
pourrait bien être celui du génie solitaire, ce qui éveille la
méfiance.)

Et ce pour une raison simple : un travail de développement
est une activité fortement itérative ou l'on navigue en
permanence entre conception, codage et test.

Il peut y avoir des développements itératifs, tout dépend du
contexte. Mais même itératif, on suit la même schéma dans
chaque itération -- conception et définition de ce qu'on veut
faire d'abord, puis validation du concepte, puis codage et
tests.

Je ne parle pas de process itératif avec un waterfall par
itération. Je parle de l'activité du développeur devant son
écran. Je ne connais personne qui soit capable d'écrire toutes
ses classes dans une phase de conception sans écrire une ligne
de code puis dans un deuxième temps d'écrire son code sans
rajouter une classe ou déplacer des responsabilités entre les
classes.

Tout à fait. C'est pour ça qu'on a des revues de conception.
Ce n'est pas parce que j'ai codé la conception qu'elle devient
mauvaise. C'est seulement qu'une fois codée, il coûte plus cher
de la corriger.

Il existe surement des "êtres supérieurs" dont les neurones
sont connectées en forme de diagramme de classe ou de séquence
mais chez le commun des développeurs, la conception est
raffinée pendant le codage.

Il peut arriver qu'on se rend compte pendant le codage qu'on a
oublié quelque chose, et qu'on revient sur la conception. Mais
ça coûte cher ; c'est beaucoup mieux de l'éviter. C'est
pourquoi, aujourd'hui, le développement logiciel est devenu un
travail d'équipe.

C'est pour cela que je parle d'*activité* itérative : la
meilleure productivité chez la plupart des développeurs est
obtenue avec quelque chose comme (sur une période de quelques
heures) :

- Je réfléchis à une ébauche de conception avec les classes
principales
- Je code ces classes
- J'écris un test

Et tu oublies encore les parties les plus importantes :

-- J'écris une ébauche de conception.
-- J'en discute avec les collègues.
-- J'incorpore les trouvails des collègues en ma conception.

J'itère ces trois démarches jusqu'à ce qu'il y a un consensus
sur la qualité de la conception, puis :

-- J'écris le code des classes et des tests. (L'ordre ici n'a
pas d'importance. J'en connais beaucoup qui insiste qu'il
faut commencer avec les tests, mais je n'en suis pas
convaincu.)
-- Je les fais révisé par mes collègues.

Là aussi, itération jusqu'à consensus, mais en général, si la
première partie a été fait correctement, il n'y a pas
d'itération, parce que le code est trivial.

Évidemment, la révue vérifie aussi que les tests sont complets.

- Je reviens sur le code des classes
- Je fais passer le test
- J'avance dans ma conception en rajoutant un comportement à mes classes
- Je modifie mon test en conséquence
- J'adapte mon code
- Je fais passer le test
- Je pense à une simplification de code : je l'essaye en modifiant le
code

- Je fais passer le test
- Je me rends compte que la conception pourrait être plus claire en
rajoutant une classe : je la rajoute
- Je modifie mon test en conséquence
- J'adapte mon code
- Je fais passer le test
.....

C'est tout bien beau, mais il ne marche que si tu es de la
perfection, et que tu vois tout. Jusqu'ici, je n'ai jamais
rencontré quelqu'un d'aussi fort. D'où l'importance de
travailler à plusieurs. Moi, il y aurait des choses que je ne
vois pas. Toi aussi, Mais avec un peu de chance, ce ne seraient
pas les mêmes choses, et la totalité sera bien supérieur à la
somme des parts.

Dans plusieurs cas, j'ai constaté une bonne efficacité avec un
tel comportement, et ce quel que soit l'effort porté sur la
phase de conception initiale...

Tu as constaté en comparant à quoi ? Avec quelles mésures ?

Pour moi, il est clair que le meilleur moyen pour le commun
des développeurs d'arriver au code qui implémente le plus
simplement possible les fonctionnalités voulues c'est de
naviguer en permanence entre conception, code et test.

Je ne dis pas que dans un très petit projet, on peut changer de
châpeau assez fréquemment. Mais les activités doivent rester
distinctes.

(et je connais même des personnes qui disent que l'écriture
des tests doit venir avant celle du code mais ceci est une
autre histoire...)

C'est une des modes, aujourd'hui:-). Mais ils disent en fait que
les tests, c'est la documentation de la conception -- donc
toujours qu'il faut d'abord la conception.

J'ajouterais que la productivité maximale est obtenue en
rajoutant à tout ça des discussions avec les collègues pour
avoir du feedback sur les choix effectués.

Je dirais que c'est bien l'essentiel. Et que si tu t'es rendu
compte de ça, on est d'accord sur l'essentiel. Parce que la
reste, on y arrive, à condition de discuter de façon ouverte. Si
tu ajoutais une ligne sur la discussion dans chaqu'une des
lignes ci-dessus, je n'en serais pas forcément contre. Je vois
certains problèmes, surtout dans la contexte d'une grossee
application, mais dans la mésure où on en discute, et qu'on se
montre fléxible, c'est jouable.

Mais pour revenir à Rose ou Together : comment discutes-tu de la
conception sans l'avoir définie ? Sur un support que les autres
puissent lire ?

Le code propre et lisible, on ne l'obtient jamais en
sortant directement d'une conception, mais en l'ayant
travaillé pendant un certain temps qui passe par des
aller-retours avec la conception.

Le code ne devient jamais plus lisible suite à des
modifications. Au plus, on espère qu'il ne devient pas moins
lisible.

C'est bien pour cela qu'il faut suffisamment le re-travailler
pour le rendre à nouveau lisible !

Tout à fait.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Olivier Azeau wrote:

James Kanze wrote:

une réponse qu'il faut coder bêtement, si on a bien dit que
c'est parce qu'on a reflechi sur ce qu'on avait à coder
avant, marquera des points positifs.

Pas si c'est moi qui fait passer l'entretien ;-) (mais formulé
comme ça il n'y aura pas non plus de points négatifs)

En fait, évidemment, une phrase, prise comme ça, n'a pas
beaucoup de valeur en soi ; il faut la mettre dans la contexte
de tout ce que dit le candidat.

Ceci dit, j'ai passé beaucoup d'entretiens. (Je travaille sur
contrat, ce qui veut dire que je suis souvent à la récherche
d'un travail.) Et prèsque systèmatiquement, il y a des questions
sur la façon de travailler : une insistance que le codage soit
précédé par une conception, par exemple. Et une insistance qu'on
ne pousse pas l'envéloppe du langage, et qu'on écrit des choses
simples, compréhensibles par tout le monde.

Celui qui veut sauter la phase de conception, et qui se met à
écrire du code sans savoir réelement ce qu'il doit faire, n'a
rien compris au développement dans un milieu industriel ou
commercial. De même quelqu'un qui ne prise pas la simplicité
dans son code.

Il est évident qu'il ne faut pas commencer du code sans savoir
ce que l'on doit faire mais ça c'est du niveau des
spécifications.

Et la conception, c'est quoi, sinon une spécification interne du
comportement de chacune des classes ? (Enfin, une bonne
conception doit aboutir à quelque chose de semblable à ça.)

Ce qui est tout à fait acceptable, et même souhaitable, c'est
de commencer à écrire du code sans savoir complètement
*comment* on va le faire, c'est à dire sans savoir à quoi
ressembleront les classes et les relations entre classes que
l'on aura à la fin du codage.

Je ne crois pas. Et toutes les études que j'ai vu jusqu'ici
semblerait me donner raison.

Dans un grand projet, c'est trivialement faux. Une fois que j'ai
figé l'interface de ma classe, je ne peux plus y toucher, parce
que la modifier imposerait des modifications chez tous les
collègues qui s'en servent. Mais même dans les petits projets,
c'est préférable d'éviter des modifications qui impactent
partout.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

James Kanze wrote:

J'ai déjà donné sur projet où j'avais fortement influencé une
méthode de travail "toutes les interfaces publiques décrites
sous Rose et le code de ces interfaces généré automatiquement
en C++" Non seulement je ne suggèrerai plus ce genre de choses
mais je botterais le derrière de toute personne qui le
suggèrerait dans le cadre d'un projet auquel je participe !

Je ne connais pas ton projet, mais je peux dire que je l'ai vu
marcher de façon extrèmement efficace à plus 'une occasion.
Chaque fois qu'on s'est servi de Rose, pour dire.

Je ne suis pas sûr comprendre la position que tu argues. Est-ce
que tu essaies de dire que la conception ne sert à rien, et
qu'il vaut mieux écrire des classes sans savoir leur rôle dans
l'application, et les fonctions sans savoir exactement ce
qu'elles doivent faire, ou est-ce que tu argues qu'il faut
simplement éviter à tout prix de communiquer ces informations
aux autres ?

Il y a d'autres possibilités, comme de dire tout simplement que Rose
n'est pas un bon outil pour faire de la conception ou communiquer dessus.

De plus, je pense que le niveau de détail sur lequel il faut arrêter la
conception dépend des gens, des tailles d'équipe, des types de projet...

[...]

Mais pour revenir à Rose ou Together : comment discutes-tu de la
conception sans l'avoir définie ? Sur un support que les autres
puissent lire ?

J4ai moi aussi un problème avec Rose. J'ai essayé de l'utiliser, mais
j'ai triuvé ça très laborieux. Je réfléchis jusqu'à ce que j'ai une
ébauche de conception dans la tête, mais après, s'il me faut trop de
temps pour la retranscrire, ce qui a été le cas quand j'ai utilisé Rose,
j'ai tendance à me mélanger les pinceaux. Ou à avoir un chef qui
débarque dans mon bureau pour de la paperasserie ou organiser une démo.

Together m'avait semblé plus approprié à l'époque, mais encore immature,
très lent et trop orienté Java.

Pour l'instant, j'ai tendance à travailler au papier et crayon, ou
encore en décrivant mon architecture sous forme de squelette de classe
écrits en C++, avec la doc d'utilisation de ses classes. Je n'en suis
pas pleinement satisfait, mais n'ai pas encore trouvé mieux.

--
Loïc

On Sun, 30 Jan 2005 21:17:39 +0100, James Kanze <kanze@none>:

Dans un grand projet, c'est trivialement faux. Une fois que j'ai
figé l'interface de ma classe, je ne peux plus y toucher, parce
que la modifier imposerait des modifications chez tous les
collègues qui s'en servent. Mais même dans les petits projets,
c'est préférable d'éviter des modifications qui impactent
partout.

Je travaille dans une toute petite entreprise, où je suis le seul
programmeur (et encore, pas à temps plein, puisque je m'occupe aussi
du parc informatique et du serveur web).
Et pour le coup, la donne est un peu différente. C'est le même
principe que le monothread/multithread : quand j'écris une classe, je
n'ai pas le temps d'écrire beaucoup de code qui l'utilise. Du coup,
j'ai une certaine latitude pour changer l'interface tant que le gros
du développement de cette classe n'est pas terminé.
Evidemment, une fois que je passe à l'utilisation de cette classe, je
ne peux plus changer l'interface -- sauf pour rajouter des membres, ou
des paramètres avec une valeur par défaut.


--
;-)

Dans le message 41f95372$0$26206$7a628cd7@news.club-internet.fr,

pour moi, commenter correctement son code c'est ceci :
commenter le code sans le paraphraser, de telle sorte que si l'on
enlève toutes les lignes de code d'une fonction, on puisse lire
l'algorithme grâce aux commentaires.

Ça me semble une définition de « commenter correctement » qui n'est
pas très répandue... Je ne l'ai jamais vu dans les ouvrages sérieux
sur la programmation.

par "sans le paraphraser", j'entends :
PAS BON :
/* mettre 42 dans le champ reponse de question */
question.reponse = 42;

BON :
/* initialiser la recherche de la question fondamentale sur la vie
l'univers et le reste */
question.reponse = 42;

Alors là, je dirais que si l'on peut écrire d'aussi « bons »
commentaires sans pouvoir du meilleur code, on a un problème plus
important que l'écriture de bons commentaires. Je sais que c'est
un exemple non réaliste, mais, justement, on ne peut s'y fier pour
montrer de « bons commentaires ».

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Dans le message pntiv05lfuktguirdsuusfgoq5gf5k6ur5@4ax.com,

Je préfère

std::vector<std::string> split
(std::string const &text, char separateur= ',');

Juste un mot pour indiquer que mettre du français et de l'anglais
ainsi, ce serait vraiment une mauvaise idée ! (donc on met texte
ou separator... et on se décide aussi sur le nom de la fonction
vs les noms des autres, selon les standards en place)

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/