Le tout sans indentation ? Les sauvages !

Ça dépend...

Moi ça m'arrive d'imbriquer pas mal de if {...} ElseIf {...} ElseIf {...} etc si je peux avoir une multiple sortie de fonction, donc à moins que je n'ai rien compris au PEBKAC (ce qui est possible vu que je n'entrave que dalle au PHP ^^) je ne vois pas où il est le PEBKAC justement...

Si les fonctions sont optionnelles, je suppose que l'indentation, les constantes et les objets ne sont que confort aux yeux du précédent développeur. Mais il aime bien les commentaires inutiles.

13 niveaux d'imbrication ! Il faut être complètement malade pour pondre un truc pareil... Il faut un minimum modulariser le truc. Par exemple, sur le projet où je suis en ce moment, on essaye dans la mesure du possible d'avoir moins de 30 ";" par méthode (technique simple pour déterminer la complexité d'une méthode).

@Heidi : Le code était vaguement indenté mais selon les pages la norme changeait (des fois je revient à la ligne, des fois pas) sans parler des normes de nommage des variables et fonctions aléatoires.

@flak : Le code a été créé sous PHP 4 (voire 3) si mes souvenirs sont exacts le PHPOO n'est possible que depuis la 5. Côté commentaires il y en a très peu et ils sont presque tous de cet acabit.

@Shadam : code en objet, j'ai pas eu à imbriquer plus de 2 if et je fais pas (que) des petits scripts du dimanche :)

J'allais dire que pour une fois le PEBKAC était assez vague, mais finalement non.

PEBKAC validé.

dans ce cas, il nous faut une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe imbriquée dans une baffe.

Le problème c'est que je ne sais pas quelle onomatopée associer à ça.

Tu vois la scène dans Astérix et Obélix mission cléopâtre quand ils "interrogent" le marchand à grand coup de claques ? Ben pareil :)

Malheureusement, je n'ai pas vu le film.

*fuis pour éviter les baffes*

Et sinon, le switch, ça lui dit quelque chose ?

Par contre, éclairez-moi : en PHP, on peut switch sur n'importe quoi ? vu que typage et PHP, bon... Je sais qu'en Java, à part les char et les int...

Le pire dans l'histoire c'était que ces 13 if (et encore ça c'est juste la dernière ligne il y avait encore d'autre conditions refermées plus haut) c'était simplement pour vérifier le contenu d'un formulaire.
Donc pas besoin d'imbrication, et pour répondre à ta question oui on peut switch sur n'importe quoi en PHP :)

Tu peux aussi switch des enum et des String en Java.

Pas con, le coup des 30 ";", je garde l'idée. :)

Je me souvient de mes premiers codse en sequentiel tous pourrave.
On m 'a vite calmer avec un peut d'injection sql.

On a tous été un jeune developpeur à un moment donné.
Maintenant je sais que certaine personne prefere reprendre mon code plutot que d'autre , on passe tous par la case "jeune developpeur".
Soyez indulgent, c est pas un pebkac, juste un jeune developpeur.

Si tu es Apprenti développeur , il y a de fortes chances pour que la personne avant toi le soit aussi.

Le gars en question n'était pas un jeune développeur mais un programmeur d'une 30aine d'années. Ceci étant le soft en question a bien 10-15 ans et entre temps on a changé la façon de programmer.

Et pour ce qui est des jeunes développeurs qui sont passés avant moi j'ai posté quelques PEBKAC à ce sujet il y a quelques jours :)

Baffeception ! Je ne suis plus là

même jeune dev, fermer ses accolades en respectant l'indentation, ça aide bien pour suivre après, et donc surtout pour ceux qui suivent (et je dis ça après expérience de débugage de mes bouts de code à moi à la fac ... ça commence à dater, enfin jamais j'aurai fait ça sur un truc pro). Même si le genre d'erreur de compil' qu'on peut trouver dans ces cas est plus ou moins facilement trouvable sans indentation (mais j'ai abandonné l'idée de débuger les trucs sur une ligne quand l'indentation est mal faite sans refaire l'indentation -mici indent quand c'est pas mon code-).

C'est des dev qui ferait mieux de bosser en Common Lisp...

Ça me rappel un de mes stages datant de quelques années: Modifier une application access déjà existante. Ma solution ? Tout refaire à partir de rien.
Au moins ça évite de tomber sur des pebkac et d'essayer de comprendre la façon de coder d'un mauvais dev ;)

J'aime pas trop ces normes de limitation de taille des méthodes... Je sais que, souvent, ça évite les codeurs qui écrivent 10 lignes où la moitié n'est pas utile, mais en même temps, quand on fait des choses un peu plus complexes, on se mange des warnings qui n'ont pas lieu... Vivement que ces algos deviennent intelligents !

Une onomatopée genre mitraillette à baffe, ça marcherait pas ? Genre SPSPSPSPSPSPSPSPSPSPSPSPSPAAAAAAAAAAAAAFFFFFFFFFFFFF

Je faisais pareil jusqu'à ce qu'on me dise que je perdais du temps et que c'était pas ce que l'on me demandait... Depuis, quand je vois un code dégueulasse, je râle plus ou moins discrètement et je débranche mon cerveau... Heureusement qu'il me reste les projets persos pour voir un code un peu plus clean...

C'est aussi ce que j'ai fini par faire, tout recommencer. J'en ai profité pour ajouter de l'AJAX et du JS, qui étaient totalement absents du projet original :)

@Mat+1 c'est pas toujours justifié de tout recommencer mais avec les bons arguments ça passe tout seul, notamment quand tu commences à parler de compatibilité, de facilité d'utilisation, de problèmes fonctionnels.

@Mat+1 : la plupart des outils que je connaisse qui vérifie l'esthétique du code automatiquement possède des mots-clef qui permettent de désactiver localement un test pour éviter ce genre d'avertissement. Bien sûr, je vérifie que l'utilisation de ces mots-clef est justifiée, sinon ça ne sert à rien de faire les tests...
Ensuite, il est également possible de désactiver totalement la vérification du code quand on est en phase de développement, pour la réactiver juste avant la publication sur le gestionnaire de configuration.

@Sihn : pour le Java, tu peux utiliser ça : http://checkstyle.sourceforge.net/config_metrics.html#JavaNCSS

Pas toujours, tu peux te retrouver à la maintenance applicative et là, tu peux expliquer ce que tu veux, personne ne t'écoute...

If maVariable1 = x
message d'erreur
else
If maVariable2 = y
message d'erreur
else
If maVariable3 = z
message d'erreur
else
etc....

@shadam : Dans le PEBKAC ça serait plutôt

IF maVariable1 = x {
IF maVariable2 = x {
IF maVariable3 = x {
IF maVariable4 = x {
IF maVariable5 = x {
[...]
}
}
}
}
}

Le tout (à priori) sans indentation évidement. Donc rien avoir avec des IF-ELSEIF : dans le PEBKAC tous les tests de chacun des IF seront obligatoirement fait (et ce que les tests soit OK ou KO) alors que dans ton exemple, plus aucun test ne sera fait dès qu'il y en aura un OK.

En attendant, 13 niveaux d'imbrications ça va pas être évident à justifier. S'il fait pareil pour les boucles, je m'imagine les perfs de ses applis => Que du bonheur :D

Ça, ça ressemble au son du GAU-8 monté dans les A-10 ;-)

C'est cool, mais ça reste quand même un poil overkill.

Malheureusement je ne suis pas responsable du paramétrage de l'outil d'audit de code installé sur mon projet et qui bien souvent nous pousse à coder improprement.

Il m'est déjà arrivé de devoir clore des blocs ifs par des }}} pour un gain de 2 lignes et un substantiel gain dans ce même outil de code.

Croyez moi je le fais pas par plaisir.

Oui c'est bien pour ça que j'ai précisé, parce que quand j'ai vu le -6 de mon commentaire, je me suis dit que j'avais été mal compris...

De toute façon je suis un grand incompris :'(

@Geist : Il me semble qu'il manque un "a", c'est "GAU-A8" si je ne m'abuse. Un joli jouet soit dit en passant, tu es la première personne que je croise qui le connaisse :)

J'ai déjà eu un projet où on n'avait pas le droit de dépasser 80 caractères par ligne. Déclaration du namespace, classe, méthode, avec l'indentation déjà 12 caractères bouffés. En rajoutant les tests et boucles (éventuellement imbriqués pour certains) on était obligés de mettre des retours à la ligne bien dégueulasses pour rester dans ces 80 caractères, alors qu'on n'était même pas au bout de l'écran... Et obligé de scroller verticalement du coup vu que des instructions même pas trop compliquées prenaient plusieurs lignes. Bonjour la lisibilité du code :/
Et tout ça pour quoi ? Pour que ça rentre sur une page A4 quand la personne en charge de la validation du code allait l'imprimer...

C'est plus courant qu'on ne pourrait l'imaginer, mais faut pas que ça soit quand même trop contraignant.

Si on suit les recommandations de codage Zend pour le Zend Framework, c'est même ce qu'ils disent :
http://framework.zend.com/manual/1.12/en/coding-standard.php-file-form[...]
Même s'ils concluent par dire que le maxi absolu d'une ligne doit être de 120 chars.

La plupart du temps, on passe à 120 car sur les écrans actuels, c'est la limite acceptable pour que tout apparaisse. Au-delà, le résultat n'est pas toujours garanti

Ça me fait penser à SAP dans des versions pas si vieilles que ça (la 4.6C par exemple) : la limite de caractères par ligne était de 72 quoi qu'il arrive ! Cette limite additionnée au langage particulier qu'est l'ABAP rend les conditions de travail particulières ^^

Mon principal argument c'était un schéma relationnel complètement pourri ;)

Apprendre à coder
À coder pour deux,
Rien qu'en ouvrant les yeux,
Et savoir penser
penser sans rature
Ni demi-mesure
Apprendre à programmer.
Vouloir jusqu'au bout
Programmer malgré tout,
Apprendre à coder,
Ou s'en aller,
Ou s'en aller...

Ma limite est fonction de celle de mon écran/éditeur (100-120), si ça dépasse, retour à la ligne, c'est TOUJOURS possible de mettre un beau retour à la ligne qui délimiter bien ce qu'on fait, avec une belle indentation comme il faut, surtout dans un if, ça devient vraiment chiant quand c'est un tableau multidimensionnel avec des noms/clés à rallonge.

Je me confesse, mon record c'est 21 if{} imbriqué.
Vous pouvez me lyncher

80 caractères je trouve que c'est peu. C'était à l'époque où on avait des résolutions avec 800px de large. Remarque, si t'es payé à la ligne c'est good :D

Maintenant, avec 1280px de large pour la résolution d'écran, je fais tenir 180 caractères max avec l'éditeur en fullscreen. C'est quand même beaucoup, mais ça ne sert à rien d'aller jusque là.

Pourquoi faire ?

Rien à voir avec la résolution de 800x600, c'était lié au nombre de caractères dans un terminal (ceux sans l'interface graphique fenêtrée).

Si il y a trop de if, pourquoi de pas faire un switch avec des case ?

switch ($i) {
case x":
break;
case "y":
break;
}

Imbriquer des if ne signifie pas qu'on teste toujours la même variable, le switch c'est pour les else if à la suite, donc non-imbriqués.