Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ La différence entre un bon et un mauvais programmeur...

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

105 réponses
Avatar
korchkidu
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...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.

Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Olivier Azeau
Sayajin wrote:
"korchkidu" 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.


Avatar
Laurent Deniau
Olivier Azeau wrote:
Sayajin wrote:

"korchkidu" 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.


Ca depend du contexte. Ca peut en rapporter aussi.

a+, ld.



Avatar
Laurent Deniau
Sayajin wrote:
"korchkidu" a écrit dans le message de news:
41f901ba$

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...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait
jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un
avenir proche, c'est juste une question de curiosite.

Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)



Un bon programmeur fait beaucoup de conception avant de coder, faut pas se
jeter directe sur son IDE pour taper du code sans réfléchir.


Pourquoi pas? Avec les outils appropries ca peut-etre une des meilleurs
solutions pour converger rapidement vers un tres bon design.

a+, ld.


Avatar
Sayajin
"Olivier Azeau" a écrit dans le message de news:


Sayajin wrote:
"korchkidu" 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.


Avatar
Sayajin
"Sayajin" a écrit dans le message de news:
41f92dfc$0$18830$

"Olivier Azeau" a écrit dans le message de news:


Sayajin wrote:
"korchkidu" 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.

Zut J'ai rippé j'ai pas mis de réponse !


Bien entendu faut pas le dire tel quel. La conception doit être conséquente.



Avatar
Laurent Deniau
Sayajin wrote:
"Sayajin" a écrit dans le message de news:
41f92dfc$0$18830$

"Olivier Azeau" a écrit dans le message de news:


Sayajin wrote:

"korchkidu" 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.



Zut J'ai rippé j'ai pas mis de réponse !

Bien entendu faut pas le dire tel quel. La conception doit être conséquente.


On peut aussi imaginer des etapes de refactoring tres rapprochees.

a+, ld.




Avatar
Sayajin
"Laurent Deniau" a écrit dans le message de news:
ctbc1a$b8u$
Sayajin wrote:
"Sayajin" a écrit dans le message de news:
41f92dfc$0$18830$

"Olivier Azeau" a écrit dans le message de news:


Sayajin wrote:

"korchkidu" 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.



Zut J'ai rippé j'ai pas mis de réponse !

Bien entendu faut pas le dire tel quel. La conception doit être
conséquente.


On peut aussi imaginer des etapes de refactoring tres rapprochees.

a+, ld.


Bien sur mais mieux vaut avoir un code assez propre dés le début qui repose
csur des bases saines ! Si c'est pour rendre le code propre pas la peine !





Avatar
flure
- commente correctement son code


Tout dépend du 'correctement' : il en faut ni trop, ni trop peu
Il est d'ailleurs préférable de faire comprendre une intention
directement dans le code que d'utiliser des commentaires pour
expliciter un code un peu trop illisible


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.

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;

- 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. 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à. La bonne
maintenance de la documentation est étroitement liée à la bonne
maintenance du code, on piste donc plus facilement les endroits où l'on
s'est "laissé aller".

- gère les erreurs correctement,


et, surtout, documente les cas d'erreur, idéalement avec des scenarios
de test correspondant a ces cas


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

- é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.

- optimise l'algorithme en premier


Pourquoi ?


Quand le programmeur est contraint d'optimiser son code, il doit d'abord
utiliser un profileur pour déterminer où sont les bottlenecks, et, pour
optimiser ces endroits, commence par chercher un meilleur algorithme,
avant de descendre d'un cran dans le niveau d'optimisation. Ce que je
voulais dire, c'est qu'on commence par l'optimisation haut niveau, pour
descendre peu à peu, jusqu'à arriver à des performances satisfaisantes.
Les optimisations en ASM arrivent évidemment en dernier recours.

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


Un enum ? C'est quoi ?


second degré j'espère ???

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

- sait écrire une documentation pour le client


Savoir tout simplement communiquer avec les intervenants extérieurs a
son équipe, c'est deja pas mal...


Tu n'as pas eu les mêmes chefs de projet que moi ...

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

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.

--
Florent "flure" C.
http://flure.free.fr


Avatar
Loïc Joly
flure wrote:


et, surtout, documente les cas d'erreur, idéalement avec des scenarios
de test correspondant a ces cas



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


Je pense qu'il y a là confusion entre test unitaire et validation des
pré/post conditions/invariants.

Les tests unitaires n'on pas à appraître dans le code même mais à côté,
puisqu'on se place dans le cadre d'un client lambda de la classe en
cours de test. De plus, ça évite d'encombrer le code avec le code de test.

--
Loïc


Avatar
Olivier Azeau
flure wrote:
Tout dépend du 'correctement' : il en faut ni trop, ni trop peu
Il est d'ailleurs préférable de faire comprendre une intention
directement dans le code que d'utiliser des commentaires pour
expliciter un code un peu trop illisible


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.


Mais pourquoi vouloir enlever les lignes de code ???
C'est quand même elles qui font le boulot en fin de compte, non ?
L'idéal c'est quand même de pouvoir enlever tous les commentaires et
lire *aussi bien* l'algorithme uniquement grace au noms de variables et
de fonctions !

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;


Et que dire de :
questionFondamentaleSurLaVieLUniversEtLeReste.initialiserReponse( 42 );

Dans le même ordre d'idée :
http://www.refactoring.com/catalog/introduceExplainingVariable.html

- 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. 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à. La bonne
maintenance de la documentation est étroitement liée à la bonne
maintenance du code, on piste donc plus facilement les endroits où l'on
s'est "laissé aller".


Pourquoi devrait-on se "laisser aller" ?

Le principal problème avec la documentation, c'est que l'on n'est jamais
sûr de sa validité, et, effectivement, si qqun s'est "laissé aller", on
en est encore moins sûr !
Que celui qui n'a jamais vu de documentation obsolète me jette la
première pierre...

Une approche "moins de docs, plus de tests" a l'avantage de "documenter"
avec du code qui s'exécute pour tester un autre code, il en dit aussi
long que du blah blah, voire plus car il ne peut pas "tricher".
Si on se "laisse aller" dans ces conditions, la sanction est immédiate :
le test ne passe plus et il faut agir.

Bref il faut trouver un bon compromis entre :

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

et :

std::vector<std::string> s = split( "ri-ri,fi fi,lou;lou" );
UNIT_TEST_ASSERT( s[0] == std::string("ri-ri") );
UNIT_TEST_ASSERT( s[1] == std::string("fi fi") );
UNIT_TEST_ASSERT( s[2] == std::string("lou;lou") );

- é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.


Mais cette prévoyance, arrives-tu à la justifier ?
Comment expliques-tu à un client que tu as passé 1 semaine à implémenter
la fonctionnalité X de manière générique et qu'il pourra dans le futur
avoir rapidement les fonctionnalités X1 et X2 (dont rien ne dit qu'il en
aura besoin) et que du même coup, tu n'as pas eu le temps d'implémenter
la fonctionnalité Y ?

- optimise l'algorithme en premier


Pourquoi ?


Quand le programmeur est contraint d'optimiser son code, il doit d'abord
utiliser un profileur pour déterminer où sont les bottlenecks, et, pour
optimiser ces endroits, commence par chercher un meilleur algorithme,
avant de descendre d'un cran dans le niveau d'optimisation. Ce que je
voulais dire, c'est qu'on commence par l'optimisation haut niveau, pour
descendre peu à peu, jusqu'à arriver à des performances satisfaisantes.
Les optimisations en ASM arrivent évidemment en dernier recours.


C'est une approche qui se défend mais il ne faut pas pour autant
occulter des optimisations qui ne touchent pas à l'algo.
Exemple : si le bottleneck est sur le fait que l'algo utilise trop les
allocs dynamiques, changer d'allocateur dynamique et ne rien toucher au
reste est une option satisfaisante si elle permet de rentrer dans les
contraintes de performance.


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


Un enum ? C'est quoi ?


second degré j'espère ???


Si peu...

"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...

http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

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


Mais pourquoi ?
Une équipe qui ne se parle pas quand une des personnes est bloquée ne
serait-ce que quelques minutes, ce n'est pas une équipe, du moins pas au
sens où je la conçois.
Si qqun peut être débloqué en demandant un truc qui va prendre 1 minute
à lui + un collègue et qui lui en aurait pris 10 s'il restait seul dans
son coin, c'est globalement 8 minutes de gagnées pour l'équipe + une
possibilité de feedback immédiat car un oeil extérieur s'est intéressé
pendant quelques secondes à ce qu'il faisait.

- sait écrire une documentation pour le client


Savoir tout simplement communiquer avec les intervenants extérieurs a
son équipe, c'est deja pas mal...


Tu n'as pas eu les mêmes chefs de projet que moi ...


Dois-je en déduire que l'on juge si un "programmeur" est "bon" à
l'opinion qu'a de lui son chef de projet ?



1 2 3 4 5