Les tares d'un mauvais codeur

[Xenos]

Salut à tous,

histoire de finir la semaine en beauté, et suite à un message de Keltaïnen, je me demande: quelles sont les pires tares d'un mauvais codeur selon vous?

Pour moi, un mauvais codeur:
• Réinvente tout, je ne vais pas laisser un autre faire mon taff!
• Ne lis pas la doc, parce que c'est pour les nuls (de même que chercher sur le net)
• N'écoute/ne demande pas aux autres, parce que leur avis est inutile vu qu'ils sont tous nuls (c'est pour ça que je réinvente tout, cf 1•)
• Fait compliqué, parce que ça en jette (et plus un projet semble compliqué, moins on passe pour un con quand on le rate)
• Règle les problèmes au mauvais endroit (ce qui le pousse souvent à tout réinventer)


Quand on parle de mauvais codeur, j'ai toujours en tête l'image du "singe qui essaie de clouer avec une perceuse et râle que ça marche pas donc il invente la vis ou le marteau" Je ne sais plus trop comment cette métaphore était née, mais ça date des années d'école.

Ces tares s'appliqueraient d'ailleurs aux autres métiers de la création de jeux, à quelques ajustements près.

[Voilà, ça sert un peu à rien comme message, mais ça permet de Blablater ]

[rachids]

Salut,

Sympa comme sujet, je pense que ça pourrait réunir une bonne liste des trucs à éviter de faire ^^

Pour ma part, j'ai tendance à très vite vouloir tester mon code afin de voir si celui ci fonctionne au lieu de chercher à comprendre ce que je fais et du coup je me retrouve souvent à réviser mon code X temps plus tard en me disant... WTF.

Sinon dans mon équipe, les tares qui me saoulent le plus :

• Mal commenter ses commits : une galère pour retrouver où tel truc a été fait.
  
• Ne pas respecter un standard : une variable en anglais, une autre en français, une avec le type dans son nom, l'autre qui est carrément une phrase...
  
• 0 espaces, 0 indentation, je compresse le plus possible... ark
  

[niahoo]

Moi de ce que je peux voir au boulot, c'est ne pas savoir débugger. Généralement le type / la meuf est paumé-e parce-que « ça marche pas » mais il/elle n'a aucune foutue idée de par quel bout prendre le bouzin pour trouver son erreur.

Parce que en soi, faire des erreurs c'est habituel pour nous, ça fait vraiment partie de la démarche. Mais ensuite il faut savoir les trouver, les comprendre et les corriger ; et éventuellement apprendre à ne plus les faire en premier lieu mais ce n'est pas le plus important.

edit: et je rajouterais aussi : ne pas vouloir lire du code. Je connais une personne que rien ne rebute plus que de devoir aller implémenter un truc sur la base de code de quelqu'un d'autre. Et ce sans savoir si le code de base est potable ou non. Elle va juste trouver tous les moyens du monde pour ne pas le faire. Et quand c'est une erreur à corriger, elle va faire 50 tests de comportements et bouger des machins dans la config plutôt que de prendre une heure avec un bon café pour lire et comprendre 50 pauvres lignes de codes qui lui diront qu'est-ce qu'il se passe.

[Prélude]

Celui qui reste enfermé dans ce qu'on lui a appris.

[Keltaïnen]

Pour moi, un mauvais codeur:
• Réinvente tout, je ne vais pas laisser un autre faire mon taff!
• Ne lis pas la doc, parce que c'est pour les nuls (de même que chercher sur le net)
• N'écoute/ne demande pas aux autres, parce que leur avis est inutile vu qu'ils sont tous nuls (c'est pour ça que je réinvente tout, cf 1•)
• Fait compliqué, parce que ça en jette (et plus un projet semble compliqué, moins on passe pour un con quand on le rate)

Vaste sujet que tu proposes là !
Le 4e (ou dernier, ou 1er après le 3e, ou le carré du 2e, ...) est sûrement le plus énervant et récurrent à mon sens !
Je me souviens avoir galéré à essayé de comprendre des codes d***biles croyant que c'était super alors que non. Et pour s'auto-former avec ça c'est très difficile alors que, quand tu observes le travail d'un bon développeur, c'est étrangement plus limpide.
A mon avis cette dérive est source de beaucoup de maux, notamment dans le monde du PHP. Les gens apprennent avec ce que j’appellerai les "kékédukodage" (c'est beau non ?) et prennent de mauvaises habitudes. S'ils n'ont pas la possibilité d'accéder à d'autres sources d'information (notamment les études), ça peut être préjudiciable pour la qualité de leur travail.
Un jour peut-être je compilerai des atrocités trouvées sur le net, ça ne sera pas trop difficile.

Évidemment les gens qui restent dans leur coin c'est casse-pied mais parfois leur parler suffit à les ouvrir. Je pense que le problème de fond est qu'il y a un vrai soucis d'estime des codeurs les uns envers les autres (un peu comme les conducteurs). Trop souvent j'ai vu des gens se croire les plus fort du monde parce qu'ils connaissent 4 ou 5 langages différents (j'ai sûrement dû être comme ça aussi). Quand chacun arrive à avoir de l'estime pour ses coéquipiers, tout est plus facile. Bizarrement les meilleurs développements que j'ai pu voir ont, systématiquement, été réalisés par des personnes humbles qui ne s'en vantaient pas spécialement.
Après il y a parfois des boulets et il faut composer avec mais on essaie de pas travailler avec en général ;-).

[Xenos]

Un jour peut-être je compilerai des atrocités trouvées sur le net, ça ne sera pas trop difficile.

Eh, ça pourrait être fun! Il existe des livres regroupant les pires bêtises du BAC ou des élèves en général. On pourrait envisager de se faire un recueil des pires âneries du code, tous langages confondus... [A moins que cela n'existe déjà?!]

[Prélude]

N'empêche (et je dit cela sous couvert de mes nombreux apéros de ce soir), qu'un code "mal foutu" peut parfois être une révélation.
En 10 ans de DT d'une agence web, j'ai appris à me remettre en question face à des étudiants tout beaux tout neufx, me sortant des trucs improbables et qui pourtant s'avèreront être des trucs géniaux.
Donc, je m'écrase désormais en voyant du code immonde (enfin, je peste et je vomi dessus, mais en douceur) et je me remet en question.
Cela dit, je déteste et j'espère qu'ils se résurectionneront (cherchez pas...) en cochon dinde pour l'armée, ceux qui utilisent des espaces au lieu des tabulation dans leur code.

[Xenos]

Christ, Mel. Your reasons in b22d127a39dd are weak as hell, and then you come up with THIS shit instead: ... Heck no. In fact, not a fcking way in hell. Look yourself in the mirror, Mel. This patch is ugly, and *guaranteed to result in subtle locking issues, and then you have the gall to quote the "uhh, that's a bit ugly due to some trivial duplication" thing in commit... compared to the diseased abortion you just posted...

L'ouverture d'esprit est une question de relativité x)

[L'Omniscient]

Réinvente tout, je ne vais pas laisser un autre faire mon taff!

Genre, moi ? xD
Non mais c'est toujours intéressant de ré-inventer, ça permet de comprendre des choses, des logiques. J'avoue que je déteste récupérer des gros codes à personnaliser. Des petits bouts de codes ok, mais genre si je veux faire un blog par exemple, je préfère recréer le blog entièrement :o
Enfin bon, tu le sais Xenos :p (Oui je sais, j'irai zieuter du côté de Wordpress ! Mais pour l'instant je trouve même pas le temps et l'énergie de me remettre sur mon jeu, trop de boulot tue le boulot )

[Xenos]

Oui, c'est sympa de "réinventer" et je le fais aussi (mon archi sur les différents jeux hors Wordpress n'est pas basé sur du Framework et j'ai probablement réinventé quelques classes qui existaient) s'il s'agit vraiment de réinventer différemment.
Je trouve un peu dommage en revanche de réinventer ce qui existe exactement déjà. Par exemple, refaire un blog pour refaire un mini-Wordpress, bof... Mais réinventer un blog pour, éventuellement, le faire dans des langages plus exotiques que PHP (et qui n'auraient pas déjà leur équivalent CMS), pourquoi pas.

Disons que justement: t'as pas de temps (ou très peu), alors le perdre en fixant des bogues dans un truc marginal au jeu comme son blog, son forum ou sa page d'accueil, franchement, je trouve cela dommage. Dommage niveau productivité et niveau intérêt (car tu referas les mêmes erreurs que ceux qui avaient fait le CMS, sauf que eux les ont vues et corrigées depuis; mieux vaut aller voir comment ces CMS sont codés, sous la forme de "ah moi je ferai comme ci et comme ça [tu l'écris vite fait dans un coin puis tu lis le code du CMS] ah ben j'avais juste! Ah non en fait, ils ont fait ce truc là... pourquoi...")

Au taff, je te garantis que la relecture de pull request (= lire le code des autres) est vachement plus rapide à faire et instructive que de coder soi-même.