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.
J'ai dû faire un projet en langage C en groupe de quatre, mélangeant deux débutants et deux plus expérimentés. Étant l'un des "expérimentés", je ne m'attendais pas à en apprendre autant de mon collègue :
– Une fonction qui en appelle une autre, ça fait planter la stack ;
– C'est la raison pour laquelle il faut tout mettre dans le main ;
– Visiblement, un code "optimisé", c'est un code rempli de #include jamais utilisés (il doit penser que c'est un genre de talisman) ;
– Et enfin, pour tester un programme, il faut faire gcc -o machin.c… Et si ça plante, c'est que le programme est mauvais.
Respect pour les longuement ressassées six années d’expérience. PEBKAC.
PEBKAC #8674 proposé par dave null le 30/09/2013 | 14 commentaires | 👍🏽 👎🏽 +187
– Et enfin, pour tester un programme, il faut faire gcc -o machin.c

C'est quoi le pebkac ici ? La syntaxe est incorrecte (fichier de sortie non spécifié), ou tu juge indispensable de faire un beau makefile ?
Commentaire #113024 écrit par Link le 30/09/2013 à 09h01 | 👍🏽 👎🏽
Je crois que pour l'auteur, tester un programme c'est le compiler puis surtout l'exécuter. Ici on dirait qu'ils se limitent à la compilation :)
Commentaire #113029 écrit par Plop le 30/09/2013 à 09h25 | 👍🏽 👎🏽
Peut-être qu'il veut parler d'une confusion entre le test et la compilation. Le test d'un programme se situe plutôt du côté de l'exécution, même s'il est vrai que si un programme ne compile pas, c'est bien qu'il a mal été codé.
Commentaire #113030 écrit par Gné? le 30/09/2013 à 09h25 | 👍🏽 👎🏽
ben déjà, -o c'est pour spécifier le fichier de sortie. S'il veut compiler le .c, il faudrait utiliser par exemple : gcc -o machin machin.c ou gcc -c machin.c (dans le 1er exemple il y a édition de liens en plus de compilation). Mais oui, la syntaxe est incorrecte…
Commentaire #113034 écrit par pbx le 30/09/2013 à 09h43 | 👍🏽 👎🏽
Ton avis rejoint celui de Gné?, je n'avais pas vu la phrase dans ce sens là. Il est écrit il faut faire et pas il suffit de faire. La compilation est indispensable avant de tester, mais il ne dit pas que c'est la seule chose à faire.
Commentaire #113035 écrit par Link le 30/09/2013 à 09h49 | 👍🏽 👎🏽
Pour moi, la façon dont c'est vu, le collègue expérimenté explique ce qu'il faut faire. S'il ne précise pas autre chose, c'est qu'il suffit de faire ce qu'il dit (implicitement dans le texte).
Commentaire #113036 écrit par Raizarachi le 30/09/2013 à 09h52 | 👍🏽 👎🏽
Ouiii, mettons tout, TOUT dans le main /o/
Commentaire #113046 écrit par mini le 30/09/2013 à 10h55 | 👍🏽 👎🏽
Ben oui on peut tout mettre dans le main. Exemple.

Fichier principal :

#include "header.h"
main () {
(...)
toto
(...)
}

Ficher header:

#define toto } void ma_fonction() {
void ma_fonction();
Commentaire #113051 écrit par ptolemee le 30/09/2013 à 11h38 | 👍🏽 👎🏽
Ben, il n'a pas tout à fait tord.
– Une fonction qui en appelle une autre, ça fait planter la stack ;
Si on fait beaucoup beaucoup beaucoup beaucoup d'appels de fonctions imbriqués, on vas finir par faire saturer la pile (ou la RAM).

– C'est la raison pour laquelle il faut tout mettre dans le main ;
Le compilateur n'apprécie pas beaucoup le code en dehors du main, du genre:
main()
 {
 }
 printf("toto");


– Visiblement, un code "optimisé", c'est un code rempli de #include jamais utilisés (il doit penser que c'est un genre de talisman) ;
Si on ne les utilise pas, on ne pert pas de temps à les exécuter. CQFD.

– Et enfin, pour tester un programme, il faut faire gcc -o machin.c… Et si ça plante, c'est que le programme est mauvais.
Mis à part la syntaxe, si la compilation plante c'est effectivement que le programme est mauvais.



Si vous me cherchez, je suis dehors.
Commentaire #113068 écrit par Shirluban le 30/09/2013 à 14h29 | 👍🏽 👎🏽
Pour un coup de pelle mérité, j'irais même dehors te rejoindre !
Commentaire #113075 écrit par mini le 30/09/2013 à 14h47 | 👍🏽 👎🏽
Reviens à l'intérieur, couard ! Tu dois payer pour tous ceux qui emploient « tord » au lieu de « tort » sur ce site depuis un certain temps. Et pour l'occasion, tu mérites que je te torde la colonne vertébrale, que cela vous serve d'exemple à tous.
Commentaire #113084 écrit par Grammar Nazi le 30/09/2013 à 15h26 | 👍🏽 👎🏽
Quand j'ai commencé le C, je recopiais les #include sans bien savoir à quoi ils servaient...
En revanche, j'écrivais sans problème des fonctions qui en appelaient d'autres. Et je n'avais aucune idée de ce que pouvait être la stack...
Commentaire #113093 écrit par Tharkun le 30/09/2013 à 16h46 | 👍🏽 👎🏽
Si on veut pousser le vice un peu plus loin, le test d'un programme ce sont :
- Les tests unitaires
- Les tests fonctionnels
- Les tests de montée en charge
- Les tests qualité/utilisateurs (aussi appelés "Rent an idiot" http://rentanidiot.com/ )

Souvent un logiciel passera par des phases de tests Alpha, Beta puis Omega (Release Candidate).
Et pour certaines types de programmes, il faut passer par la phase de certification, qui est aussi un test.

La compilation n'est pas dans la liste...
Commentaire #113108 écrit par OzoneGrif le 30/09/2013 à 18h36 | 👍🏽 👎🏽
ne connaissant pas le C, je ne panne rien à la dernière ligne(même si vos commentaires m'orientent vers une commande de compilation).

Par contre, les 3 premières..... Les deux premières, c'est l'interdiction de la programmation structurée, la troisème du cargo cult programming. Belle performance. Je valide, c'est un PEBKAC.
Commentaire #113264 écrit par El_Slapper le 01/10/2013 à 16h43 | 👍🏽 👎🏽