# Le club des professionnels en informatique > La taverne du Club : Humour et divers > Humour Informatique >  Comment crire le code qui vivra ternellement en entreprise ?

## Stphane le calme

*Comment crire le code qui vivra ternellement en entreprise * 
*et qui sera regard avec crainte et respect ? * 

Dans un processus de dveloppement, plusieurs rgles doivent tre respectes afin que le code puisse tre facilement comprhensible par un autre et donc que la maintenance ne soit pas une preuve digne dun des travaux dHercule. Au vu de certains manquements quil a observs dans les habitudes, Steven A. Lowe, dveloppeur consultant, a rdig un billet satirique qui exalte la culture de lobscurantisme.

Vous vous inquitez parce quun dveloppeur pourrait venir gcher la beaut immacule de votre solution si soigneusement labore ? Ne serait-il pas prfrable dcrire un code que personne  part vous ne serait capable de comprendre, un code qui serait regard avec crainte et respect et qui vivra ternellement dans lentreprise parce que personne naura os le toucher ? Ce nest pas facile, mais avec un peu deffort, vous pourrez dvelopper les habitudes et la discipline pour crire ce code qui va durer ternellement. Comment ?  

*Ne rien tester :*

Les tests sont juste une perte de temps. Ils vous donnent une illusion de confiance et pourraient rvler  une tierce personne comment les choses fonctionnent. Si vous devez crire des tests, faites-le en dernier et affirmez juste quils sont concluants. Ne les crivez surtout pas de prime abord et ne vous en servez pas pour guider la conception ; un code dvelopp de cette faon est trop facile  comprendre et  changer.

*Ne rien modifier :*

Tout dabord sil ny a pas de bug, nessayez pas de colmater de failles. Ensuite, personne na le temps dvoluer en lgance et simplicit. Les dveloppements pilots par des tests, sils sont requis, peuvent tre transforms en une liste dlments affubls de la mention vrifi / pas vrifi.

*crire du code indchiffrable :*

Donnez des noms  vos classes et vos mthodes pour reformuler ce quelles font, pas leur responsabilit. Des noms comme ObtenirLesAchatsPrealablesDuMemeProduit sont trop longs et trop informatifs. RechercherSemblables serait beaucoup mieux. Ou encore Rechercher tout simplement. Cest simple : les noms gnriques a dchire ! Aussi, il faut les utiliser autant que possible.

Il faut utiliser les abrviations et les acronymes pour nommer les interfaces. Il faut utiliser les structures gnriques, pas seulement pour conomiser en temps et en effort, mais galement pour masquer les informations de type. Gardez les structures fortement types pour des ensembles non typs. Faites des tableaux de tout.

De faon occasionnelle (pas trop souvent quand mme), donnez aux variables des noms qui impliquent les mauvais types comme nommer une valeur numrique  virgule flottante MessageTexte. Passez des valeurs en utilisant Object ou String et nencapsulez pas les types de valeur. Si vous devez utiliser des constantes, donnez-leur le mme nom que leurs valeurs ou alors utilisez des noms avec des lettres grecques. 

Les commentaires sont une opportunit pour mal orienter. Aussi, les meilleurs commentaires vont simplement rpter ce que le code fait et restent les mmes aprs que le code soit chang. Gardez  lesprit que la personne qui lit votre code ne doit voir que le reflet de ce quil fait au niveau de limplmentation : louverture de connexions, la recherche des rsultats, le traitement, le retour des rsultats, etc.

*crire du code illisible :*

La lecture du code dautres personnes est une perte de temps et pourrait corrompre votre style cratif. Insistez sur vos propres normes et conventions, mais ne les documentez jamais.

Les espaces sont des gaspillages. Le code sera compil bien plus vite sans tous ces caractres supplmentaires et la sparation pourrait rendre le code plus lisible. Mettez donc tout sur une seule ligne aussi longtemps que vous le dsirez.

La modularit est pour les simples desprit. Vous pouvez garder toute la solution dans votre tte, alors pourquoi la dverser dans de multiples classes et mthodes ?

La complexit est belle et la complexit qui nest pas ncessaire lest encore plus. Cest tellement mieux dutiliser les dernires fonctionnalits du langage qui vous permettent dcrire deux lignes obscures de code au lieu den crire cinq avec des effets vidents. Si jamais quelquun venait  vous interroger sur votre choix, rtorquez que cest plus efficace ou que cest ridicule de ne pas connatre les fonctionnalits sotriques du langage dont vous vous tes servies.

*Ne pas partager les informations :*

Nexpliquez jamais pourquoi votre code fait quelque chose. En fait, vitez les collgues ou au moins vitez de parler des projets sur lesquels vous travaillez ; vos collgues pourraient avoir des suggestions  vous faire, et les suggestions sont tellement ennuyeuses. En plus, vous pourrez accidentellement en dire tellement sur ce que vous faites que vos collgues pourraient le comprendre. Rien de tout ceci nest souhaitable.

Ne faites pas de programmation par paires, jamais, et vitez les codes review. Tout a va juste contribuer  perdre votre temps en questions auxquelles vous avez dj rpondu dans le code. Si vous tes acculs, contentez-vous de dcrire ce que le code fait.

Sil est impratif que vous interagissiez avec quelquun dautre, ne le faites que via des courriels et prenez la peine despacer vos rponses dun ou deux jours. 

Contournez ou transgressez les soi-disant  politiques  ou  normes  qui pourraient interfrer avec vos plans infmes. De toutes les faons, toutes les raisons quils ont voques comme  lamlioration de la qualit  ou  un gain de temps  sont des mensonges. Dautre part, sil vous arrive galement dtre en charge dautres dveloppeurs, vous pourrez mettre des politiques, directives et modifications de processus aussi souvent que vous le souhaitez sans jamais expliquer pourquoi.

Sil y a de nouveaux dveloppeurs dans lquipe, spcialement de nouveaux diplms, laissez-les sans orientation, ne les soutenez pas. Assurez-vous de tourner en ridicule leurs questions ou alors ignorez-les tous en continuant de faire pression sur eux pour quils terminent les projets sur lesquels ils travaillent.

*DevOps ? Ah a non !* 

Les pratiques et les praticiens DevOps doivent tre vits. Mettez tout manuellement en place, selon votre convenance et aussi souvent que vous le souhaiterez. Mfiez-vous des systmes de contrles de code source.

*Vive la mauvaise documentation :*

Si vous tes contraint de rdiger une documentation externe, rdigez-la afin que vous seul soyez capable de la comprendre. Ne dfinissez jamais les acronymes et laissez de ct quelques tapes critiques, aprs tout vous avez d travailler dur pour parvenir  les implmenter, alors pourquoi pas les autres ?

*Ne cherchez rien :*

Cest un signe de faiblesse. Dcouvrez tout de vous-mme en vous basant sur vos principes. Les bibliothques des autres sont suspectes, alors crivez vos propres frameworks.

Si vous appliquez religieusement ces prceptes, vos programmes deviendront comme les zombies de The Walking Dead, toujours en dcomposition, mais jamais tout  fait mort. Vos efforts vont hanter le code base longtemps aprs votre dpart. 

Source : TechBeacon

*Et vous ?*

Que pensez-vous de ces prceptes ? Pouvez-vous en proposer d'autres pour crire un code qui vous survivra ?

Voir aussi : 
 ::fleche::  [Tutoriel] L'art de programmer salement 
 ::fleche::  Forum Humour

----------


## transgohan

On est plus dans les annes 80.  ::mouarf::

----------


## dfiad77pro

a va a ??  ::mouarf:: 



```

```

----------


## eldran64

C'est une news pour apprendre  se faire virer?  ::ptdr::

----------


## dfiad77pro

> C'est une news pour apprendre  se faire virer?


le soucis est justement que dans beaucoup de structure , tu te fais pas virer pour a  ::mrgreen::

----------


## vampirella

> C'est une news pour apprendre  se faire virer?


Il suffit d'avoir suffisamment de bons contacts / des collgues dbords ou qui s'en foutent / pas dous techniquement.
La rentabilit est un facteur aussi. "Tant que a marche, on n'y touche pas" : qui n'a jamais entendu ce paradigme ? Cette expression n'est pas dnu de bon sens capitaliste  court-terme. Pourquoi amliorer quelque chose que le client ne demande pas et qu'il ne remarquera jamais ?
Et puis : pas de bug, pas de ticket. Pas de ticket, pas d'argent. Et pas d'argent ... pas d'argent.  ::): 


Ceci dit, le dernier paragraphe du blog n'a pas t traduit et c'est bien dommage  ::D: 



> On dit souvent qu'il faut crire le code comme si la personne reprenant le projet sera un psychopathe violent connaissant votre adresse. Mais cela est hautement improbable : elle sera bien trop occupe  batailler votre horde de zombies.
> 
> Rappelez-vous juste de ne jamais mettre votre nom.

----------


## eulbobo

Ca me rappelle ce thread
http://www.developpez.net/forums/d14...mmer-salement/

----------


## 10_GOTO_10

> le soucis est justement que dans beaucoup de structure , tu te fais pas virer pour a


Bien au contraire :  Les gens les moins comptents sont systmatiquement affects aux postes o ils risquent de causer le moins de dgts : ceux de managers. 

En appliquant scrupuleusement a, tu as une chance de devenir chef de projet. De toutes faons tu deviens indispensable, donc tu ne sera jamais vir.

----------


## Sodium

Un conseil important a t oubli : rptez-vous.

Je reprends pour le moment pas mal de code d'un ancien collgue. Sur un site, pour un formulaire d'envoi de candidature soit spontane, soit en rponse  une annonce (la seule diffrence tant que l'annonce est rfrence dans le mail gnr dans le deuxime cas) il me fait deux templates de formulaires et deux traitements complets. Un bonheur pour la maintenance.

----------


## Pierre Louis Chevalier

Trs beau troll pour le week end, bravo Stphane, la tu t'es surpass  ::bravo:: 

Le pire c'est que ce qui est dcrit est trs courant  ::aie::

----------


## Invit

> On est plus dans les annes 80.


 ::bravo:: 



```

```

----------


## HippoBaro

```

```

iOCCC FTW

----------


## Invit

> ```
> 
> ```
> 
> iOCCC FTW


  ::f1::

----------


## sevyc64

Tout a ressemble trangement aux pratiques de mes prdcesseurs sur le produit que je maintiens. Sauf que pour eux, j'ai la certitude que a a t fait involontairement par manque de connaissances et comptences.

----------


## CodeurPlusPlus

Le vrai problme est que chacun(e) d'entre nous est persuad(e) qu'il/elle crit du code lisible, maintenable, rutilisable, factoris et bien document... et que ce sont les autres qui font le contraire. Le nul, c'est toujours l'autre.

----------


## Invit

c'est comme avec les utilisateurs, qui n'a jamais entendu un user se plaindre d'avoir plant le systme et un concepteur rpondre  ::furieux::  au lieu de  ::pc::

----------


## G'Optimus

Si tout le monde crivait une code que personne ne peut comprendre je crois l'informatique ne pourra plus bien voluer  .

----------


## air-dex

Pas tout  fait d'accord avec le "_ne pas tester_". Il faut tout de mme s'assurer que le bout de code en question marche. Si a bogue de partout les mainteneurs auront moins de scrupules  faire sauter le bout de code problmatique. Si ces bouts de codes s'installent sur le long terme dans les projets, c'est aussi parce que a marche et que les mainteneurs ne vont pas aller toucher  la bote noire de peur d'aller crer des bugs.  ::oops::

----------


## cervo

::salut:: 
 c'est le parfait cocktail pour tre le premier vir au moindre dysfonctionnement du programme  ::mouarf::  ::mouarf::  ::mouarf::  
En plus faut savoir que si les prdecesseurs avaient ces habitudes celui qui se comporte comme  n'aurait mme pas eu l'ocassion d'crire une seule ligne de code ... ! 
faut toujours penser u prochain  ::D:  ::D:  ::D:

----------


## Invit

Ben en arrtant l'ordonnanceur ?

----------


## ensi_en

Le responsable qualit de mon quipe va trop aimer a. Si le code vivra ternellement c'est parce que a va tuer le responsable qualit pour pouvoir survivre.

----------


## sinople

T'en fais pas il doit probablement avoir une liste semblable pour s'assurer que "sa" qualit ait une dure de vie au moins aussi longue que ton code :-)

----------


## matthius

Bonjour,

Ne trouvez-vous pas tonnant que les logiciels propritaires contiennent 80 % de sources libres ?
Pourtant ce sont les socits prives qui sont les plus nombreuses, largement.

Si vous voulez que vos sources durent longtemps, partagez les si vous le pouvez.
La question est aussi de savoir si votre entreprise possde rellement les sources qu'elle utilise.

Aussi le DRA ou RAD permet de migrer. Donc les composants qui viennent de DELPHI 2 peuvent toujours migrer vers LAZARUS ou DELPHI XE8, s'ils sont utiles.

Aussi les vieilles sources PHP 1 ou PHP 3 sont plus intressantes pour la rapidit que les sources PHP objet.
Les vieux artistes de l'informatique savent que leurs logiciels valent le cot.

Bon courage !

----------


## evil duke

J'aurais d lire un tel post plus tt. Ainsi, je serais pass pour un gnie en classe.

----------


## Lung

a me fait penser  a :
http://www.commitstrip.com/fr/2015/08/04/the-blob-ject/

----------


## JeanMi3000

> 




```

```

Je suis dj dehors. ::salut::

----------


## Sodium

Je vais encore me prendre des downvotes de fanboys, mais niveau code atroce qui vit ternellement il y a tout le cur de Wordpress.
Grant la compatibilit ascendante depuis ses dbuts, tout son code a 10 ans de retard sur les bonnes pratiques actuelles. Quasiment pas de construction objet, des fonctions de centaines de lignes, une hirarchie de fichiers chaotique ...
Il parat qu'un type voulant dvelopper un connecteur PDO pour les interactions avec la base de donnes a finalement laiss tomber devant l'ampleur de la tche.

----------


## eulbobo

> Ben en arrtant l'ordonnanceur ?


L o je suis en ce moment, ils ont fait mieux : ils ont REFAIT un ordonnanceur...
Qui a besoin de Talend qui tourne en permance, d'une base Oracle et de tout plein de requtes chelou pour savoir si quelque chose doit se dclencher...

Tout a pour au final lancer de simples commandes Shell bien entendu...



Du coup,  la question initiale pose dans ce thread, j'ai la rponse absolue
Recrer quelque chose qui existe dj en surcompliquant le problme et si possible en le liant au plus d'lments possibles. Mme si c'est "bien" fait, a sera de toute faon la merde  utiliser/faire voluer/corriger.
Ne jamais chercher des solutions simples et existantes, toujours "innover".

----------


## ustensile

J'adore ce genre de discussion. Je sais que c'est pas bien mais je pense qu'il faut encourager les mauvaises pratiques:
-on aurait pas de boulot
-rien  raconter  ses collgues sur les trucs immondes qu'on a vu
-personne dont on pourrait dire du mal (stagiaire, manager, collgue ou autre victime)
-pas de discussions sur l'art du dveloppement
-pas d'auto-satisfaction quand on dit "quel abruti a pondu ce code?" et qu'on se rend compte que c'est nous(on ne met pas de commentaires,les commentaires c'est mal)
-plus d'aura mystrieuse du mec qui comprend mais pas nous
-plus de prises de ttes donc plus de rflexion donc baisse de niveau donc on devient bte et paresseux

----------


## dfiad77pro

> J'adore ce genre de discussion. Je sais que c'est pas bien mais je pense qu'il faut encourager les mauvaises pratiques:
> -on aurait pas de boulot
> -rien  raconter  ses collgues sur les trucs immondes qu'on a vu
> -personne dont on pourrait dire du mal (stagiaire, manager, collgue ou autre victime)
> -pas de discussions sur l'art du dveloppement
> -pas d'auto-satisfaction quand on dit "quel abruti a pondu ce code?" et qu'on se rend compte que c'est nous(on ne met pas de commentaires,les commentaires c'est mal)
> -plus d'aura mystrieuse du mec qui comprend mais pas nous
> -plus de prises de ttes donc plus de rflexion donc baisse de niveau donc on devient bte et paresseux


*j'ai encore plus vicieux* 

"Tout de faon quoi qu'il arrive on se fait enfiler sur le salaire, alors autant leur faire payer autrement"  ::mouarf::  ::mouarf:: 

Normalement si avec cette argumentation t'es pas vir y'a un soucis ::ptdr::

----------


## Traroth2

Entendu dans plein d'entreprises : "Tant que a marche..."

----------


## eulbobo

> Entendu dans plein d'entreprises : "Tant que a marche..."


Nan, mais a c'est vrai !
A un moment, il faut aussi savoir tre pragmatique. Quand tu as hrit d'une grosse merde et que tu arrives  la faire marcher, la satisfaction est suffisante.

Par contre, faire de la merde en mettant un truc neuf en place, l a tient du sabotage !

----------


## NevilClavain

Je crois que j'applique dj tout a, plus ou moins inconsciemment  ::mrgreen::  ::mrgreen::

----------


## Traroth2

> Nan, mais a c'est vrai !
> A un moment, il faut aussi savoir tre pragmatique. Quand tu as hrit d'une grosse merde et que tu arrives  la faire marcher, la satisfaction est suffisante.
> 
> Par contre, faire de la merde en mettant un truc neuf en place, l a tient du sabotage !


Ben... toutes les merdes ont t *faites*  un moment ou  un autre, tu sais...

Le truc, c'est que souvent, "tant que a marche", a veut dire qu'on a une bouse immonde comme existant, et qu'il est hors de question de recommencer from scratch quelque chose de mieux fait. Il faut absolument maintenir et faire voluer la grosse bouse. Et bien merci du cadeau !  ::massacre::

----------


## eulbobo

> Ben... toutes les merdes ont t *faites*  un moment ou  un autre, tu sais...
> 
> Le truc, c'est que souvent, "tant que a marche", a veut dire qu'on a une bouse immonde comme existant, et qu'il est hors de question de recommencer from scratch quelque chose de mieux fait. Il faut absolument maintenir et faire voluer la grosse bouse. Et bien merci du cadeau !


Je sais, et c'est bien pour a que je dis que parfois on est content quand le vieux truc tout pourri dont on a hrit fonctionne !

Il ne faut pas oublier que quand tu rcupres un truc tout naze, a veut souvent dire que les utilisateurs ont subit pas mal d'anomalie, merdes en tout genres ou autres plantages svres qui leur ont potentiellement dj fait perdre pas mal de temps et d'argent.
Chat chaud craint l'eau froide, tu peux tre sr que ceux qui ont subit ne veulent SURTOUT PLUS y toucher maintenant que a marche. Trop peur de retomber dans la spirale infernale des dfauts qui une fois corrigs font apparatre d'autres merdes... Ou du redveloppement from scratch qui ne reproduit pas les dfaut de la version d'avant mais en apporte de nouveaux 
Oui, je parle de mon exprience avec une V1 toute pourrie mais qui tombait en marche et une V2 qui n'arrivait pas  tourner sans tout casser... J'ai du ngocier longtemps avant d'avoir le droit de remettre les trucs droit au fur et  mesure.


Donc c'est pour a, parfois, le fait que a marche, c'est dj bien !

----------


## Saverok

> Le truc, c'est que souvent, "tant que a marche", a veut dire qu'on a une bouse immonde comme existant, et qu'il est hors de question de recommencer from scratch quelque chose de mieux fait. Il faut absolument maintenir et faire voluer la grosse bouse. Et bien merci du cadeau !


Si c'est pour rester iso primtre, o est l'intrt ?
Il faut penser pragmatique.
C'est peut tre une merde, mais a fait le job et surtout, depuis le temps que a tourne, c'est rentabiliser depuis longtemps.
Ta nouvelle appli toute belle, elle a un coup  amortir et priode de stabilisation qui peut tre relativement longue celons la complexit.

Prend exemple sur une bonne vielle bagnole.
Elle est moche et le moteur fatigue.
Elle tombe en panne de temps en temps mais comme elle est simplissime de mcanique, elle se rpare facilement et pour pas chre.
Mieux encore, tu fais l'entretient toi-mme.
Changer de voiture est-ce vraiment ncessaire ?
Non seulement la voiture neuve cote cher mais en plus, y a tellement dlectronique dedans que tu ne peux plus faire l'entretient toi-mme et en plus, cette mme lectronique est source de panne qui cote ultra cher  rparer (avec une dure de garantie ultra courte).
La dcote est rapide.
Le moteur qui consomme trs peu est super fragile et ncessite plein de filtres qu'il faut changer rgulirement et bien videmment, cotent un bras  chaque fois.
Bref, quand tu poses le tout sur une feuille de compta, tu remarques que ta lubie de nouvelle voiture sera amortie dans 10 ans par rapport  ta vieille bouse qui roule tjrs.
Lgitiment, tu te poses la question de savoir si cet argent ne serait pas mieux investit dans un nouvel outil qui va booster ta productivit asap au lieu de remplacer l'existant.

----------


## eulbobo

> Non seulement la voiture neuve cote cher mais en plus, y a tellement dlectronique dedans que tu ne peux plus faire l'entretient toi-mme et en plus, cette mme lectronique est source de panne qui cote ultra cher  rparer (avec une dure de garantie ultra courte).
> La dcote est rapide.
> Le moteur qui consomme trs peu est super fragile et ncessite plein de filtres qu'il faut changer rgulirement et bien videmment, cotent un bras  chaque fois.
> Bref, quand tu poses le tout sur une feuille de compta, tu remarques que ta lubie de nouvelle voiture sera amortie dans 10 ans par rapport  ta vieille bouse qui roule tjrs.


Et en plus, elle te ment en disant qu'elle ne pollue pas alors que si a se trouve elle pollue toujours autant que ta vieille bagnole !  ::mrgreen::

----------


## Zirak

> Et en plus, elle te ment en disant qu'elle ne pollue pas alors que si a se trouve elle pollue toujours autant que ta vieille bagnole !


True Story !




> Volkswagen, premier constructeur automobile mondial, est accus davoir mis en place un systme de fraude des contrles de la pollution. La firme aurait quip ses vhicules amricains dun logiciel permettant de fausser les mesures.


http://www.liberation.fr/economie/20...gueule_1387207

----------


## Cincinnatus

> Ben... toutes les merdes ont t *faites*  un moment ou  un autre, tu sais...
> 
> Le truc, c'est que souvent, "tant que a marche", a veut dire qu'on a une bouse immonde comme existant, et qu'il est hors de question de recommencer from scratch quelque chose de mieux fait. Il faut absolument maintenir et faire voluer la grosse bouse. Et bien merci du cadeau !


 Il y a quelques temps j'ai d reprendre une application extrieure, libre, et l'adapter pour nos rgles internes. Genre "bouse immonde", je n'ai jamais vu pire. Refaire une appli neuve aurait t un gain de temps, mais il fallait "que a marche" comme la dmo. Sauf que ct Big Ball of Mud, c'tait gratin : gnration de requtes SQL  la vole, le tout dans des fonctions trs longues mlangeant allgrement la page Web, le traitement mtier et les accs  la base (Ah, les joies de PHP/MySQL qui ont permis d'utiliser des fonctions ultraspciques et totalement importables... ::arf:: ). Rien que sparer ces requtes pour les coller dans du simple PDO tait une qute dantesque. Et je n'oublie pas les dizaines de requtes l o 2-3 suffisaient. Tout pour planter le serveur (en pleine dmo, bien sr) avant refonte de la cave au grenier.

 Moralit : certains langages permettent de coder vraiment salement... ::aie::  Avis aux amateurs.

----------


## eric.c

> Entendu dans plein d'entreprises : "Tant que a marche..."


Variante : "Celui qui a perdu sa femme viendra pas la chercher ici" ::mrgreen:: 

Le bordel auto-entretenu est parfois peru comme une mthode pour se rendre indispensable. J'ai vu des spcialistes de la chose  ::lol::  (la bonne nouvelle c'est qu'ils ont fini par prendre la lourde quand quelqu'un a estim que remettre leur boxon en ordre serait moins cher que de continuer  le subir)

----------


## tpericard

Hello,

magnifique illustration de ce que j'ai pu connatre dans les annes 90 o sur une transaction sensible, pour 15k lignes de code (et oui du cobol) 90% taient totalement inutiliss  ::calim2:: 
Au final, il m'a t + simple de tout rcrire de A  Z en m'inspirant quand mme de quelques % du code existants  ::mrgreen::  avec environ 1000 lignes dans la nouvelle version de la transaction.

En fait, c'est tout le problme des maintenances vite faites (budget oblige), o tous les intervenants ajoutent leurs propres bout de code car ils n'ont pas le temps de tout comprendre !!!

a+

----------


## Akiroth

Joli troll :3

----------


## Martin Lestas

+1000
On en a marre des codes lisibles, propres et claires ! On est pas l pour fayoter !

----------


## moueza

::bravo:: 
Supers tes moyens d'obfuscation de code source!

----------


## MichMuchCardo

il suffit en fait d'crire avec un langage que personne ne pratique ou que tout le monde ignore ou ddaigne
il y a 30 ans j'ai cris un programme en DOS qui t utilis (ou est encore utilis) tous les jours, je ne sais plus je suis a la retraite depuis 8 ans
personne n'a jamais essay d'y toucher

----------


## Invit

Rassurant  ::):

----------


## air-dex

Vu il n'y a pas longtemps sur Internet : crire son programme en Javascript et en n'utilisant que les six caractres suivants : [, ], (, ), ! et +. C'est possible.

(source)

----------


## sevyc64

> Vu il n'y a pas longtemps sur Internet : crire son programme en Javascript et en n'utilisant que les six caractres suivants : [, ], (, ), ! et +. C'est possible.


Jolie obfuscation  ::mrgreen::

----------

