Les codes les plus hallucinants rencontrés :

[LeGnome12]

Voilà mon souci :
Après avoir fait des études informatiques et un stage dans une boite internationale, je viens d'arriver dans le SI d'une PME.
Et là, ho stupeur ! Je vois des choses hallucinantes !!! Des codes incompréhensibles et pas du tout optimisé !

Alors, je demande au collègue (sans chercher à provoquer de conflits dès mon arrivé) pourquoi il fait comme ça.
La seule réponse a été "Tu sorts tout juste des études le jeunes. Dans le monde réel, on ne fait pas les choses de la même manière !"

Alors je me suis demandé si c'est partout la même chose. A priori non.

Mais, je pense que si vous postez quelque truc hallucinant que vous avez pu voir (fonctions à 100 paramètres, algorithme de calcul de la longueur d'une chaine de caractère...) on peut rigoler un bon peu.

[granquet]

si tu ne connais pas deja; tu peux lire l'excellent The Daily WTF : http://thedailywtf.com/

[el_slapper]

Une bonne partie des codes "hallucinants" ont été faits sous extrême pression. Parfois, certains ont même l'apparence de code propre, mais, quand on y regarde de plus près, tout devient incompréhensible. Et on retrouve une doc d'une personne ayant passé une semaine à essayer de comprendre, et dont la conclusion est "l'algorithme semble aléatoire".....

Je suis sur que je suis coupable de quelques horreurs. Je me rapelle d'au moins une, j'avais un truc un peu complexe à coder très vite, et, en manque d'inspiration, j'ai sorti une usine à gaz(me souviens plus du détail, juste des horribles imbrications illisibles dans tous les sens).

Après, il y a les gnous, gens doués, mais pas pour l'informatique. Et là, on tombe assez vite dans l'horreur. Du genre :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
dim i as variant
for i = 1 to 2
    'traitement numérique des lignes 1 et 2
next i
i = 3
'traitement alphanumérique de la ligne 3
i = 4
'traitement numérique de la ligne, idem traitement 1 et 2
for i = 5 to 7
    'traitement alphanumérique des lignes 5 à 7, idem traitement ligne 4
next i
'le tout continue comme ça jusqu'à plus de 120.....

Et on m'a demandé de rajouter 4 lignes de plus. En trois jours. 2 heures plus tard, j'étais passé de 1000 lignes à 40, avec un petit référentiel des lignes en plus.(et si j'avais passé plus, j'aurais vraiment été un incompétent, je crois).




Celà étant, ce qu'a dit ton collègue, même si dans son cas c'est peut-être faux, sera parfois vrai. On peut être amené à coder volontairement des solutions suboptimales d'un point du code afin de coller au plus près au besoin du client. J'ai eu un jour à générer du XML en cobol. A partir de cobol 3, il existe un ordre XML GENERATE. Il aurait donc semblé logique de l'utiliser. Eh bien non. Parceque la revue de code était assistée par des outils, calibrés pour le cobol 2, qu'il aurait couté fort cher de faire évoluer. Au final, j'ai fait un module "à la main", plus lent, plus moche, mais qui correspondait au besoin. Et qu'ils pouvaient valider avec leur outillage.

Pas mal de choses doivent être désapprises. La solution optimale techniquement doit parfois être mise de coté(pas toujours, heureusement). Parfois même pour des raisons de maintenance : il sera difficille de trouver quelqu'un pour maintenir un code trop élégant, alors qu'on trouvera facilement quelqu'un pour déboguer du code bourrin.

[LooserBoy]

Après un certain nombre d'expériences professionnelles, j'ai découvert que si on dispose de temps, on sera beaucoup plus enclin à faire du code élégant.
Par contre, en cas de manque de temps, il est toujours plus viable de faire du code simple, direct et robuste, quitte à perdre en flexibilité et en maintenabilité.

Il faut parfois choisir la manière de coder la plus rentable en fonction des contraintes posées par le client/l'utilisateur/le chef/le planning.

[souviron34]

Envoyé par LeGnome12

Voilà mon souci :
Après avoir fait des études informatiques et un stage dans une boite internationale, je viens d'arriver dans le SI d'une PME.
Et là, ho stupeur ! Je vois des choses hallucinantes !!! Des codes incompréhensibles et pas du tout optimisé !

Alors, je demande au collègue (sans chercher à provoquer de conflits dès mon arrivé) pourquoi il fait comme ça.
La seule réponse a été "Tu sorts tout juste des études le jeunes. Dans le monde réel, on ne fait pas les choses de la même manière !"

Alors je me suis demandé si c'est partout la même chose. A priori non.

Mais, je pense que si vous postez quelque truc hallucinant que vous avez pu voir (fonctions à 100 paramètres, algorithme de calcul de la longueur d'une chaine de caractère...) on peut rigoler un bon peu.

y'a pas de quoi rigoler..

Même si cela peut s'avérer faux, la réponse du collègue est (le plus souvent) correcte...

a) le monde réel N'EST PAS une théorie

b) le monde réel a des contraintes

c) quelques fois les problèmes sont TRES complexes, et les résoudre en suivant soi-disant les manières optimales les compliquent (le code, la maintenance, la perspective) plus que ne les simplifient...


J'ai déjà fait des fonctions à 3000 lignes.... Je n'en suis pas particulièrement fier, mais je ne voyais pas (et j'ai eu du temps pour réfléchir) de moyen simple de faire autrement sans passer mon temps à jongler avec des sous-fonctions à 40 paramètres....


En bref, la théorie et la pratique sont 2 choses bien différentes...

[7gyY9w1ZY6ySRgPeaefZ]

souviron34, j'ai un peu de mal avec ce que tu dis.

Ok, un petit jeune qui arrive, il a certes ses visions utopiques du métier.

Mais ce n'est pas rare non plus de trouver des personnes d'expériences qui vivent avec des procédures codées il y a 10 ans mais qui ne sont plus en rapport avec l'évolution de la norme et de l'optimisation possible. À la question "pourquoi tu fais comme ça?", il n'est pas rare d'entendre des trucs du genre "c'est pour optimiser le process". Ce qui était vrai à la version N mais 10 ans plus tard à la version N+3, ce n'est plus vrai.

Bref, il faut savoir rester critique sur son code et le code de ses collègues...

[zaventem]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Mais ce n'est pas rare non plus de trouver des personnes d'expériences qui vivent avec des procédures codées il y a 10 ans mais qui ne sont plus en rapport avec l'évolution de la norme et de l'optimisation possible.

Qu'est-ce qui est important? Avoir un code respectant la norme du jour (parce qu'une norme qui change tous les deux où trois ans, c'est juste une mode) ou un code qui fait ce que l'on attend de lui et sans bug (connus)?

[souviron34]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

il n'est pas rare d'entendre des trucs du genre "c'est pour optimiser le process". Ce qui était vrai à la version N mais 10 ans plus tard à la version N+3, ce n'est plus vrai.

Bref, il faut savoir rester critique sur son code et le code de ses collègues...

Entièremnt d'accord sur le fait de savoir rester critique...

Cependant, sur la partie "optimisation" par exemple, qu'est-ce qui n'est plus vrai à la version N+3 ??

C'est parce que les DD ou la RAM ne coûtent pas cher, ou que les processeurs tournent 1000 fois plus vite ???

Et alors ??

Est-ce une raison pour ne pas optimiser ???

[LooserBoy]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Mais ce n'est pas rare non plus de trouver des personnes d'expériences qui vivent avec des procédures codées il y a 10 ans mais qui ne sont plus en rapport avec l'évolution de la norme et de l'optimisation possible. À la question "pourquoi tu fais comme ça?", il n'est pas rare d'entendre des trucs du genre "c'est pour optimiser le process". Ce qui était vrai à la version N mais 10 ans plus tard à la version N+3, ce n'est plus vrai.

Bref, il faut savoir rester critique sur son code et le code de ses collègues...

Il ne faut pas oublier que maintenir ses codes, afin d'être à jour au niveau optimisation, est particulièrement chronophage.

Je me suis dit, je ne sais combien de fois, que je passerais un peu de temps entre deux projets pour "refactorer" les codes existants et, au final, je n'ai absolument pas touché faute de temps.

[Loceka]

J'ai relativement peu d'années d'expériences mais j'ai vu pas mal de codes vraiment moches. Et pourtant j'ai bossé (en SSII) uniquement pour des "grands" groupes : Ministères, France Telecom, Airbus, ...

Un bout de code sur lequel un collègue est tombé sur un utilitaire de log qui faisait une surcouche à log4j (projet interne d'un des grands groupes ci-dessus) :

Code Java :

1
2
3
4
5
try {
  // main du programme
} catch (Throwable t) {
  System.exit(1);
}

En gros : une NullPointerException lancée dans le logger fait planter tout le programme (donc pas seulement l'utilitaire de log). Assez gênant...

[LeGnome12]

Bon alors pour ceux qui se demandent encore pourquoi j'ai poster ce sujet.
Pour ceux qui disent que dans le monde de l'entreprise, les contraintes obligent certaines choses.
Je suis d'accord que le monde de l'entreprise n'est pas celui des études cependant il y a des codes qui ne sont pas concevable.
Par exemple, j'ai vue des requêtes où il était utilisé des group by à la place d'order by !

Un autre exemple :

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
$Rqt = "SELECT pkTable2, pkTable3, pkTable4 FROM table1 WHERE condition";
$db = new SQLConnnect();
$db->ExecuteRqt($Rqt);
$cpt = 0;
WHILE ($rs = $db->MapRecord())
    {
    echo "Ligne num";
    echo $cpt++;
    echo "<BR>";
    $db2 = new SQLConnect();
    $Rqt2 = "SELECT libelle1 FROM table2 WHERE pk=".$rs->pkTable2;
    $db2->ExecuteRqt($Rqt2);
    $rs2 = $db2->MapReccord();
    echo "Libelle 1 = ".$rs2->libelle1."<BR>";
    $db2->CloseConnection();
    $db3 = new SQLConnect();
    $Rqt3 = "SELECT libelle2 FROM table3 WHERE pk=".$rs->pkTable3;
    $db3->ExecuteRqt($Rqt3);
    $rs3 = $db3->MapReccord();
    echo "Libelle 2 = ".$rs3->libelle2."<BR>";
    $db3->CloseConnection();
    $db4 = new SQLConnect();
    $Rqt4 = "SELECT libelle3 FROM table4 WHERE pk=".$rs->pkTable4;
    $db4->ExecuteRqt($Rqt4);
    $rs4 = $db4->MapReccord();
    echo "Libelle 3 = ".$rs4->libelle3."<BR>";
    $db4->CloseConnection();
    }
    // fin
    $db->CloseConnection();

Voilà à peu près comment était construit l'algorithme que j'ai trouvé un jour.
Et encore j'ai rajouté des commentaire.
Donc, que l'on m'explique pourquoi ouvrir et fermer des connexions à la bdd dans une boucle (de plusieurs milliers de lignes). Alors qu'une seule requête et quelques jointures (vraiment simple) fonctionne très bien !!

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par LooserBoy

Il ne faut pas oublier que maintenir ses codes, afin d'être à jour au niveau optimisation, est particulièrement chronophage.

Attention, je ne parle pas de mise à jour du code existant mais d'utiliser des "optimisations" d'un autre âge sur du nouveau code.
En bd, j'ai vu des hint pour "optimiser" des requêtes qui n'avaient aucune raison d'être de nos jours, surtout quand on ne sait même pas à quoi ça sert. "On m'a montré à faire comme ça quand j'ai commencé à travailler, y a 10 ans" n'excuse pas de se renseigner un minimum...

[RomainVALERI]

En lisant le titre du post j'ai immédiatement pensé à ça ^^ (pardon à tous ceux qui connaissent déjà, ça date un peu faut bien avouer. Pour les autres, attention hallucination droit devant )

Mais... vu la tournure qu'a pris la conversation je suis peut-être hors-sujet ?

[LeGnome12]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Mais ce n'est pas rare non plus de trouver des personnes d'expériences qui vivent avec des procédures codées il y a 10 ans mais qui ne sont plus en rapport avec l'évolution de la norme et de l'optimisation possible. À la question "pourquoi tu fais comme ça?", il n'est pas rare d'entendre des trucs du genre "c'est pour optimiser le process". Ce qui était vrai à la version N mais 10 ans plus tard à la version N+3, ce n'est plus vrai.

Cela reprend très bien l'idée de mon post.

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Bref, il faut savoir rester critique sur son code et le code de ses collègues...

Je suis totalement d'accord, le code parfait n'existe pas. Lorsque mon collègue pose un regard critique sur mon code, je l'écoute et je sais prendre note.

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Ok, un petit jeune qui arrive, il a ses visions utopiques du métier.

Ca résume le problème que je rencontre depuis mon arrivé dans l'entreprise. Tout ce que je peux dire est faut. Mes formations ne sont pas du tout reconnu ("ho, aujourd'hui tout le monde a le bac S").

Il m'est arrivé de prosposé des idées qui ont été immédiatement regetées ("C'est complètement stupide !") sans même m'avoir laissé finir ma phrase. Deux mois après, mon collègue trouve l'idée sur un site et remarque que c'est exélent ! Lorsqu'il la partage et que je fais remarqué que c'est ce dont j'avais parlé, il répond avec mauvaise fois : "Mais non, c'est pas du tout ça."
(et dire que lors de mon entretient on me demandait d'être force de proposition)

Après ça, lorsque je trouve des tentatives de réinvanter la roue, je ne peux qu'en rire et je suis désolé si ça choque !

[souviron34]

Envoyé par RomainVALERI

En lisant le titre du post j'ai immédiatement pensé à ça ^^ (pardon à tous ceux qui connaissent déjà, ça date un peu faut bien avouer. Pour les autres, attention hallucination droit devant )

Je ne connaissais pas et c'est excellent ..

Merci

Envoyé par LeGnome12

Ca résume le problème que je rencontre depuis mon arrivé dans l'entreprise. Tout ce que je peux dire est faut. Mes formations ne sont pas du tout reconnu ("ho, aujourd'hui tout le monde a le bac S").

Pôv pitchoun !!!

[Médinoc]

Je ne comprends pas le dillemme "élégant" contre "simple, direct et robuste". Car pour moi, "élégant" signifie "simple, direct et robuste" (et par extension, maintenable).

C'est le code "intelligent" ("clever" en anglais) qu'il faut craindre.

Ce n'est pas le code non-optimisé qui est mauvais: c'est le code inutilement compliqué, moins efficace qu'un truc plus simple. La réimplémentation maison d'une fonction de la bibliothèque standard comme Convert.ToDouble(). Le test de vérité.

[RomainVALERI]

Envoyé par granquet

si tu ne connais pas deja; tu peux lire l'excellent The Daily WTF : http://thedailywtf.com/

Envoyé par Médinoc

C'est le code "intelligent" ("clever" en anglais) qu'il faut craindre.

Ce n'est pas le code non-optimisé qui est mauvais: c'est le code inutilement compliqué, moins efficace qu'un truc plus simple. La réimplémentation maison d'une fonction de la bibliothèque standard comme Convert.ToDouble(). Le test de vérité.

Bon ben on est tous abonnés au DWTF ou quoi ?

C'est quoi vos ptits noms là-bas, tiens ? (moi c'est toshir0 ^^)

[j.peg]

Envoyé par LooserBoy

Il faut parfois choisir la manière de coder la plus rentable en fonction des contraintes posées par le client/l'utilisateur/le chef/le planning.

Pourquoi parfois? qu'est ce qui justifierait de ne pas choisir la manière la plus rentable en fonction des contraintes?
Qui est prêt à payer pour de la sur-qualité?

[LooserBoy]

Envoyé par j.peg

Pourquoi parfois? qu'est ce qui justifierait de ne pas choisir la manière la plus rentable en fonction des contraintes?

Je pensais, par exemple, aux développements que j'ai pu avoir en tâche de fond, parfois en complet sous-marin, pour améliorer le fonctionnement de l'équipe en développant des outils internes, pour remplacer un existant handicapant et fortement ancré dans l'historique de l'entreprise donc ne pouvant pas être remplacé sans avoir une solution "clé en main" et "en béton", ou acquérir la maitrise d'une technologie/technique sans avoir d'application immédiate,...

Il n'y avait pas de contraintes de temps, ni de cahier des charges, un besoin encore mal délimité,... Se baser seulement sur un concept laisse énormément de liberté sur les choix d'architecture, de technologie,... Il n'y a pas de notion de rentabilité à mes yeux dans ce genre de travail, c'est de la recherche et développement.

Tout comme la recherche scientifique, certaines de ces recherches aboutiront sur une exploitation réelle et rentable alors que d'autres finiront dans la poussière au fond du placard, pour peut-être être ressorties un peu plus tard, le moment opportun...

Envoyé par j.peg

Qui est prêt à payer pour de la sur-qualité?

[exagération]Combien de développements m'a-t-on confié devant faire certaines choses mais si ça pouvait aussi faire le café et ne pas prendre plus de temps à réaliser, ce serait encore mieux...[/exagération]
S'il n'y a pas de surcoût, je ne vois pas pourquoi on refuserait systématiquement la "sur-qualité".

Note: La notion de sur-qualité me pose un problème car je pense qu'on ne dois pas penser à la même chose.

Si c'est dans le sens pourquoi faire simple alors que l'on peut faire compliqué sans que ça n'apporte rien, je suis d'accord, c'est inutile.

Si par contre, c'est faire un peu réfléchi pour que ce soit plus simple ensuite, je vois vraiment pas le problème. Sans tomber dans l’excès et faire dans le très compliqué sans gagner en simplicité, bien-sûr.

[straasha]

sinon j'avais rencontré ça chez mon ancien client :

Code Fichier.h :

1
2
3
4
5
6
7
8
9
10
#ifdef CONSTANTE_A
...
du code sans entête de fonction ni quoi que ce soit
...
#endif
#ifdef CONSTANTE_B
...
déclarations comme on en trouve dans un .h classique
...
#endif

Code Fichier.c :

1
2
3
4
5
6
7
8
9
10
11
...
au debut :
#define CONSTANTE_B
#include "fichier.h"
#undef CONSTANTE_B
...
plus loin au milieu d'une fonction :
#define CONSTANTE_A
#include "fichier.h"
#undef CONSTANTE_A
...

notez que j'ai simplifié et qu'il y avait en réalité 3 ou 4 sections de codes dans le .h, chacune encadrée par une constante différente et utilisée de cette manière à différents endroits du .c.
le pire c'est que ça marchait très bien, par contre pour relire...