PEBKAC #7979

Quand je débutais en programmation, je nommais mes variables a1, a2, a3, etc. Très soucieux de l'esthétique du code, je trouvais important qu'elles « entrent en lice » dans l'ordre numérique. Aussi, si j'ajoutais une condition ou une boucle au début du code, je m'arrangeais pour tout renuméroter à la main : la nouvelle variable créée devient a1, a1 devient a2, a2 devient a3, etc.

À ce petit jeu-là, une distraction arrive très vite. Bilan : un peu de programmation, beaucoup de manipulations, et énormément de temps pour chercher à comprendre pourquoi du code qui fonctionnait très bien, ne fonctionnait subitement plus. PEBKAC.

PEBKAC #7979 proposé par /etc/passwd le 15/06/2013 | 16 commentaires | 👍🏽 👎🏽 +528

Petit hors-sujet : ce n'est que mon avis personnel, mais quelque soit ce qu'on code, il vaut mieux des noms de variables très explicites, de toutes les manières.

Commentaire #96822 écrit par Samael le 15/06/2013 à 17h32 | 👍🏽 👎🏽

du genre str, tab ou compteur ?

Commentaire #96825 écrit par Link le 15/06/2013 à 17h37 | 👍🏽 👎🏽

Je ne développe pas personnellement (à part lors des cours obligatoires en licence pro), donc, je ne me penche pas vraiment sur le nommage de manière concrète. Cela étant dit, grâce aux quelques cours que j'ai dû suivre, j'ai tout de suite compris qu'un nommage de variable qui n'est pas explicite handicape pour soi-même quand on doit coder, et, aussi, ceux qui sont susceptibles de passer derrière nous.

Commentaire #96826 écrit par Samael le 15/06/2013 à 17h40 | 👍🏽 👎🏽

Complètement d'accord avec toi, si on a un bug, c'est plus facile à retrouver ainsi. Après, si on veut obfusquer son code, c'est une fois qu'il a été fiabilisé.

Commentaire #96833 écrit par Aaargh!!! le 15/06/2013 à 17h57 | 👍🏽 👎🏽

Jamais de fonctions de plus de 100 lignes : la base.

Tu devais être le seul à bosser sur ton code car sinon ça pouvait chauffer.
Si je vois ça c'est apéro tant que c'est pas changé.

Et si tu veux obfusquer ton code, tu le fais après avec des applis faites pour.

Commentaire #96845 écrit par RGB le 15/06/2013 à 18h41 | 👍🏽 👎🏽

Je pense, mon cher /etc/passwd, que tu as une compétence innée pour les langages a pile !

Si tu ne sais pas par quoi commencer, essaie Forth !

Commentaire #96848 écrit par b0fh le 15/06/2013 à 18h58 | 👍🏽 👎🏽

Je ne dirais rien, puisque quand je dois ajouter une variable imprévue dans mon code, ça se finit souvent en truc, machin ou bidule.
@RGB : 100 lignes, avec ou sans indentation ? Et l'accolade, sur une ligne à part ? :-P

Commentaire #96852 écrit par Till Gray le 15/06/2013 à 19h19 | 👍🏽 👎🏽

Avec indentation et tout, sans les gros commentaires sur plusieurs lignes peut être.
il peut y avoir des exceptions.
Je ne suis pas si rigide

Commentaire #96856 écrit par RGB le 15/06/2013 à 19h31 | 👍🏽 👎🏽

Les noms de mes variables sont généralement très clairs, en lower camelCase... ;-)
Genre (variable du jour) allowInputEvent ou serverSocket, j'utilise des noms plus courts mais il faut se méfier des abréviations genre conf pour configuration, qui vaut aussi pour confirm, après y'a les variables locales (v pour value, k pour key etc...), elles sont claires car dans contexte.

Commentaire #96870 écrit par Cartman34 le 15/06/2013 à 21h14 | 👍🏽 👎🏽

Je me doute, je voulais juste faire de l'humour :-)

Commentaire #96871 écrit par Till Gray le 15/06/2013 à 21h20 | 👍🏽 👎🏽

Ce qui est drôle, c'est qu'on peut valider le pebkac dès la première phrase. Le reste, c'est du bonus.

Commentaire #96873 écrit par Hart le 15/06/2013 à 21h53 | 👍🏽 👎🏽

Quand j'étais à Epitech, on n'avait pas le droit à des fonctions de plus de 25 lignes, sachant que les accolades comptaient chacune pour une ligne. Parfois le découpage était un vrai calvaire... (mais sur des trucs simples créer une nouvelle fonction dès qu'on pouvait devenait très vite un réflexe)

De toute façon la norme Epitech c'était bien pour certains trucs mais dans l'ensemble c'était quand même très chiant pour pas grand chose (et une espace oubliée ou rajoutée avant une parenthèse pouvait vite faire perdre des points).

Commentaire #96886 écrit par Limeila le 15/06/2013 à 23h36 | 👍🏽 👎🏽

Hormis les noms de variables (qui font un PEBKAC à eux seuls) c'est dans ces cas-là qu'on est content d'avoir un IDE avec de vraies fonctionnalités de refactoring.

Commentaire #96899 écrit par Acorah le 16/06/2013 à 00h58 | 👍🏽 👎🏽

merci d'expliquer les votes négatifs!

Commentaire #96902 écrit par RGB le 16/06/2013 à 01h30 | 👍🏽 👎🏽

Moi j'upvote*. Vu le nombre de fonctions à rallonge, non-commentées et comprenant des variables aux noms absolument pas explicites que je me tape d'aller améliorer ou débugguer, je ne peux qu'aller dans ton sens.
Quand on programme, il faut toujours se mettre à la place du gars ou de la nana qui va passer derrière un jour où l'autre et qui devra comprendre comment ton code fonctionne.

* en gardant en tête que dans les 100 lignes, on compte pas les commentaires et les lignes laissées vides pour aérer le code

Commentaire #97027 écrit par Youplà le 17/06/2013 à 10h55 | 👍🏽 👎🏽

@Youplà merci

J'ai déjà eu à débugger des fonctions de plus de 10000 lignes: n'importe quoi, j'ai tout réécris.

Je pense que c'est à cause de l'apéro les votes négatifs, on peut faire la variante un peu plus cul-cul avec les croissants ;)

Commentaire #97061 écrit par RGB le 17/06/2013 à 12h22 | 👍🏽 👎🏽