Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».
Le problème se situe entre la chaise et le clavier : soumettez vos histoires, donnez votre avis !
Ce site n'est pas le site original pebkac.fr. Je publie ici la liste des PEBKAC que j'ai pu sauvegarder avant que le site original ne soit mis hors ligne.
On me demande d'évaluer le code d'un jeune embauché. Voici ce que je trouve :

bool flag;
is_interface_up(&flag);
if (flag)
{
  /* (du code) */
}
else if (!flag)
{
  /* (du code) */
}
else
{
  // Juste au cas où !
  printf("On ne devrait jamais arriver ici !");
}

J'ai donc demandé deux choses à l'auteur de ce code :
- Atteindre 100% de couverture de code en test unitaire,
- Compiler avec « treat warnings as errors » (le compilateur émet un « unreachable code »).
PEBKAC.
PEBKAC #6763 proposé par FBM le 25/01/2013 | 26 commentaires | 👍🏿 👎🏿 +142
Si c'est multithreadé il est toujours possible que le flag soit modifié entre les 2 premiers tests…

Mais bon…
Commentaire #75654 écrit par pbx le 25/01/2013 à 17h50 | 👍🏿 👎🏿
J'aime bien aussi la gestion d'erreur avec seulement un timide printf.
Commentaire #75657 écrit par Shirluban le 25/01/2013 à 17h54 | 👍🏿 👎🏿
On est jamais trop prudent.
Commentaire #75665 écrit par Yukotso le 25/01/2013 à 18h22 | 👍🏿 👎🏿
Mais c'est pas un pebcak : c'est un mauvais programmeur.
Commentaire #75672 écrit par mais... le 25/01/2013 à 18h38 | 👍🏿 👎🏿
Oui mais non.

Car dans ce cas, il faudrait déclarer la variable comme étant volatile :
volatile bool flag;

Sinon, l'exécutable ne vérifiera la valeur de flag qu'une seule fois, puisqu'elle est déclarée comme ne pouvant pas changer hors du thread d'exécution courant.

Petit test d'ailleurs, pour ceux qui voudraient voir : créez un programme avec un thread qui ne fait que ça :

int flag = 0;

while (!flag) /* rien */;
printf("Sorti de la boucle");

Et un autre thread qui attend disons 15 secondes et qui fait :
flag = 1;

Compilez en mode debug (gcc -g truc.c -o truc), et exécutez : vous verrez "Sorti de la boucle".

Maintenant, compilez en mode O2 (gcc -O2 truc.c -o truc), et exécutez : votre programme ne terminera jamais. La variable n'étant pas volatile, le code ne la lit qu'une fois (en entrant dans le while).
Commentaire #75673 écrit par FBM le 25/01/2013 à 18h41 | 👍🏿 👎🏿
Tu programmes debout, toi ?
Commentaire #75674 écrit par contrebasse le 25/01/2013 à 18h41 | 👍🏿 👎🏿
Et je rajoute que, le compilo n'étant pas idiot, quand on a if (condition) else if (!condition) else truc;

Il ignore complètement le else (en générant un warning "unreachable code").
Commentaire #75675 écrit par FBM le 25/01/2013 à 18h42 | 👍🏿 👎🏿
-O2 ça sert pas qu'a "optimiser" le code alors. C'est beau...
Commentaire #75677 écrit par Hum. le 25/01/2013 à 18h56 | 👍🏿 👎🏿
Le mec il a peut être fait un langage objet et travaillé qu'avec des objets booléens qui peuvent avoir trois états: Vrai, Faux, Nul.

En fait le langage objet c'est comme la science: it works Bitches!
Commentaire #75678 écrit par Hum. le 25/01/2013 à 18h58 | 👍🏿 👎🏿
chrsssh Dechrssssh d'entchrssshde commchrrrsssSSSSSSSSSSSSHHHHHHHHGZZZZCHRRSSSSSSVous m'enSSSSSSSSSSSSSS?

Rah, c'est pas fiable ces machins...
Commentaire #75681 écrit par ROB le 25/01/2013 à 19h17 | 👍🏿 👎🏿
Je suppose que tu veux dire FileNotFound.

http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
Commentaire #75697 écrit par check_ca le 25/01/2013 à 19h43 | 👍🏿 👎🏿
Sauf si le code lui fait faire une synchro comme avec un sleep par exemple :)
Bon pour le !flag, il ne faut pas pousser quand même XD
Commentaire #75698 écrit par but2ene le 25/01/2013 à 19h44 | 👍🏿 👎🏿
Faudrai espacer les PEBKAC avec du code source, la page d'accueil fait peur là.
Commentaire #75707 écrit par Mme.Michu le 25/01/2013 à 19h56 | 👍🏿 👎🏿
C'est une optimisation. En supposant que le compilo est loin d'être idiot, il teste une seule fois la valeur de flag parce qu'il voit que la valeur de flag ne sera jamais modifiée, alors pourquoi tester à chaque fois si on connait déjà le résultat ?
Commentaire #75737 écrit par Noname le 25/01/2013 à 23h25 | 👍🏿 👎🏿
Sondage : Suis-je le seul a ne pas aimer les indentations a coup d'espaces (que ce soit 2, 3 ou 4) ?
C'est tellement plus pratique un seul caractere (tab) par niveau d'indentation...
Commentaire #75795 écrit par TuXiC69 le 26/01/2013 à 12h01 | 👍🏿 👎🏿
Oui
Commentaire #75798 écrit par Hum. le 26/01/2013 à 12h24 | 👍🏿 👎🏿
Le problème de TAB est qu'il n'a pas une taille constante suivant les IDE, et donc suivant les programmeurs. Les espaces ont l'avantages de ne jamais corrompre l'indentation.

Le mieux reste donc une indentation par espaces, et un IDE qui sait gérer les mouvements du curseur intelligemment.
Commentaire #75828 écrit par OzoneGrif le 26/01/2013 à 14h17 | 👍🏿 👎🏿
Tu pourrais détailler s'il te plait ? Je ne crois pas avoir déjà eu de problèmes avec les TAB.
"Pas une taille constante" ? Un caractère TAB sera toujours 1 caractère TAB non ?
Bref je ne comprends pas, mais je serais ravi si tu pouvais m'expliquer :)
Commentaire #75864 écrit par TuXiC69 le 26/01/2013 à 17h55 | 👍🏿 👎🏿
A l'origine, un caractère tabulation était égal à huit espaces. Mais les développeurs trouvaient ça beaucoup trop grand, surtout lorsque les écrans sous DOS n'acceptaient que 80 colonnes de caractères. On a donc vu apparaitre des IDEs autorisant le changement de la taille d'une tabulation... souvent 2 ou 4 espaces.

Très vite, cette fonctionnalité a posée problème lorsque le code source passait d'un développeur à l'autre. Quand on a une indentation mixte tabulation/espace, et que la valeur d'une tabulation change d'un développeur à l'autre, ça casse toute la mise en page...

Les IDEs ont donc trouvé une autre solution : convertir les tabulations en espaces, et traiter les séries d'espaces comme des tabulations pour le curseur. Au final, on utilise plus vraiment le caractère tabulation (sauf sous Python); c'est trop problématique.
Commentaire #75903 écrit par OzoneGrif le 26/01/2013 à 21h41 | 👍🏿 👎🏿
on l'a pas tous fait le " printf("On ne devrait jamais arriver ici !");" ? :D
Commentaire #75988 écrit par baka le 27/01/2013 à 16h15 | 👍🏿 👎🏿
J'ai déjà fais des commentaires "// si vous arrivez ici, il y a un bug" et tu t'aperçois avec le temps que tu finis toujours par tomber dans ces zones théoriquement impossibles.

Autant gérer ça avec un code erreur propre. :)
Commentaire #76014 écrit par OzoneGrif le 27/01/2013 à 19h59 | 👍🏿 👎🏿
Il programmait debout, c'est peut-être un détail pour vous, mais pour moi ça veut dire beaucoup

ça veut dire qu'il était libre, heureux d'être là malgré tout...
Commentaire #76082 écrit par Garf365 le 28/01/2013 à 10h21 | 👍🏿 👎🏿
3 états seulement ? Pfff petit joueur
http://vhdl.renerta.com/mobile/source/vhd00067.htm
Commentaire #76245 écrit par hardeux le 28/01/2013 à 20h31 | 👍🏿 👎🏿
Même sous Python, on utilise très souvent des espaces.

En tout cas mixer les espaces et les tabulations, c'est le mal !
Commentaire #76487 écrit par contrebasse le 30/01/2013 à 09h06 | 👍🏿 👎🏿
Un de mes condisciples avait la particularité de tout faire planter de la façon la plus improbable. Donc à chaque fois qu'on faisait un switch couvrant tous les cas logiquement possibles, on faisait un default: avec un printf("Hubert, comment t'as fait pour arriver là ?");

Et de fait, Hubert arrivait à tomber dans ces cas impossibles.
Commentaire #76832 écrit par Eric D le 31/01/2013 à 17h54 | 👍🏿 👎🏿
Une des applications dont je suis responsable contient un grand nombre de cas improbables avec un log:
log.error("THIS IS A BUG !! We should never reach this code");

Je vous dis pas comment ça fait sérieux quand un client tombe sur un log pareil. Je les reformule au fur et à mesure que je les trouve avec des trucs genres "Unexpected option combination foo+bar, please report this error to the application support. Continuing without any of those options." Ca fait quand même nettement plus pro.
Commentaire #76833 écrit par Eric D le 31/01/2013 à 17h59 | 👍🏿 👎🏿