Si tu veux pouvoir changer de Bdd, il vaut mieux un addshlashes qu'un mysql_escape_sting
Suis plus partisan d'un vrai modèle d'abstraction de la couche db. Mais après, on rentre dans des querelles de chapelle. :-)
Effectivement si demain un autre devrait reprendre certaines applications, il devrait passer un peu de temps à comprendre certains algo et la logique de la chose.
Bah... s'il y a une doc qui explique le tout, c'est déjà ça. Il y a bien évidemment des sections/applications critiques où l'on ne peut faire que du spécifique, mais ce n'est effectivement pas les mêmes contraintes.
Exploser en plein d'objets différents avec des méthodes privées et publiques, des couches différentes ne donne pas forcement plus de facilité à prendre en main la chose.
On ne se comprends qu'à demi-mot : faire de l'objet, ce n'est pas appliquer toutes les possibilités présentées dans un bouquin sur les technologies objets, ni découper une appli en couches non cohérentes, tordues ou non optimisées pour la performance du code.
et pas des moindes, le code le plus difficile à percer est souvent le code le plus long, avec des appels dans des appels dans des appels.
Quand ce ne sont pas des includes qui se marchent sur les pieds et remplacent la logique d'appel de fonction (avec toute la gestion impliquée des variables globales qui deviennent dès lors des paramètres potentiels).
Je suis d'accord avec toi, il y a plein de code goret, mais cela ne veut pas dire que ceux qui ne code pas comme toi sont des gorets. :-)
Je n'ai jamais dit ça. Chacun son style de code, et tout projet doit avoir le sien.
Il n'empêche qu'un code mal écrit (style, nommage, construction, algorithme, factorisation, tout ça) est très souvent révélateur d'un travail bâclé, mal conçu, tordu. Et la plupart du temps également, le code est buggé, peu fonctionnel ou extensible, voir troué (je n'ai que très rarement vu un code php pratiquement illisible mais révélant un truc bien réfléchi).
Ce qui ne veut pas dire qu'un codeur de type artisan puisse livrer un code très efficace, fonctionnel et illisible. Mais son illisibilité est son pire défaut pour son cycle de vie : on préférera jeter et tout réécrire histoire d'arriver à comprendre si cela fait bien ce que c'est censé faire - ni plus, ni moins (à moins de disposer d'ici là d'un outil de preuve).
[^] # Re: Curiosité...
Posté par romain . En réponse au journal Offre d'emploi Développeur Web (Paris). Évalué à 2.
Bah... s'il y a une doc qui explique le tout, c'est déjà ça. Il y a bien évidemment des sections/applications critiques où l'on ne peut faire que du spécifique, mais ce n'est effectivement pas les mêmes contraintes.
On ne se comprends qu'à demi-mot : faire de l'objet, ce n'est pas appliquer toutes les possibilités présentées dans un bouquin sur les technologies objets, ni découper une appli en couches non cohérentes, tordues ou non optimisées pour la performance du code.
Quand ce ne sont pas des includes qui se marchent sur les pieds et remplacent la logique d'appel de fonction (avec toute la gestion impliquée des variables globales qui deviennent dès lors des paramètres potentiels).
Je n'ai jamais dit ça. Chacun son style de code, et tout projet doit avoir le sien.
Il n'empêche qu'un code mal écrit (style, nommage, construction, algorithme, factorisation, tout ça) est très souvent révélateur d'un travail bâclé, mal conçu, tordu. Et la plupart du temps également, le code est buggé, peu fonctionnel ou extensible, voir troué (je n'ai que très rarement vu un code php pratiquement illisible mais révélant un truc bien réfléchi).
Ce qui ne veut pas dire qu'un codeur de type artisan puisse livrer un code très efficace, fonctionnel et illisible. Mais son illisibilité est son pire défaut pour son cycle de vie : on préférera jeter et tout réécrire histoire d'arriver à comprendre si cela fait bien ce que c'est censé faire - ni plus, ni moins (à moins de disposer d'ici là d'un outil de preuve).