Le pire bout de code que vous ayez vu

**Boojum** · 08/12/2009, 11h10

Personnellement, ce que je reproche le plus à un développeur, ce n'est pas de faire des boulettes, ça arrive (j'aurais tendance à davantage reprocher à leurs responsables de ne pas les avoir assez encadrés). C'est de ne pas tester ce qu'il fait, parce que là c'est carrément un manque de conscience professionnelle.

Un petit exemple de code PL/SQL, réalisé par un gars qui bossait depuis un an sur la même application (J2EE et énormément de PL/SQL)... Syntaxe peut-être approximative, PL/SQL n'est pas ma tasse de thé. Etonnamment, ça n'a jamais marché. Plus étonnant encore, ça n'a été découvert qu'à la mise en production, après que la maintenance soit passée chez nous.

SELECT COUNT(*) INTO v_count FROM table WHERE /* des conditions */;
IF count != -1 THEN
RETURN code_erreur;
END IF;

Quelques petits bouts que j'ai pu voir aussi :

if (machin.equals(null)) { ...

List result = new ArrayList();
for(int i = 0; i<myList.size(); i++) {
result.add(myList.get(i));
if (/* je sais plus quels critères */) {
result.remove(myList.get(i));
}
}

J'ai également eu droit à un superbe bloc d'une centaine de lignes, dont je n'ai jamais été complètement sûr de ce qu'il faisait. Après tests et étude algorithmique, il me semblait bien que la réponse était "absolument rien" (parcours de listes et de maps en tous sens avec ajouts et suppressions pour revenir au final à l'état initial). Faute de temps pour vraiment vérifier, j'ai mis un commentaire pour signaler le fait. Je suis sûr qu'il y est encore aujourd'hui.

En vrac, dans la catégorie style pourri, je demande la JSP d'environ 9000 lignes avec davantage de code Java que de balises. Dans la catégorie "incompétent roi du monde", je connais un "expert technique" (c'est son titre officiel) qui explique que la mutualisation de code c'est mal : si il y a un bug dans une fonction réutilisée, on va le retrouver partout...

**Legarsdelouest** · 08/12/2009, 22h46

Au passage, une que j'ai trouvée dans le code d'un ami :

Code :

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

1
2
3
4
5
6
7
        Dim x As Integer = 0

        While Not x = 51
            Instructions
            x = x + 2

        End While

No comment

**jabbounet** · 09/12/2009, 02h38

Envoyé par Boojum

En vrac, dans la catégorie style pourri, je demande la JSP d'environ 9000 lignes avec davantage de code Java que de balises. Dans la catégorie "incompétent roi du monde", je connais un "expert technique" (c'est son titre officiel) qui explique que la mutualisation de code c'est mal : si il y a un bug dans une fonction réutilisée, on va le retrouver partout...

Il oubli que de factoriser fait qu'il y'a moins de lignes a maintenir et donc peu rendre la tache de maintenance moins difficile.
Si le bug est dans un des algorithme qui n'est pas "mutualisé" on le retrouve dans toutes les implémentations de l'algorithme et qu'il faut donc le corriger partout (risque d'oubli), alors que si c'est factorisé dans une fonction dont le nom permet de comprendre clairement ce que cela fait il n'y a qu'une seul et unique correction à faire.

Personnellement je pense que factoriser correctement son code limite énormément de dégats et que c'est l'une des bases de la programmation.

**Jidefix** · 09/12/2009, 09h40

Envoyé par jabbounet

Personnellement je pense que factoriser correctement son code limite énormément de dégats et que c'est l'une des bases de la programmation.

Je pense pas que tu aie beaucoup de monde à convaincre ici

**Alain Defrance** · 09/12/2009, 10h00

Envoyé par jabbounet

Il oubli que de factoriser fait qu'il y'a moins de lignes a maintenir et donc peu rendre la tache de maintenance moins difficile.
Si le bug est dans un des algorithme qui n'est pas "mutualisé" on le retrouve dans toutes les implémentations de l'algorithme et qu'il faut donc le corriger partout (risque d'oubli), alors que si c'est factorisé dans une fonction dont le nom permet de comprendre clairement ce que cela fait il n'y a qu'une seul et unique correction à faire.

Personnellement je pense que factoriser correctement son code limite énormément de dégats et que c'est l'une des bases de la programmation.

Ca sent le vécu

**ThomasR** · 09/12/2009, 12h53

Envoyé par Legarsdelouest

Au passage, une que j'ai trouvée dans le code d'un ami :

Code :

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

1
2
3
4
5
6
7
        Dim x As Integer = 0

        While Not x = 51
            Instructions
            x = x + 2

        End While

No comment

J'imagine que dans les instructions doit y avoir une condition où il ajoute 1, sinon c'est boucle infinie.

**Legarsdelouest** · 09/12/2009, 13h32

C'est bien une boucle infinie qui est là . Et je crois que j'ai du faire la même faute la toute première fois que j'ai commencé à coder

Ah nostalgie.......

**kpouer** · 09/12/2009, 15h33

Envoyé par Jidefix

Bon alors juste pour la petite histoire, j'ai été promu par ma SSII expert junior webmethods/java au bout d'un an de vie professionelle

Moi je dit pas non m'enfin je le crie pas partout non plus (qu'est ce qu'ils m'ont mis au boulot...)

ah expert junior, ils sont marrant quand même les SSII pour inventer des non-sens, soit on est expert soit on est junior

**Jidefix** · 09/12/2009, 15h36

Envoyé par kpouer

ah expert junior, ils sont marrant quand même les SSII pour inventer des non-sens, soit on est expert soit on est junior

Ben en gros faut interpréter le "expert" comme un "a dejà travaillé sur" et le junior comme un "mais pas trop longtemps donc soyez gentil avec lui"

**deadalnix** · 09/12/2009, 19h45

Envoyé par jabbounet

Personnellement je pense que factoriser correctement son code limite énormément de dégats et que c'est l'une des bases de la programmation.

J'irais bien plus loin : si tu as deux bouts de code qui ont des similarités, c'est que ta conception est foireuse.

J'ajouterais que non seulement le code dupliqué est à corriger partout en cas de bugs (et il y a risque d'oubli) mais que plus le code est utilisé, et dans des cas différents, et plus les bugs seront trouvés rapidement et corrigé rapidement.

Moins le code est exécuté, et plus il y aura des problèmes dedans.

**Pill_S** · 09/12/2009, 20h12

Dans l'absolu ok, mais dans la vraie vie c'est rarement comme ça.

Même avec les meilleures intentions du monde, je me demande quel projet peut se vanter d'être parfaitement implémenté... Ils ont tous des défauts, il faut faire la différence entre les défauts graves qui auront des conséquences à long terme, et les défauts mineurs...

La plupart des défauts sont souvent liés à l'historique d'une application... Les premières versions sont toujours impecs niveau architecture, puis au fur et à mesure des changements/évolutions de specs, les coûts de refactoring seraient trop importants, alors on dégrade la qualité structurelle pour améliorer la qualité fonctionnelle...

C'est toujours facile de critiquer un code. C'est beaucoup plus dur de reprendre un projet en se disant "ok il a son vécu, il a ses défauts, faut bien vivre avec et malgré tout je dois faire mon boulot". Ne pas confondre duplicata de code et code moisi....

**ThomasR** · 09/12/2009, 20h49

Envoyé par Legarsdelouest

C'est bien une boucle infinie qui est là . Et je crois que j'ai du faire la même faute la toute première fois que j'ai commencé à coder

Ah nostalgie.......

Dur dur, rendu à ce stade faut reprendre les bases, ou les continuer

Mais bon, c'est avec des erreurs comme çà qu'on apprend, l'important c'est d'avoir assimilé pourquoi cette erreur et comment la résoudre.

**Legarsdelouest** · 09/12/2009, 21h36

Exactement, je n'aurai pas dit mieux

Et que celui qui n'a jamais codé une application sans avoir de problèmes lors des tests me jettent la première pierre

**el_slapper** · 10/12/2009, 09h25

Envoyé par Legarsdelouest

Exactement, je n'aurai pas dit mieux

Et que celui qui n'a jamais codé une application sans avoir de problèmes lors des tests me jettent la première pierre

j'irais plus loin : si du premier coup la compil passe impec, je trouve ça louche. Et si en plus je ne trouve pas d'erreur fonctionnelle à l'exécution, c'est qu'il y a baleine sous gravillon.....

**Legarsdelouest** · 10/12/2009, 19h37

Envoyé par el_slapper

Et si en plus je ne trouve pas d'erreur fonctionnelle à l'exécution, c'est qu'il y a baleine sous gravillon.....

Je mets 20/20 pour l'expression

**Sébastien Cosson** · 16/12/2009, 19h15

Moi qui ne suis pas DU TOUT comme vous tous développeur professionnel, certaines de vos interventions me laissent un rien rêveur...

Dans la catégorie un rien banale (et déjà évoquée dans ce fil) , je reste toujours étonné de lire des choses comme

Code :

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

while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) { ... }

dans des pages comme
http://php.net/manual/fr/function.fgetcsv.php

Exemple évidemment repris partout...

**metagoto** · 16/12/2009, 19h22

Envoyé par Sébastien Cosson

Code :

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

while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) { ... }

Quel est le problème ?

**Sébastien Cosson** · 16/12/2009, 20h02

Ne serait-ce pas plus simple d'écrire :

Code :

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

while ($data = fgetcsv($handle, 1000, ",")) { ... }

???

**Pill_S** · 16/12/2009, 23h07

Envoyé par Sébastien Cosson

Ne serait-ce pas plus simple d'écrire :

Code :

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

while ($data = fgetcsv($handle, 1000, ",")) { ... }

???

ce n'est pas pareil...

!== est un test d'égalité et de type, pas seulement d'égalité, donc rien de choquant

**deadalnix** · 17/12/2009, 01h49

Dans le premier cas, il faut que $data vaille false pour s'arrêter.

Dans l'autre, la boucle peut s'arrêter si $data vaut "", 0 ou tout autre valeur qui sera castée en false pour effectuer le test.

Le pire bout de code que vous ayez vu

Discussions similaires

Partager

Partager