1 - Ne pas commenter son code proprement suivant un standard comme phpDoc
C'est le service minimum en matière de commentaires. Il est vital de savoir ce qu'une fonction attend en parametre et ce qu'elle retourne. De plus, cela permet la génération d'une documentation; et certains éditeurs tels que Komodo edit s'en servent pour afficher une aide en ligne lorsque vous y faites appel .
2 - Ne pas voir le bénéfice d'un bon outil de développement intégré tel que Zend Studio ou Eclipse.
Ces usines à gaz ? Non, désolé.
3 - N'avoir jamais utilisé d'outil de contrôle de versions tel que Subversion
Plus que la qualité du programmeur, je crois que c'est surtout une question de projet. Pour une appli professionnelle ou un projet open source, c'est vital, mais on n'a pas toujours un serveur subversion sous la main pour un site perso....
4 - Ne pas adopter de convention de codage et de nommage et s'y tenir, au moins à l'échelle d'un projet.
Qui ne s'est pas déjà arraché les cheveux avec le nom des fonctions natives php (avec ou sans underscore), et pire l'ordre des arguments qui varie d'une fonction à l'autre ?
5 - Ne pas adopter une méthodologie constante
Faudrait déjà en avoir une. Personnellement, je suis plutôt habitué à La Rache.
6 - Ne pas échapper ou valider les variables pour les requêtes SQL
Là c'est plus de la mauvaise programmation, c'est l'amour du risque.
7 - Ne pas planifier l'application avant de commencer à coder.
Dans un monde idéal, les utilisateurs sauraient ce qu'ils veulent les spécifications ne changeraient pas tous les trois mois. Dans un monde idéal.
8 - Ne pas pratiquer le développement dirigé par les tests.
Les test unitaires, c'est bon. Mangez-en.
9 - Désactiver l'affichage des erreurs
La première fois qu'on l'active, ça fait mal. Mais après, c'est tellement bon. Et surtout, cela permet généralement de préparer en douceur la prochaine mise à jour de PHP.
10 - Ne pas voir les bénéfices d'un débogueur
Il n'y a qu'un débogueur ici, c'est moi. Sans rire, pour un langage web interprété, le débogueur, c'est un petit coup de rafraichissement de la page. Non ?
11 - Ne pas refactoriser son code
On peut faire autrement ? Mon nom est Refactoring. Constant Refactoring.
12 - Ne pas séparer les couches de traitement en utilisant un motif tel que MVC.
Ou MVT. Elementaire, mon cher Django.
13 - Ne pas connaitre les acronymes KISS, DRY, MVC, OOP, REST
Mouais, pas besoin de connaitre les acronymes pour pratiquer.
14 - Ne pas retourner de contenu mais faire des print() depuis les fonctions et classes
Autrement dit, éviter les effets de bord. Et appliquer le principe de la séparation des couches de traitement.
15 - Ne pas connaitre les avantages des tests unitaires et des tests en général
On avait pas dit DRY ? cf #8
16 - Retourner du html au lieu de données / objets
Pareil, voir #14
17 - Coder en dur les messages et les parametres de configuration
Coder en dur, c'est mal
18 - Ne pas optimiser ses requetes SQL
Je veux bien, mais qui le fait vraiment au lieu de juste le prétendre ?
19 - Ne pas utiliser __autoload()
J'ai la malchance de maintenir des applications PHP4. Mais j'ai mieux qu'autoload : Webappkit"
20 - Ne pas autoriser la gestion intelligente des erreurs
???
21 - Utiliser GET au lieu de POST pour toutes les actions de destruction
Ca, c'est pour les applications accessibles aux moteurs de recherche. Qui suivront tous les liens en GET qu'ils trouveront. Et ne savent pas si cela correspond à un document ou une action sur un document. Trop dur pour vous.
22 - Ne pas savoir se servir des expressions régulières
Qui voudrait se priver de si belles migraines ?
23 - N'avoir jamais entendu parler d'injection SQL ou de scripting multisites
24 - Ne pas permettre de configurer simplement ses classes, que ce soit par arguments passés au constructeur, via des méthodes dédiées ou des constantes
Je suis moi-même un fanatique de la configurabilité. Un bon script générique avec une configuration spécifique peut parfois permettre de s'économiser bien des lignes de code. C'est ce qui a présidé au concept des Outils (Tools) pour Webappkit.
25 - Ne pas connaitre les bénéfices et limitations de la programmation orienté objet
J'ai du mal à me souvenir de ma brève période procédurale puis fonctionnelle...
26 - Mal utiliser la POO
27 - Penser que du code réutilisable implique du code POO
Parfois une bonne fonction peut suffire, mais ça devient rare...
28 - Mal choisir ses valeurs par défaut
29 - Ne pas avoir un unique fichier de configuration
Pas d'accord. Les premières versions de webappkit fonctionnaient comme cela et pour de grosses applis, cela devient un enfer à maintenir. D'autant que tout n'est pas forcément utilisé et ralentit donc inutilement le tout.
30 - Croire masquer le contenu d'un script en le renommant .inc au lieu de .php
31 - Ne pas utiliser une couche d'abstraction de base de données.
Je plaide coupable. Je suis masochiste et je préfère faire mon SQL à la main.
32 - Se répéter. Si vous devez faire du copier-coller de code, il y a sans doute une erreur de design.
33 - don't make a function/class/method do just one thing and don't make them interact.
Moi pas compris. Toi parler moi ?
34 - Ne pas se servir des mécanismes objets tels qu'interface, héritage multiple et (modifeurs d'accès ?)
35 - Ne pas optimiser l'architectire de son application en suivant les motifs de conceptions éprouvés.
36 - Ne pas autoriser les chemins relatifs
Les chemins absolus, c'est le mal. Vous brulerez en enfer pour cela.
37 - Polluer l'espace de nommage global en en préfixant pas ses noms de fonctions.
38 - Ne pas autoriser le prefixage des tables de sa base de données
39 - Utiliser un moteur de gabarits séparé
Hein ? Quoi ? Qu'est-ce qu'il entend par "séparé" ?
40 - Ne pas s'inspirer des frameworks PHP existants
Les frameworks Python, ça compte ?