Le concours Parnassus Delphi
Récompense le meilleur... du mauvais code !
Le 2016-04-01 10:13:12, par gvasseur58, Responsable Lazarus & Pascal
En ce 1er avril et par des temps tumultueux, un peu d’humour ne peut faire de mal
Du modèle de code censé améliorer une routine alors qu’il la ralentit ou l’estropie jusqu’au programme ambitieux illisible et/ou impossible à maintenir, il y en a pour tous les goûts.
Le grand prix de la compétition revient de juste droit à Alexander Benikowski qui a réussi à écrire une boucle for…to de 14 000 signes ! Mais quand on rêve de cloner Mario, on ne compte pas !
J’avoue cependant avoir une préférence pour les portions de code courtes mais très efficaces quand il s’agit de créer des bogues retors : celui qui a écrit une procédure Break qui cache la procédure originale ou encore celui qui a « optimisé » une routine de comparaison de chaînes à coups de hashcode mal maîtrisé sont mes programmeurs préférés.
Voici la procédure Break à la perversité garantie :
Code : |
1 2 3 4 | procedure Break; begin // Yeah, I'm pretty sure this will break something :) end; |
Source : https://parnassus.co/delphi-bad-code...sults-winners/
-
ShaiLeTrollExpert éminent séniorJ'ai aussi survolé, le sujet, j'aurais juste aimé voir le code complet du Mario, c'est intriguant cette grande boucle !
Par contre, un concours du plus mauvais code : je ne sais pas si je dois en rire ou en pleurer !
En tant que professionnel, je suis confronté à du mauvais code tous les jours,
le dernier en date commité ce vendredi 8 Avril 2016 par un collègue m'hallucine par sa lourdeur :
le code d'origine
Code : 1
2
3
4
5... LModeleFile: string; begin LModeleFile := ExtractFilePath(ParamStr(0))+ModeleFichier; ... DownloadFile(RemoteFileName, LModeleFile) ...
C'est pour privilégier un dossier local où l'utilisateur ou Excel peut lire et écrire
C'est depuis la migration d'application locale de plus en plus lancé via CITRIX
Donc ParamStr(0) retourne chez nous souvent \\server\dossier\module.exe, télécharger un fichier sur un dossier réseau c'est lourdCode : 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... LModeleFile, LTest: string; begin LTest := IncludeTrailingPathDelimiter(GetEnvironmentVariable('APPDATA')); LModeleFile := ExtractFilePath(ParamStr(0))+ModeleFichier; if not DirectoryExists(LTest) then begin ForceDirectories(LTest); end; if DirectoryExists(LTest) then begin LTest := LTest+'\Microsoft'; if not DirectoryExists(LTest) then begin ForceDirectories(LTest); end; if DirectoryExists(LTest) then begin LTest := LTest+'\Templates'; if not DirectoryExists(LTest) then begin ForceDirectories(LTest); end; if DirectoryExists(LTest) then begin LModeleFile := LTest+'\'+ModeleFichier; end; end; end; ... DownloadFile(RemoteFileName, LModeleFile) ...
LTest contient déjà le \ ajouté par le IncludeTrailingPathDelimiter du coup cela fait « AppData\\Microsoft » au lieu de « AppData\Microsoft »
Mais Windows supporte le \\ comme \ dans un chemin
Mauvaise maitrise de ForceDirectories qui inclus l’appel à DirectoryExists
le code simplifié par mes soinsCode : 1
2
3
4
5
6
7
8
9
10… LModeleFile, LTest: string; begin LTest := IncludeTrailingPathDelimiter(IncludeTrailingPathDelimiter(GetEnvironmentVariable('APPDATA')) + 'Microsoft') + 'Templates'; if ForceDirectories(LTest) then LModeleFile := IncludeTrailingPathDelimiter(LTest) + ModeleFichier else LModeleFile := ExtractFilePath(ParamStr(0)) + ModeleFichier; ... DownloadFile(RemoteFileName, LModeleFile) ...
le 11/04/2016 à 11:02 -
guillemouzeMembre expérimenté@Shai : pour moins de lourdeur, j'aurai plutôt vu le PathDelim dans les cas ou son abscence est connue :
Code : 1
2
3
4
5
6
7
8
9
10… LModeleFile, LTest: string; begin LTest := IncludeTrailingPathDelimiter(GetEnvironmentVariable('APPDATA')) + 'Microsoft' + PathDelim + 'Templates'; if ForceDirectories(LTest) then LModeleFile := LTest + PathDelim + ModeleFichier else LModeleFile := ExtractFilePath(ParamStr(0)) + ModeleFichier; ... DownloadFile(RemoteFileName, LModeleFile) ...
le 11/04/2016 à 18:18 -
AndnotorRédacteur/ModérateurOui mais tout n'est pas correct dans ce qu'ils énoncent.First, it’s incorrect: the hash is case-sensitive (though the original code was too.)
La première fonction est sensible à la casse mais pas la deuxième. GetHashCode commence par appeler ToUpper. 70063 correspond à "FOO" et non à "Foo".
Ce qui explique en bonne partie la différence de vitesse.
EDIT:
Adrian Gallero avait relevé l'erreur.Second, what if the string constants change – you need to regenerate the constants
Dommage qu'ils n'expliquent pas, selon eux, la bonne pratique. Ne serait-ce que si on veut appeler cette fonction un million de fois, passer le paramètre en const pour éviter la gestion du compteur de référence.le 01/04/2016 à 12:41 -
ShaiLeTrollExpert éminent séniorPathDelim, oui effectivement dans ce cas, c'est tout à fait opportunle 12/04/2016 à 11:39
-
anapurnaExpert confirmétu peut le récupérer sur sur icile 12/04/2016 à 12:03
-
ShaiLeTrollExpert éminent séniorEn Release, ça mets une erreur sur XE2 que je n'ai encore jamais vu "[MSBuild Erreur] "0" is an invalid value for the "DebugInformation" parameter of the "DCC" task. The "DebugInformation" parameter is of type "System.Boolean"."
En Debug, je n'ai qu'un tas d'erreur de vérification d'étendu ou alors des Violations d'accès
Comme sous Seattle comme c'est indiqué dans le sujet
un petit try except en plus ça affiche difficilement le StartScreen.png
Sous XE7 que j'ai aussi, ça affiche la fin du niveau directement
Dommage, j'aurais aimé voir tourner cette petite foliele 12/04/2016 à 18:19