Le pire bout de code que vous ayez vu

[Louis Griffont]

Un truc une fois :

Code :

1
2
3
4
5
6
7
Case une_Variable Of
   True : //Code
  False : //
  Else Case
    //Code
End

La variable était de type Booléen ! Le pire était qu'il y avait du code dans le Else case !

[el_slapper]

Envoyé par sleepy2002

(.../...)
N'oublions pas que c'est en forgeant qu'on devient forgeron

Exact. Le pire que j'ai vu a été fait par un informaticien, disons, improvisé. C'est d'ailleurs le premier code professionnel sur lequel je suis tombé. J'ai vu mieux depuis, celà va sans dire.

contexte : une équipe d'homologation contient dans ses rangs une superbête en programmation qui fait plein de macros VB pour Excel qui facilitent grandement la vie de tout le monde. Puis la superbête se barre en mauvais termes, en effaçant une partie de ses codes. Un homologateur, jamais formé pour programmer, essaye de reprendre..... Il doit faire un traitement sur des lignes de tableau, mais c'est pas le même suivant que la valeur est alpha ou numérique.

et ça donne un truc du genre :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
for i = 1 to 3
     (traitement alpha)
next i
for i = 4 to 5
     (traitement num)
next i
for i = 6 to 6
     (traitement alpha)
next i
for i = 7 to 9 
     (traitement num)
next i
for i = 10 to 13
     (traitement alpha)
next i
for i = 14 to 15
     (traitement num)
next i
for i = 16 to 16
     (traitement alpha)
next i
for i = 17 to 20
     (traitement num)
next i
etc.......jusqu'à la ligne 110

les traitements étant faits dans leur intégralité à chaque fois.....et étant toujours identiques. Mais ça marchait! Quand on m'a demandé d'ajouter quelques lignes, je me suis permis d'industrialiser tout ça.....

Mais il est effectivement difficile de jeter la pierre à quelqu'un de non formé, lâché dans un contexte ou l'aide en ligne de VB pour Excel avait été désactivée, ou internet était inaccessible, bref, ou l'auto-formation était des plus délicates.



EDIT

J'oubliais une autre horreur, celle-ci datant du temps ou le Cobol ne permettait pas de programmation structurée, et ou seul le GO TO permettait de faire des embranchements. Ca donnait un truc du genre :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
A1.
MOVE 1 TO I.
A11.
(traitement sur I)
ADD 1 TO I.
IF I < 10
    GO TO A1
END-IF.
A121.
MOVE 0 TO J
A122.
ADD 1 TO J.
IF I < VALEUR-QUELCONQUE
    GO TO A122
END-IF.

En bref, du pur code spaghetti, mais à l'époque ils n'avaient pas le choix. J'ai douillé pour faire le reverse engineering.....

[vintz72]

Envoyé par LordBob

Je rigolais toujours en voyant ce genre de code jusqu'à y à quelques mois où j'ai repris une application que j'ai développé y à presque 1,5 ans maintenant et ou j'ai écrit presque la même chose, mais en pire...

Code :

Je me demande bien ce qui à pu me traverser l'esprit quand j'ai écrit ça! J'ai même honte de le poster ce soir...

Ce genre de code s'explique avec les langages qui ne sont pas pourvu de directives de compilation. Par exemple en C, on fait un #if 0 #endif autour d'un bloc de code pour le désactiver (temporairement). En Java, on fait un "if (0)"... Le truc, c'est quand on le réactive pour de bon, il faut faire le ménage plutôt que laisser le "if (1)"...

[Alain Defrance]

Envoyé par vintz72

En Java, on fait un "if (0)"...

Compilation fail.

[adiGuba]

Envoyé par vintz72

Ce genre de code s'explique avec les langages qui ne sont pas pourvu de directives de compilation. Par exemple en C, on fait un #if 0 #endif autour d'un bloc de code pour le désactiver (temporairement). En Java, on fait un "if (0)"... Le truc, c'est quand on le réactive pour de bon, il faut faire le ménage plutôt que laisser le "if (1)"...

En Java ce serait plutôt des if(true) ... mais je confirme que cela peut être très pratique pour activer/désactiver rapidement un petit bout de code

De plus cela n'impacte pas le code généré :

• Le if(false) sera complètement supprimé du code généré.
• La condition du if(true) sera supprimé (inutile de l'évaluer), mais son contenu sera bel et bien généré dans le code (comme s'il n'y avait jamais eu de if)

Sinon, une chose qui me titille souvent en Java, même si ce n'est pas vraiment une erreur grave : le fait de vouloir "initialiser" les objets avant de les utiliser. Par exemple :

Code :

1
2
3
String str = new String(); // Le new est complètement inutile ici
str = getString();

a++

[pseudocode]

Le célèbre convertisseur de chemin windows->unix en Java :

Code java :

1
2
3
4
String convertWindowsPathToUnix(String path) {
    path.replace('\\', File.separatorChar);
    return path;
}

Dommage que les chaines ne soient pas mutables en Java.

[kpouer]

Envoyé par kev42100

J'ai vu aussi le if(true) dans Mitaka, un logiciel astronomique de 3D temps réel ............

Ca serait pas tout simplement un générateur de code automatique qui aurait fait ca, comme pour physx ?
Par exemple le générateur de parseur JavaCC fait parfois des if (true).
C'est moche mais c'est éliminé par les compilateurs heureusement

Envoyé par xtope

Je dis peut-être une bêtise (faut pas m'en vouloir, parfois je suis crevé après le boulot..) mais ce bout de code m'a l'air tout a fait fonctionnel.
En Java les paramètres ne sont passés par valeur que pour les types primitifs, pour les objets c'est par référence.
Ici donc c'est bien par référence que c'est passé.

Non, c'est une copie de la référence originale qui est passée, donc ca pointe bien sur le même objet mais le passer à null ne va pas fermer le stream, et surtout l'appelant de cette méthode aura toujours sa référence vers le stream en question

Sinon le truc le plus moche que j'ai vu c'était fait en php, le type devait a partir d'un serveur php récupérer des fichiers sur un serveur linux via ftp.
Mais n'y arrivant pas, il a finalement décidé d'installer Samba sur le serveur linux et de mettre dans le code php son login/pass du domaine Windows de l'entreprise (sachant que bien sur le produit ne doit pas tourner chez nous mais chez les clients auxquels on vendra le soft )

[getz85]

Envoyé par Gordon Fowler

Quelquefois ce "pire code" n'est pas trop méchant. Il relève juste du non sens :

Code :

Ou comment calculer simplement la longueur du tableau à partir de la longueur ("a.length") qu'on a dès le départ...

C'est pas ça qui m'a choqué dans ton code au début, c'est plutôt le i++

=> "i undefined variable"

[Jonas0122]

Envoyé par Alain Defrance

Bonjour,



C'est une facon de cacher l'implémentation. Le fait de créer cette indirection n'est pas une mauvaise pratique au contraire. Ici on voit que ca ne sert à rien, mais ca évite de refactorer ton code une fois que tu auras des modifitations à faire au moment de la récupération de tes champs post. A ce moment là tu va finir par faire pareil que lui pour factoriser ton code, sauf que tu l'auras pas prévu à l'avance. Là au moins c'est tout prêt, lui l'a prévu ...

Oui et non, on peux aussi traiter tous les POST avec un simple foreach sur cette variable mais bon, c'est comme dans tous les langages, ya 10 mille façons de faire..

Je pense juste que sans connaitre la totalité du programme on peux pas dire que c'est "un bout de code horrible", et après chacun sa façon de programmer, perso ca m'arrive de faire un extrait de la var $_POST pour obtenir des $p_nomduchamp (c'est toujours bon de gratter 4/5 caractères, quand ta 50 champs à traité ca fais la diff)

[ThomasR]

On voit souvent des codes du genre :

Code :

1
2
3
4
5
6
7
if(empty($var)){
    return true;
}
else{
    return false;
}

Alors que ceci équivaut à :

Code :

1
2
return empty($var);

[jefcrac]

en 25 ans j'ai vu pas mal de choses mal écrites mais j'en ai écrit aussi pas mal

Code :

1
2
3
4
5
6
7
 if(a=1) {
// y a de quoi se poser des questions
}...
else {
//hum hum
}

Code :

1
2
3
4
5
6
7
8
function Char* toto(){
machaine  char*
return machaine; 
}

trucchaine=toto()
printf(truchaine)
//dump mémoire

avec en plus
modifier un program
compiler le program
a.out modification pas prise en compte
plus de 2 heures avant de comprendre l'utilité du PATH j'en suis pas fier

et le meilleur
faire un code récursif pour écrire un fonction dos de suppressions des fichiers
compiler
tester
et me retrouver avec un disque vide

donc quand je vois des erreurs de code je ne jette pas la pierre (pierre) mais j'essaye d'expliquer l'incongruité du code.

[Heimdal]

Une chose me revient immédiatement à l'esprit.
Dans les méthodes de différentes classes, j'ai pu voir le blindage ultime:

Code :

1
2
3
4
if(this == null) {
//envoie la sauce
}

Enfin bon, on a tous fait à un moment ou un autre des choses pourries... OSEF

[Mac LAK]

Envoyé par kpouer

Ca serait pas tout simplement un générateur de code automatique qui aurait fait ca, comme pour physx ?
Par exemple le générateur de parseur JavaCC fait parfois des if (true).
C'est moche mais c'est éliminé par les compilateurs heureusement

Yep, j'ai déjà vu ça aussi dans du code généré à partir de templates, où on va laisser un test toujours faux / vrai après (dés)activation de certains modules pour éviter un traitement du fichier un peu trop lourd à faire (= rechercher la fin du bloc notamment).

C'est pas très joli en effet, mais si cela découle réellement d'une génération automatique de code, c'est moins nuisible. Il faut alors plutôt se poser la question de savoir pourquoi ils ne font pas travailler sur le template d'origine et/ou pourquoi ils modifient manuellement du code généré...

Si par contre c'est du code 100% manuel, alors là, oui, c'est crade au possible... Sauf s'il y a du code mort laissé exprès pour la trace "historique" des évolutions ou du debug : tous les langages ne possèdent pas non plus de préprocesseur.

[Jidefix]

Ben personnellement j'ai honte de le dire mais le pire bout de code que j'aie jamais vu ben... je crois que c'est moi qui l'ai fait

Je l'ai remplacé depuis mais en gros c'était en java, je voulais représenter des données compliquées, triées etc. et les envoyer à une jsp pour les représenter en html. Pour une raison qui m'échappe encore aujourd'hui créer une classe répondant à mon besoin ne m'a même pas effleuré l'esprit...
Ca a fini en imbrication de HashMap TreeMap, HashSet, et TreeSet (oui oui les quatres), à environ 8 niveaux.
Ca marchait hein... enfin tant qu'on poussait pas trop les données à représenter :S

[yodaime]

Moi j'ai vu cette déclaration de variable :

Code :

1
2
bool true = 1;
bool false = 0;

Véridique !

[pjv]

Dans cet exemple Java, l'objet "service" est une instance du contrat d'interface d'un web service :

Int ExitCode = service.getUneMethodeDeMonWebService(param1, param2, etc.).getExitCode();
List<Class> listeObjets = service.getUneMethodeDeMonWebService(param1, param2, etc.).getListeObjets();
String attribut1 = service.getUneMethodeDeMonWebService(param1, param2, etc.).getAttribut1();
Long attribut2 = service.getUneMethodeDeMonWebService(param1, param2, etc.).getAttribut2();
MaClasse attribut3 = service.getUneMethodeDeMonWebService(param1, param2, etc.).getAttribut3();
...

C'est performant !

[Tofalu]

A l'instant :

Code :

1
2
3
4
5
6
A=1
X=1
While x<13
"Me.ABG" & X & ".value" = A
A = A+1
Wend

• Aucune déclaration
• La chaîne "Me.ABG" & X & ".value" est destinée à être comprise par magie à l'exectution comme la propriété d'un objet et non une chaine
• On incrémente A et on teste X pour sortir de la boucle

[phantomass]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public interface NombresConstantes {

	/** 0 */
	int CONST_0 = 0;

	/** 1 */
	int CONST_1 = 1;

	/** 2 */
	int CONST_2 = 2;

	/** 3 */
	int CONST_3 = 3;

	/** 4 */
	int CONST_4 = 4;

	/** 5 */
	int CONST_5 = 5;

	/** 6 */
	int CONST_6 = 6;

	/** 7 */
	int CONST_7 = 7;

	/** 8 */
	int CONST_8 = 8;

	/** 9 */
	int CONST_9 = 9;

	/** 10 */
	int CONST_10 = 10;
/* Et ça continue jusqu'à 100*/
}

Déjà une une classe de constante pour référencer des nombres entiers, c'est très difficile d'y trouver un intérêt.
Mais le pire est à venir . C'est l'usage de ces constantes dans le programme.

Code :

1
2
3
4
5
6
7
8
9
String[] valeurs = new String[NOMBRE_COLONNE];               
valeurs[0] = rs.getString("ChampA");                         
valeurs[1] = rs.getString("ChampB");                         
valeurs[2] = rs.getString("ChampC");                         
valeurs[NombresConstantes.CONST_3] = rs.getString("ChampD"); 
valeurs[NombresConstantes.CONST_4] = rs.getString("ChampE"); 
valeurs[NombresConstantes.CONST_5] = rs.getString("ChampF"); 
valeurs[NombresConstantes.CONST_6] = rs.getString("ChampG"); 
valeurs[NombresConstantes.CONST_7] = rs.getString("ChampH");

On remarquera l'usage mixte de constante et de nombre pour les indices du tableau.
Et ca continue de plus belle.

Code :

monBean.setChampFoncctionnel("1".equals(valeur.substring(2, NombresConstantes.CONST_3)));

Dans une même instruction, 3 manières de représenter un nombre.

Que s'est il passé dans la tête du développeur ?

[Népomucène]

Il y a quelques temps, j'ai été appelé pour modifier un programme en VBA (une application Access)
Manifestement, le mec qui avait codé voulait économiser sur les lignes de code ;
et plutôt que d'aller à la ligne pour chaque instruction, j'ai eu droit à :

Code :

Dim t As Date: Debug.Print "début": t = DateAdd("s", 10, Now()): While t > Now(): Wend: Debug.Print "fini"

Tous les modules étaient écrits comme ça (la peur des espaces blancs sans doute ).
Le client était étonné que je mette deux jours à déboguer un truc tout con

[bubulemaster]

En java :

Code :

1
2
3
4
5
for(...) {
StringBuffer sb = new StringBuffer() ;
sb = new StringBuffer()
....
}

On aurait pu sortir la déclaration de la variable sb de la boucle.
Et l'instancier deux fois de suite

Le classic :

Code :

1
2
3
4
5
6
7
private int longueur(List liste) {
    return liste.size();
}

private void ajouter(List liste, String chaine) {
    liste.add(chaine) ;
}

Ca m'étonne pas qu'on dise que Java est lent quand on voit ça

Ah, précision, la personne était programmeuse Java depuis 5 ans