[Tutoriel] L'art de programmer salement

**Sodium** · 30/12/2016, 20h46

Je viens réveiller ce topic avec quelques bonnes pratiques ~~conseillées~~ imposées par le développeur avec qui je travaille et qui est mon responsable, un expert auto-proclamé du code propre et performant qui considère que ceux ne travaillant pas comme lui sont des idiots incompétents :

Un grand classique mais qui ne reste primordial : ne jamais commenter le contenu d'une fonction, même et surtout si elle fait plus de 500 lignes avec 6 ou 8 niveau de boucles et de conditions imbriqués
Ne jamais instancier plusieurs fois un même objet mais passer par un singleton. Si l'on a réellement besoin de plusieurs versions distinctes de la classe (pour instancier plusieurs formulaires par exemple), rajouter dans l'unique objet des tableaux de propriétés pour chaque besoin
Ne pas utiliser de framework, de plugins JavaScript ou de version de PHP ayant moins de 5 ans car les versions récentes sont "pleines de bugs"
Réécrire environ 90% des fonctionnalités du-dit framework car ses développeurs sont forcément incompétents
Ne surtout pas utiliser quoi que ce soit se rapprochant d'un début d'IDE. Un vrai développeur travaille uniquement avec une invite de commande et VIM
Ne surtout pas respecter le principe de single responsability. Mieux vaut une classe de 2000 lignes que 2-3 classes légères car les objets c'est "lourd et il faut privilégier la performance"
Effectuer toutes les validations de formulaire en JavaScript uniquement, de toute façon tout le monde a JavaScript aujourd'hui
Construire ses requêtes SQL en 20 étapes avec 3 sous-requêtes imbriquées sur la même ligne. Pour les noms de tables, utiliser uniquement des abréviations impcompréhensibles.
Utiliser PDO mais sans les requêtes préparées. Se soucier des injections SQL, c'est pour les faibles.
Ne jamais utiliser de return false au début d'une fonction car avoir plus d'un return c'est "interdit". Tant pis si ça oblige à imbriquer 5 ifs, au moins c'est propre.
Passer les variables par référence car c'est plus performant (après vérification non, c'est même l'inverse)
Ne jamais déclarer une variable dont on n'est pas sûr à 100% d'avoir besoin. Si une méthode d'une classe n'a pas besoin d'une ou deux variables, interdit de les déclarer dans un constructeur, il faut les redéclarer individuellement dans chaque fonction

**foetus** · 30/12/2016, 21h41

Envoyé par Sodium

Ne jamais instancier plusieurs fois un même objet mais passer par un singleton.

Je ne sais pas si le singleton est un problème, mais lorsque tu utilises un singleton tu peux le faire + ou - proprement

Tu planques ton singleton et tu passes par une fonction/ procédure inline proxy

Envoyé par Sodium

Mieux vaut une classe de 2000 lignes que 2-3 classes légères

Cela dépend du contexte

.

Lorsque tu fais une application IHM, des fois c'est plus pratique d'avoir 1 grosse classe contrôleur qui gère tous les évènements, callbacks, la vue (passive view), ...

Envoyé par Sodium

Pour les noms de tables, utiliser uniquement des abréviations impcompréhensibles.

Je me suis aperçu qu'avec Access

, le moteur considère par défaut certains mots (par exemple "name" "id") comme des alias/ "placeholders".

Soit tu les échappes dans les requêtes, soit tu désactives cette "fonctionnalité" ... soit tu mets des abréviations

Envoyé par Sodium

Tant pis si ça oblige à imbriquer 5 ifs, au moins c'est propre.

En C si tu veux gérer toutes les erreurs avec 1 seul endroit pour nettoyer la mémoire, c'est une façon de faire

Sinon tu peux utiliser un booléen bool_tmp.
À la fin de la première étape il faut qu'il soit bien rempli en gérant tous les cas de la première étape (faux ou vrai en cas d'erreurs ou pas).
Et ensuite à chaque étape tu le testes (si bool_tmp est vrai + éventuellement d'autres tests) pour faire l'étape. Et en cas d'erreur tu passes bool_tmp à faux.

**Iradrille** · 30/12/2016, 21h42

Envoyé par Sodium

Ne jamais déclarer une variable dont on n'est pas sûr à 100% d'avoir besoin. Si une méthode d'une classe n'a pas besoin d'une ou deux variables, interdit de les déclarer dans un constructeur, il faut les redéclarer individuellement dans chaque fonction

J'aurais tendance à être d'accord avec ça, si tu peux remplacer un membre par une variable locale; à priori c'est que tu n'en a pas besoin.
Si tu commences à déclarer des variables globales pour sauvegarder ta variable locale entre 2 appels de fonctions, c'est que tu en avais besoin au final

**Sodium** · 30/12/2016, 22h58

Je ne sais pas si le singleton est un problème, mais lorsque tu utilises un singleton tu peux le faire + ou - proprement

Tu planques ton singleton et tu passes par une fonction/ procédure inline proxy

Si le singleton peut se défendre pour une classe utilitaire qui ne fait que répondre à une demande sans avoir de vie propre (et encore mieux vaut qu'elle soit instanciée et accédée via le framework), c'est déjà nettement moins le cas lorsqu'il s'agit d'un formulaire avec ses propres champs, validations etc. Surtout que dans mon cas il s'agissait d'une classe abstraite héritée par d'autres classes.

Sinon tu peux utiliser un booléen bool_tmp.
À la fin de la première étape il faut qu'il soit bien rempli en gérant tous les cas de la première étape (faux ou vrai en cas d'erreurs ou pas).
Et ensuite à chaque étape tu le testes (si bool_tmp est vrai + éventuellement d'autres tests) pour faire l'étape. Et en cas d'erreur tu passes bool_tmp à faux.

Et donc rajouter des conditions qui alourdissent le code tout en obligeant un autre programmeur à lire l'ensemble de la fonction alors qu'avec un simple return false au début, la lecture est claire. Je ne dis pas qu'il faut faire des fonctions à 40 returns, juste qu'il faut savoir être pragmatique et ne pas ériger certains principes en paroles sainte quitte à rendre son code incompréhensible.

J'aurais tendance à être d'accord avec ça, si tu peux remplacer un membre par une variable locale; à priori c'est que tu n'en a pas besoin.
Si tu commences à déclarer des variables globales pour sauvegarder ta variable locale entre 2 appels de fonctions, c'est que tu en avais besoin au final

Non non, là c'est plutôt que le type instancie le même modèle et effectue les même vérifications de droits d'accès dans chaque action du contrôleur dans un pure soucis de performances.
Par contre, il charge l'ensemble des fichiers de traductions, configuration etc sur chaque page du site, quelques milliers de variable au total dont seule une fraction est utilisée.

**el_slapper** · 02/01/2017, 09h56

Envoyé par Sodium

Un grand classique mais qui ne reste primordial : ne jamais commenter le contenu d'une fonction, même et surtout si elle fait plus de 500 lignes avec 6 ou 8 niveau de boucles et de conditions imbriqués

Sur celui-là, d'accord avec toi : "pas de commentaires", c'est du sexy coding, et ça a des règles, à commencer par des routines courtes et bien nommées.

Envoyé par Sodium

Ne jamais instancier plusieurs fois un même objet mais passer par un singleton. Si l'on a réellement besoin de plusieurs versions distinctes de la classe (pour instancier plusieurs formulaires par exemple), rajouter dans l'unique objet des tableaux de propriétés pour chaque besoin

Faut voir le cas précis, mais effectivement, dans la plupart des cas, c'est "pourquoi faire simple quand on peut faire compliqué."

Envoyé par Sodium

Ne pas utiliser de framework, de plugins JavaScript ou de version de PHP ayant moins de 5 ans car les versions récentes sont "pleines de bugs"

C'est parfois vrai. Donc, voir au cas-par-cas.

Envoyé par Sodium

Réécrire environ 90% des fonctionnalités du-dit framework car ses développeurs sont forcément incompétents

Là, par contre, c'est du masochisme pur et dur : soit on utilised un framework, soit on se fait le sien, mais un entre-deux de ce genre est un appeau à problèmes.

Envoyé par Sodium

Ne surtout pas utiliser quoi que ce soit se rapprochant d'un début d'IDE. Un vrai développeur travaille uniquement avec une invite de commande et VIM

VIM est surpuissant, mais bon, il y a aussi des outils rigolos dans les IDE modernes. Qu'il préfère VIM, c'est son problème. Qu'il l'impose est bien plus emmerdant.

Envoyé par Sodium

Ne surtout pas respecter le principe de single responsability. Mieux vaut une classe de 2000 lignes que 2-3 classes légères car les objets c'est "lourd et il faut privilégier la performance"

Là encore, la réponse standard de l'ingénieur standard : ça dépend. Ca dépend des contraintes, ça dépend du métier. Quand tu commences à avoir des setters/getters bien épais, qui eux même pointent sur des getters-setters bien épais, qui eux-mêmes... tu peux avoir des problèmes de performance. Il y a aussi des cas métiers, rares mais réels, ou le code est un bête script très long, et l'utilité de le couper en morceaux de 3 (ou même 30) lignes est inexistante.

Ce qui me gêne, c'est qu'il en fait un standard, alors que clairement, dans la majorité des cas, son dogme est inadapté.

Envoyé par Sodium

Construire ses requêtes SQL en 20 étapes avec 3 sous-requêtes imbriquées sur la même ligne. Pour les noms de tables, utiliser uniquement des abréviations incompréhensibles.

Ca, c'est mal. A la maintenance, la difficulté de maintenir un code augmente linéairement avec sa taille. La difficulté de maintenir une requête SQL, elle, augmente exponentiellement avec sa taille, parceque c'est un bloc unique.

Envoyé par Sodium

Utiliser PDO mais sans les requêtes préparées. Se soucier des injections SQL, c'est pour les faibles.

euh, c'est sérieux, là???

Envoyé par Sodium

Ne jamais utiliser de return false au début d'une fonction car avoir plus d'un return c'est "interdit". Tant pis si ça oblige à imbriquer 5 ifs, au moins c'est propre.

Ca, c'est un débat qui dure depuis l'invention de la routine. Ca brise le flux naturel des données. Mais ça allège le code. Ca augmente la complexité cyclomatique du code. Ca simplifie la lecture. Je n'ai pas d'avis là-dessus.

Envoyé par Sodium

Passer les variables par référence car c'est plus performant (après vérification non, c'est même l'inverse)

ça, si c'est vérifié et qu'il le nie, on a pas à faire à un scientifique. En cas de doute, mesurer. Là, on a à faire à un croyant, une espèce nuisible.

Envoyé par Sodium

Ne jamais déclarer une variable dont on n'est pas sûr à 100% d'avoir besoin. Si une méthode d'une classe n'a pas besoin d'une ou deux variables, interdit de les déclarer dans un constructeur, il faut les redéclarer individuellement dans chaque fonction

D'autres ont répondu là-dessus. Après, moi, j'ai beaucoup bossé en COBOL(avec la couche objet désactivée), et on a gagné beaucoup de temps(développement et maintenance) en créant des méga-structures standard en faible nombre - quitte à avoir pas mal de vide dedans - plutôt que des micro-structures adaptées à chaque étape du traitement. Comme ce ne sont pas des objets, mais de simples définitions de données, et comme en plus les étapes intermédiaires sont des fichiers temporaires effacés assez rapidement, le coût en termes de performances était négligeable. Dans une structure objet, il faudrait mesurer. Le risque, je l'ai déjà évoqué plus haute, c'est de faire des méga contrôles à chaque fois qu'on accède à la donnée(ce qui n'est pas possible sans objet), et, effectivement, de faire ramer le proc.

A mesurer.

**ManusDei** · 02/01/2017, 11h00

Envoyé par el_slapper

VIM est surpuissant, mais bon, il y a aussi des outils rigolos dans les IDE modernes. Qu'il préfère VIM, c'est son problème. Qu'il l'impose est bien plus emmerdant.

Ca veut dire quoi "surpuissant" dans ce cas ? Je connais très peu VIM, j'ai vu quelques collègues l'utiliser, pour le débogage en particulier l'interface était quasiment la même que celle que j'ai sous Eclipse. Celle d'Eclipse était plus jolie (ça on s'en fout), mais il y avait les mêmes "fenêtres" avec le code, la mémoire etc...
La grosse différence que j'ai vu c'est qu'il n'y avait guère de menu, les collègues utilisaient plein de raccourcis là où j'en utilise quelques uns seulement (pour le reste je cherche dans les menus).
Donc oui VIM prend beaucoup moins de mémoire (voire pas du tout comparé à Eclipse

), mais je n'ai pas l'impression qu'il y ait des fonctionnalités en plus.

PS : je ne cherche pas à lancer un troll, je me pose vraiment la question.

**tchize_** · 05/01/2017, 02h33

Envoyé par el_slapper

VIM est surpuissant, mais bon, il y a aussi des outils rigolos dans les IDE modernes. Qu'il préfère VIM, c'est son problème. Qu'il l'impose est bien plus emmerdant.

Ca me rappelle un prestataire. Une boite de geeks qui a décidé d'engager une secrétaire pour gérer les clients / facturation. Ils lui ont donc configuré un pc sous linux et une boite mail. Pour lire la boite mail, elle n'avait le droit d'utiliser que vim. Elle n'a pas tenu une semaine

**el_slapper** · 05/01/2017, 09h20

Envoyé par tchize_

Ca me rappelle un prestataire. Une boite de geeks qui a décidé d'engager une secrétaire pour gérer les clients / facturation. Ils lui ont donc configuré un pc sous linux et une boite mail. Pour lire la boite mail, elle n'avait le droit d'utiliser que vim. Elle n'a pas tenu une semaine

Tu m'étonnes. C'est surpuissant, mais il faut un sacré investissement personnel - et une certaine tournure d'esprit - pour utiliser toute sa puissance. Je n'en suis pas là, d'ailleurs(mon usage est très limité, je travaille sur des scripts d'une quinzaine de lignes, sous LINUX, et rarement.....)

**zecreator** · 05/01/2017, 13h47

En fait, tant que le code fait le job demandé, kénen-a-nafoute. Si le ou les mecs qui reprennent le code ne sont pas des tanches, ils réussiront à le ré-exploiter. Sinon, faut changer de métier.

Tiens, un fait divers :
http://www.20minutes.fr/insolite/174...parfois-visite

Le SDF il devait pas être très propre, pourtant il a fait le job. A méditer...

Zecreator.

**foetus** · 05/01/2017, 14h17

Envoyé par zecreator

Le SDF il devait pas être très propre, pourtant il a fait le job. A méditer...

Si c'est la même histoire, mais je ne l'ai pas suivi, le boulanger a employé le SDF suite à son geste.

Mais le boulanger l'a viré au bout de 4 - 6 mois parce qu'il picolait ou trafficotait il me semble

**zecreator** · 05/01/2017, 16h41

Comme on dir : le gibier, c'est meilleur quand la viande a un peu pourrie... Les mecs qui mettent en avant qu'un bon code doit être bien formaté, commenté... sont souvent les premiers à écrire du code à l'arrache bien grossié. En fait, ils fantasment les mecs

**Cpt Anderson** · 11/01/2017, 16h46

Juste pour la rigolade, j'ai bossé pour une société dont je tairais le nom mais qui distribue du matériel informatique, dont le nom qui tient sur 4 lettres et qui est sponsor de l'ASVEL

Bref, nous avons eu droit à tout ce qu'il ne faut pas faire, bien sur, mais je me rappelle d'une fonction qui était à peu près comme celle la :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Function IsItTrueOrFalse (a, b: integer): boolean;
begin
if a=4 or b=5 then
Result:=true
else if b=6 and a=7 then
Result:=true
else if b+a=13 then 
Result:=false;


Result:=true;
end ;

Voilà le travail

Ah et aussi, je me rappelle d'une phrase d'un ancien responsable de développement, mais c'était dans une autre entreprise qui m'a dit, droit dans les yeux :

Il va falloir t'habituer à faire du code sans bug

Avec lui, j'ai tenu moins de 3 mois...

Invité · 11/01/2017, 17h32

J'avais eu à débugger une fonction comme ça qui devait détecter un cas rare en suivant une analyse complexe et un cahier des charges bien sexy.

Après voir passé plusieurs heures à comprendre ce qui avait déjà été fait, de façon particulièrement dégueulasse et sans commentaires pertinents, évidemment, je suis arrivé à la dernière ligne qui donnait RETURN TRUE...

J'ai tout jeté, maudit le type qui avait fait ça pour trois générations. Bon, je viens de voir qu'il était devenu chef de projet... C'est dans la logique des choses.

**escartefigue** · 12/01/2017, 11h16

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Après voir passé plusieurs heures à comprendre ce qui avait déjà été fait, de façon particulièrement dégueulasse et sans commentaires pertinents, évidemment, je suis arrivé à la dernière ligne qui donnait RETURN TRUE...

Ca peut être un fonctionnement normal transitoire, quand des composants ne sont pas prêts, on fonctionne temporairement en mode bouchonné avec une réponse figée
Mais en ce cas, la moindre des choses est de le mentionner avec un GROS COMMENTAIRE BIEN LISIBLE, et en précisant si possible, la date prévue de "débouchonnage"

**zecreator** · 18/01/2017, 12h24

Envoyé par escartefigue

Ca peut être un fonctionnement normal transitoire, quand des composants ne sont pas prêts, on fonctionne temporairement en mode bouchonné avec une réponse figée
Mais en ce cas, la moindre des choses est de le mentionner avec un GROS COMMENTAIRE BIEN LISIBLE, et en précisant si possible, la date prévue de "débouchonnage"

Lol, et pis quoi encore ? 10 balles et un Mars ? Tu veux pas que l'on te mette directement le planning de dev dans les commentaires lol ! En fait, pour coder proprement aujourd'hui il y a 2 solutions :

1 - On réinvente rien, on adapte du code déjà super propre.
2 - On a un planning avec une date de livraison finale dans 4 ans, et là on peut peaufiner son code pour qu'il soit le plus lisible et le plus merveilleux et le plus optimisé et le plus formidable et qui en plus me sort les poubelles

Si vraiment ces solutions ne fonctionnent pas, reste l'argument ultime : "Ben vous savez, le code est généré en partie par le framework, on peut pas tout réécrire à la main.". Ce truc, je l'ai vu fonctionné bien des fois (la faute à l'outil incontrôlable), et ça passe.

Franchement, allez, dites-le, qui prend le temps de parcourir tout ses 300 scripts pour faire le la belle indentation, et commenter chaque variable, chaque fonction, chaque bidouille à la con ? Qui fait ça ?

Zecreator.

**foetus** · 18/01/2017, 16h23

Envoyé par zecreator

Qui fait ça ?

Une certitude: celui qui ne le fait pas c'est la personne qui demande de commenter son code

**zecreator** · 21/01/2017, 11h00

Envoyé par foetus

Une certitude: celui qui ne le fait pas c'est la personne qui demande de commenter son code

Haaa oui, la méthode de faire faire par d'autre ce que l'on fait pas, en argumentant que ceux sont de bonnes habitudes. J'ai dejà entendu, j'ai déjà entendu...

**Sodium** · 26/01/2017, 18h32

Je tombe sur des tas de trucs rigolos en parcourant le code de mon cher collègue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
$dep = substr($ref, 0, 1) == '5';
$not = (int)$value['see'] === 2
     || stristr($value['prbrands'], 'ARTICLE DELETED')
     || (stristr($value['prbrands'], 'GENERAL CREDITERS') && $dep)
     || stristr($value['en'], 'ARTICLE MISC')
     || stristr($value['en'], 'ARTICLE DIV')
     || in_array($ref, $fish)
     || (isset($value['en']) && stristr($value['en'], 'form'));

    if (!$not) {
    //...

Ah ben oui, if $not, c'est pourtant limpide...

La fonction fait à peu près 300 lignes comme ça, sans le moindre commentaire.

**zecreator** · 27/01/2017, 11h01

Envoyé par Sodium

Je tombe sur des tas de trucs rigolos en parcourant le code de mon cher collègue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
$dep = substr($ref, 0, 1) == '5';
$not = (int)$value['see'] === 2
     || stristr($value['prbrands'], 'ARTICLE DELETED')
     || (stristr($value['prbrands'], 'GENERAL CREDITERS') && $dep)
     || stristr($value['en'], 'ARTICLE MISC')
     || stristr($value['en'], 'ARTICLE DIV')
     || in_array($ref, $fish)
     || (isset($value['en']) && stristr($value['en'], 'form'));

    if (!$not) {
    //...