Recoder ce qui existe déjà

La première marque du mauvais développeur, c'est de vouloir absolument recoder ce qui existe déjà. Pourquoi vouloir utiliser les fonctions de tri des bibliothèques standards, alors qu'il est toujours plus amusant de (mal) recoder un tri à bulles ?

Après tout, coder est une activité hautement amusante. Ce serait dommage de se priver de longues heures de plaisir en réutilisant des fonctions qui ont déjà été testées, optimisées par des milliers de personnes.

En plus, recoder l'existant augmente considérablement les chances de voir apparaitre des bugs. C'est bien, ça permet de vendre des extensions de garantie.

Écrire un code illisible

Le pire, avec les mauvais développeurs, c'est qu'ils sont en général convaincus d'être bons. Et pour bien montrer leur grosse intelligence, ils n'hésitent pas à produire le code le plus compact et le plus illisible possible. Un peu comme ces philosophes qui emploient des phrases de 10 lignes et sont fiers de n'être compris que d'une élite.

On a dit au mauvais développeur qu'un bon code était un code OP-TI-MI-SÉ. Alors, il optimise, persuadé que l'espace disque qu'occupe son code est un critère à prendre en compte.

Et vas-y que je te rajoute des affectations dans les conditions. Et vas-y que je t'imbrique les opérateurs ternaires (?:). Et allez, une belle expression booleenne à trois niveaux sur une seule ligne.

Le résultat, bien entendu, c'est un code illisible, incompréhensible, et immaintenable.

Puisqu'il en est aux optimisations, le mauvais développeur va également tenter de concevoir le code le plus complexe possible, parce qu'un code complexe est forcément meilleur qu'un code simple. Les codes simples, c'est pour les neuneus qui ne savent pas coder.

// Parce qu'il serai trop simple d'écrire ceci :
if(adresseValide( $adresse ) && adresseDispo( $adresse )) {
    // traitement
} else {
    // Autre traitement
}

// Le mauvais développeur préférera ajouter quelques tests et conditions, pour être bien certain de gérer toutes les erreurs possibles :
if(($eAdrel = CompteUtil::VerifierDispoAdrel($d[champAdrel])) != COMPTESADREL_DISPO || ($eAdrel = VerifFormUtil::checkExistingEmailAddress($d[champAdrel]) ? COMPTESADREL_PRESENTE : COMPTESADREL_DISPO) != COMPTESADREL_DISPO) {
...

Bien entendu, si ligne par ligne, le mauvais développeur compacte au maximum, il n'hésite pas en revanche à écrire des fonctions qui dépassent allégrement les 350 lignes. Parce que, c'est bien connu, plus une fonction est complexe, plus elle est puissante.

Écrire beaucoup de commentaires

Le mauvais développeur, persuadé d'être bon, a entendu dire que les bons développeurs inséraient des commentaires dans leur code. Alors il en rajoute. Mais il en rajoute tellement, que ses commentaires deviennent des romans que ne renieraient pas Proust.

/* À FAIRE: éclater cette requête.
 * Le problème est que le traitement fait par nous n'est pas monstrueux,
 * et se fait facilement dans la transaction qu'on lui donne. Cependant
 * derrière, on a des manips eZ publish, inclues dans notre transaction,
 * susceptibles de gros brassages.
 * À l'origine, on travaillait compte par compte. Le problème est que
 * désormais, il peut y avoir des sauts façon attaque de convoi: un
 * compte secondaire peut vouloir profiter de la transition pour se
 * détacher de son principal. L'atome n'est donc plus le couple
 * [compte principal;abonnement]. La solution d'origine ne marche
 * plus.
 * À l'heure actuelle, il reste encore possible de découper par
 * abonnement de départ (une transaction par abo, plus une par
 * nouvel abo): en effet, on a du:
 * a1 <-1-n-> c <-1-0,1-> a2
 * donc pas de recoupement du moment que ce n'est pas du:
 * … 1-n-> a2
 * (qui permettrait de passer d'un a1, via un c et un a2, à un autre c
 * lié à un a1 différent du premier, autrement dit impossibilité de
 * trancher. Certes, c'est improbable qu'on permette un jour à deux
 * gusses de décider de se lier dans un même abonnement)
 * Autre piste: faire une transaction par compte, et à la fin une
 * grosse transaction sur les abonnements. Comme ça, au pire, s'il y a
 * une erreur à un moment, un certain nombre de comptes auront été
 * placés, et les abonnements seront restés dans leur état d'origine. Ce
 * qu'il faut vérifier alors est qu'on peut effectuer plusieurs fois la
 * passe de multipositionnement sans artefact (ex.: il ne faudrait pas
 * que ça incrémente un compteur, sinon, si on met trois échecs avant de
 * passer, le compteur aura été incrémenté trois fois pour une seule
 * transition d'abonnement.
 */
/* À FAIRE: permettre, par un biais que je n'imagine pas encore, à un
 * compte secondaire qui a demandé son détachement, de quitter
 * prématurément son abo d'origine pour fonder le sien propre. Sinon
 * il est obligé d'attendre pour profiter de son abonnement en nom
 * propre, que le principal veuille bien expirer. */
/* À FAIRE: repérer aussi les abonnements qui ont récupéré de nouvelles
 * options, trouver leurs comptes (comptes principaux mais aussi
 * secondaires) et rappeler leurs ActualiserGroupesComptesEz . */

C'est clair ? (Pour info, ce machin est vraiment tiré d'un vrai projet). Quand on doit se taper du code qui contient 20 lignes de commentaires toutes les 3 lignes de code, c'est... Comment dire ? Lourd ?

En plus, étant donné que son code est bardé de commentaires, le mauvais développeur se considère relevé de l'obligation d'écrire un code significatif. Le code auto documenté, c'est pour les débutants. On se retrouve vite avec des variables et fonctions qui ne signifient plus rien.

$paye = CompteUtil::ModifierEntree(PT.'produit', $restes[0]) ? 1 : COMPTES_EINTERNE;

C'est limpide, non ?

Optimiser à mort

Le mauvais développeur, on l'a dit, adore montrer sa grosse intelligence. Et pour bien montrer qu'il est un pur, un dur, un bon, il optimise son code. Sans doute parce qu'à l'école, il a reçu l'enseignement de vieux de la vieille, des gens qui ont commencé leur boulot quand la mémoire coutait cher, et que les processeurs n'exécutaient que quelques centaines d'instructions par seconde.

Forcément, à cette époque, quand on gagnait quelques octets, quand on économisait quelques instructions, on était content. Mais aujourd'hui ?! Aujourd'hui, ça rime à quoi d'écrire un code tordu pour économiser trois octets de mémoire ? Quel est l'intérêt de déployer des astuces de programmeurs pour gagner 1.10^-1000000000 secondes en temps d'exécution ?

Le mauvais développeur est également un gros fainéant. Pas dans le (bon) sens où il préfère réfléchir 5 minutes pour écrire le moins possible, mais dans celui où il compacte à mort ses instructions pour gagner trois caractères.

for($i = 0; ++$i <= 2;)
...
return array_key_exists(ABO_ACTIF, $etats) ? COMPTESADREL_PRESENTE : (array_key_exists(ABO_LATENT, $etats) ? ($aboFuturAvecCompte ? COMPTESADREL_FUTURE : COMPTESADREL_DEMANDEE) : (array_key_exists(ABO_FINI, $etats) ? COMPTESADREL_DISPO : COMPTESADREL_DISPO)); // Finalement, c'est une mauvaise idée de renvoyer COMPTESADREL_PASSEE: ça bloquerait un internaute ayant oublié de renouveler son abonnement et voulant se réabonner dès le lendemain. On renvoie donc COMPTESADREL_DISPO dans ce cas aussi.

Merci pour celui qui passe après.

Bref ! Il est beaucoup plus facile d'être un développeur moyen qu'un excellent développeur. En revanche, j'en connais qui ont élevé la médiocrité au rang d'art, s'assurant pour jamais un sentiment de haine de la part des autres développeurs qui assurent la maintenance de leurs [STRIKEOUT:erreurs] horreurs.