Un truc une fois :
La variable était de type Booléen ! Le pire était qu'il y avait du code dans le Else case ! :roll:Code:
1
2
3
4
5
6
7 Case une_Variable Of True : //Code False : // Else Case //Code End
Version imprimable
Un truc une fois :
La variable était de type Booléen ! Le pire était qu'il y avait du code dans le Else case ! :roll:Code:
1
2
3
4
5
6
7 Case une_Variable Of True : //Code False : // Else Case //Code End
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 :
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.....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
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 :
En bref, du pur code spaghetti, mais à l'époque ils n'avaient pas le choix. J'ai douillé pour faire le reverse engineering.....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.
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++
Le célèbre convertisseur de chemin windows->unix en Java :
Code:
1
2
3
4 String convertWindowsPathToUnix(String path) { path.replace('\\', File.separatorChar); return path; }
Dommage que les chaines ne soient pas mutables en Java. :aie:
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
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 :roll: )
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)
On voit souvent des codes du genre :
Alors que ceci équivaut à :Code:
1
2
3
4
5
6
7 if(empty($var)){ return true; } else{ return false; }
Code:
1
2 return empty($var);
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 }
avec en plusCode:
1
2
3
4
5
6
7
8 function Char* toto(){ machaine char* return machaine; } trucchaine=toto() printf(truchaine) //dump mémoire
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 :cry:
donc quand je vois des erreurs de code je ne jette pas la pierre (pierre) mais j'essaye d'expliquer l'incongruité du code.
Une chose me revient immédiatement à l'esprit.
Dans les méthodes de différentes classes, j'ai pu voir le blindage ultime:
Enfin bon, on a tous fait à un moment ou un autre des choses pourries... OSEFCode:
1
2
3
4 if(this == null) { //envoie la sauce }
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.
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 :D
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
Moi j'ai vu cette déclaration de variable :
Véridique !Code:
1
2 bool true = 1; bool false = 0;
Dans cet exemple Java, l'objet "service" est une instance du contrat d'interface d'un web service :
C'est performant !Citation:
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();
...
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
:calim2:
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.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*/ }
Mais le pire est à venir . C'est l'usage de ces constantes dans le programme.
On remarquera l'usage mixte de constante et de nombre pour les indices du tableau.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");
Et ca continue de plus belle.Dans une même instruction, 3 manières de représenter un nombre.Code:monBean.setChampFoncctionnel("1".equals(valeur.substring(2, NombresConstantes.CONST_3)));
Que s'est il passé dans la tête du développeur ?
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 à :
Tous les modules étaient écrits comme ça (la peur des espaces blancs sans doute 8O).Code:Dim t As Date: Debug.Print "début": t = DateAdd("s", 10, Now()): While t > Now(): Wend: Debug.Print "fini"
Le client était étonné que je mette deux jours à déboguer un truc tout con :mouarf:
En java :
On aurait pu sortir la déclaration de la variable sb de la boucle.Code:
1
2
3
4
5 for(...) { StringBuffer sb = new StringBuffer() ; sb = new StringBuffer() .... }
Et l'instancier deux fois de suite :?
Le classic :
Ca m'étonne pas qu'on dise que Java est lent quand on voit ça :lol: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) ; }
Ah, précision, la personne était programmeuse Java depuis 5 ans :calim2: