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

On Thu, 27 Jan 2005 23:54:02 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:

// Cette fonction découpe la chaîne contenue dans 'text' en sous-chaînes
// Elle utilise le caratère ',' comme séparateur de sous-chaînes
// Elle renvoie un vecteur contenant dans les sous-chaînes découpées
std::vector<std::string> split( std::string const &text );

Je préfère

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

D'une part, cette version est plus générale, c'est peut-être bien,
peut-être mal, suivant les cas -- d'ailleurs tu en parles plus loin
dans ton message.
Mettre ce prototype à la place du précédent ne casse (généralement)
pas de code.

Mais surtout, le prototype suffit quasiment à comprendre ce qu'elle
fait :
split => découpe ...
std::string const &text => ... un texte passé sous forme de
std::string comme premier argument ...
char separateur => ... en utilisant le séparateur (caractère
unique) passé comme deuxième argument ...
= ',' => ... et le séparateur par défaut est la virgule

<troll> et comme ça, on n'a pas besoin de commenter soi-même -- on
peut embaucher un stagiaire pour écrire a posteriori commentaires et
spécifications. </>


--
;-)

On Thu, 27 Jan 2005 23:54:02 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:

"grep enum *.h* | wc -l" c'est un bon indicateur de "(non-)qualité"
car derrière un enum se cache souvent un switch et derrière un switch...

Ah bon ? Dans ce cas, un petit

#define ANTI_GREP en ## um

devrait améliorer les choses ;-P


--
;-)

On Fri, 28 Jan 2005 00:50:42 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:

il va falloir trouver celle du
"bon programmeur stagiaire" ;-)

Ça, c'est facile : c'est celui qui évite aux programmeurs titulaires
de perdre leur temps.


--
;-)

Fabien LE LEZ wrote:

On Thu, 27 Jan 2005 23:54:02 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:

// Cette fonction découpe la chaîne contenue dans 'text' en sous-chaînes
// Elle utilise le caratère ',' comme séparateur de sous-chaînes
// Elle renvoie un vecteur contenant dans les sous-chaînes découpées
std::vector<std::string> split( std::string const &text );

Je préfère

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

D'une part, cette version est plus générale, c'est peut-être bien,
peut-être mal, suivant les cas -- d'ailleurs tu en parles plus loin
dans ton message.
Mettre ce prototype à la place du précédent ne casse (généralement)
pas de code.

Mais surtout, le prototype suffit quasiment à comprendre ce qu'elle
fait :
split => découpe ...
std::string const &text => ... un texte passé sous forme de
std::string comme premier argument ...
char separateur => ... en utilisant le séparateur (caractère
unique) passé comme deuxième argument ...
= ',' => ... et le séparateur par défaut est la virgule

Tout à fait d'accord (mais je n'avais pas envie de réfléchir plus de 10
secondes pour trouver un exemple de 'documentation par les tests')

<troll> et comme ça, on n'a pas besoin de commenter soi-même -- on
peut embaucher un stagiaire pour écrire a posteriori commentaires et
spécifications. </>

Après la définition du "bon programmeur", il va falloir trouver celle du
"bon programmeur stagiaire" ;-)

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 ;-)

D'autant que son son patron à du mal à comprendre pourquoi il
a besoin de WarCraft comme support à sa longue réflexion.

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

korchkidu wrote:

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

Le bon programmeur, il conçoit, il discute la conception avec
ses collègues, il code, il discute le code avec ses collègues,
il teste, ça marche, et il livre.

Plus serieusement, je vois souvent "bons programmeurs" ou
"mauvais programmeurs". Comme je sais qu'il y a surement parmi
vous des gens qui doivent decider si quelqu'un est un bon ou
un mauvais programmeur, je serais curieux de connaitre les
criteres sur lesquels vous vous bases pour decider de ca dans
le cas du C++. Par exemple, lors d'un entretien, qu'est ce qui
peut faire gagner des points et qu'est ce qui peut en faire
perdre...

Dans mon cas, les fois où on m'a convoqué à un intervue, c'était
exprès pour évaluer les compétences C++, Unix ou OO. Pas pour
une évaluation générale, et c'était toujours entendu que ces
connaissances n'en faisaient qu'une petite partie de ce qu'il
fallait.

Si j'avais la responsibilité totale, je commencerais par essayer
à comprendre un peu de la personalité du programmeur -- est-ce
qu'il s'integrait bien dans notre équipe, par exemple ? Ce qui
n'est pas forcement un jugement sur les compétences du
programmeur ; les équipes diffèrent, et il y aurait certainement
de bons programmeurs qui ne s'integreront pas dans mon équipe.

Au delà des connaissances particulières (langage, système
d'exploitation, domaine d'application, etc.), je rechercherais
une certaine rigueur dans la façon de penser et de s'exprimer,
une volenté de « faire bien » à l'intérieur d'une équipe, et une
désir non seulement d'écrire des programmes, mais de communiquer
avec les autres.

À la fin, si une personne a un bon esprit logique et
mathématique, et est capable de communiquer bien, il n'aura pas
de problème à apprendre ce qu'il ne connaît pas encore du C++ ou
d'autre chose. Tandis que sans savoir raisonner ou communiquer,
toutes ses connaissances de C++ ne me sert absolument à rien.

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

"korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message de
news:41f901ba$1@epflnews.epfl.ch...

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

Je pense que, sur fclc++, seuls les bons programmeurs te répondront :-)
"recursion is divine" :-))
J'imagine mal un intervenant régulier dire : " Ho ! ben, moi j'suis qu'un
gros nul".

Nous sommes tous de "bons programmeurs" mais seul notre environnement nous
le confirmera.
C'est affaire d'adéquation.

flure wrote:

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

Plus serieusement, je vois souvent "bons programmeurs" ou
"mauvais programmeurs". Comme je sais qu'il y a surement
parmi vous des gens qui doivent decider si quelqu'un est un
bon ou un mauvais programmeur, je serais curieux de
connaitre les criteres sur lesquels vous vous bases pour
decider de ca dans le cas du C++. Par exemple, lors d'un
entretien, qu'est ce qui peut faire gagner des points et
qu'est ce qui peut en faire perdre...

[...]

Le bon programmeur :

Un petit écart : qu'est-ce qu'on entend réelement par
« programmeur ». Parce que dans les domaines où je travaille,
les « programmeurs » sont des ingenieurs, qui s'occupent aussi
de la conception et prenent une responsibilité sur la qualité du
produit. Or, les critères qui suivent semblent s'orienter plutôt
au « pisseur de lignes ».

- écrit du code en respectant la norme et les conventions de
codage de son équipe,

Le deuxième, ça fait partie du b a ba. Quant à la norme, c'est
difficile de le respecter complétement quand les compilateurs ne
le font pas. Sans parler du fait qu'il y a beaucoup de choses
qu'il faut parfois faire qui se trouver en dehors de la norme :
dans mon application, je me sers des sockets, des threads, des
entrées/sorties synchronisées, une base de données... toutes
choses impossibles en respectant rigueureusement la norme.

- commente correctement son code
- utilise un outil pour générer la documentattion à partir des
commentaires (cf. Doxygen ou Natural Docs)

Il aligne ses commentaires sur les conventions de l'équipe. De
même, il utilise des outils de conception préscrits (qui eux se
chargent parfois d'une partie du commentaire), du genre Rose ou
Together.

- gère les erreurs correctement,

Plus généralement, considère les cas d'erreurs et leur
traitement comme faisant partie integrale de son programme.

- fait tout particulièrement attention aux problèmes
d'allocation mémoire

Dans quels sens ? Il fait ce qu'il faut pourqu'il n'y a pas de
fuites de mémoire, ni que la mémoire soit désallouée trop tôt.
Qu'il y a une allocation de plus ou de moins, ce n'est pas
importante.

- écrit un code réutilisable au maximum et ne réinvente pas la
roue

Ça veut dire quoi, « réutilisable au maximum ». Ce n'est
vraiment pas « cost effective » de prévoir des évolutions qui
n'ont pas lieu par la suite, et c'est bien connu que c'est
impossible à prévoir quelles sont les évolutions qui auront
réelement lieu.

Se lancer dans la généricité prématurée, c'est un péché du m ême
genre que l'optimisation prématurée. Dans les deux cas, on ne
s'y lance que quand on sait que ça vaut la peine.

- n'optimise pas de manière prématurée
- optimise l'algorithme en premier

Utiliser le bon algorithme pour commencer ?

- utilise des const ou des enum pour les constantes numériques

Ce genre de détail appartient plutôt aux règles de
programmation. Tu l'as donc couvert dans ton premier point.

- sait s'autoformer sur de nouveaux outils et technologies
- sait trouver de la documentation tout seul

Pourquoi tout seul ? La programmation, c'est un travail
d'équipe. Je serais tempté à dire qu'on ne fait rien tout seul.

- sait écrire une documentation pour le client

Et pour les collègues.

- travaille réellement 8h/jour plutôt que 1h code/2h internet ...

On ne code pas 8h/jour. Pas de manière efficace, en tout cas.

Si je régarde autour de moi, au moins un tiers des développeurs
ont une fenêtre ouverte sur Google en permanence. Comme par
hazard, les plus competents sont tous dans ce tiers-là.

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

flure wrote:

- utilise un outil pour générer la documentattion à partir
des commentaires (cf. Doxygen ou Natural Docs)

Tout dépend des besoins

Quand on travaille à plusieurs, c'est plus que nécessaire.

D'utiliser un outil ? Je le doute. Jusqu'ici, je m'ai vu que
Doxygen, deux fois. Et la première fois, ils sont revenu en
arrière pour l'écarter, parce qu'il s'adoptait mal avec leurs
autres habitudes (génération automatique de code avec Rose,
etc.).

Ça ne veut pas dire qu'il ne faut pas documenter, évidemment. Je
dirais plus : même avec des outils tel Doxygen, il faut de la
documentation en plus, par exemple des diagrammes UML. (Mais
évidemment, on les a fait avant de commencer le code.)

Et quand on travaille tout seul, cela permet de s'imposer une
certaine rigueur. On génère la doc, et l'on voit où les
fonctions ne sont pas bien documentées : il reste du travail à
faire à de ce côté-là.

J'ai l'impression que tu prends les choses à l'envers. D'abord,
on définit ce que doit faire la fonction, et puis, on l'écrit.
Et évidemment, on a tout intérêt à faire cette définition par
écrit, quelque part : d'abord, parce que ça ne coûte pas plus
cher, puis ça peut s'avérer utile par la suite, et surtout, sans
le mettre par écrit, c'est très difficile à attendre la rigueur
voulue.

[...]

C'est vrai, j'ai oublié les tests. Donc un bon programmeur
inclue aussi des tests unitaires dans chacun de ses modules
(entre une paire de #ifdef/#endif pour les désactiver en
release).

Les tests unitaires sont normalement des programmes à part, qui
se basent sur une charpente définie par l'organisation. Et
évidemment, les tests unitaires font partie de la revue du code,
pour être sûr qu'ils soient complets.

[...]

- écrit un code réutilisable au maximum et ne réinvente pas
la roue Ne jamais tomber dans un exces : il faut écrire le

code qui répond au besoin, pas le code qui répond au besoin
de réutilisabilité que l'on aura peut un jour dans 2 ans...

On ne peut pas prévoir quand on aura à nouveau besoin de tel
ou tel code. Mieux vaut être prévoyant.

Justement, on ne peut pas prévoir. Si on prévoir l'adaptabilité
dans trois dimensions, on peut en être sûr que l'adaptation
qu'il va falloir est dans le quatrième. Celle qu'on n'a pas
prévue. Et que le travail qu'on a fait pour l'adaptabilité dans
les autres trois, c'est pour les prunes.

[...]

- sait trouver de la documentation tout seul

I'm a long long way from home...

Non sans dec' c'est quand meme plus important de savoir
dialoguer avec les membres de son équipe non ?

Bien sûr, mais aussi, savoir ne pas les importuner inutilement
est encore plus important.

Si les questions d'un collègue importune quelqu'un, le problème
est chez lui, et non chez le collègue.

[...]

- travaille réellement 8h/jour plutôt que 1h code/2h
internet ...

Et usenet c'est permis ?

Nonon, c'est ce qui consomme le plus de temps :)

C'est donc interdit de se documenter tout seul:-) ?

Tout ca pour dire que si on prend 100 'programmeurs' au
hasard, on aura (environ) 100 descriptions différentes de
'bon programmeur' Ca s'appelle la diversité culturelle et ce
n'est pas si mal que ca...

Du point de vue d'une entreprise en particulier, il n'y a
qu'une seule sorte de bon programmeur.

En général, il n'y a que les détails qui changent. Il y a une
bonne accumulation des connaissances communes.

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

Olivier Azeau wrote:

Sayajin wrote:

"korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message de
news:

Par exemple, lors d'un entretien, qu'est ce qui peut faire
gagner des points et qu'est ce qui peut en faire perdre...

Au final on doit "coder bêtement" !

Voila un exemple de ce qui peut faire perdre des points si on
le dit lors de l'entretien.

Pas du tout. Être bête, c'est une qualité du code. Du code bête,
c'est facile à comprendre, et ça marche premier coup. Un
candidat dit qu'il fait de la conception jusqu'au point que
l'écriture du code devient bête, c'est un candidat qui a compris
comment bien développer.

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