Comment bien programmer en PHP ? [Débat]

[KiLVaiDeN]

Salut,

Juste une remarque au sujet des commentaires et documentations; En cours on nous dit qu'il faut tout commenter et tout documenter, mais c'est faux !

Il vaut mieux mille fois utiliser des variables parlantes, et ne commenter que ce qui mérite explication, en s'adressant à un développeur ( ce n'est pas une personne incompétente qui va lire le code source de toute manière ).

Il faut attacher plus d'importance à la qualité et la lisibilité du _CODE_ plutôt que de faire du code illisible et d'espérer qu'un commentaire va sauver le coup en "expliquant" ce qu'un bout de code incompréhensible fait; Ca ne change rien ou pas grand chose au fait que si quelqu'un doit reprendre le travail derrière, il devra quand même comprendre le fonctionnement du code en lui même.

La documentation, c'est un peu pareil; Documenter techniquement une application en long en large et en travers, c'est bien beau, mais ça ajoute beaucoup de contraintes; Une modification sur l'application doit également se répercuter sur la doc, et en général ça fait perdre beaucoup de temps. J'ai été confronté à beaucoup de projets où une doc existait au préalable, mais vu que les délais pour les maintenances évolutives ou correctives étaient courts, ça ne laissait pas le temps au développeurs de modifier les documentations, ce qui les rend obsolètes, et même dangereuses !

En gros, avec l'expérience que j'ai acquise, voila ce que j'en pense : les commentaires doivent être purement fonctionnels, le code doit être lisible et compréhensible facilement par un autre développeur ( vive l'orienté objet ! ) et la documentation doit être facilement modifiable et pas trop abondante pour permettre à un développeur de rapidement la modifier si cela s'avère nécessaire.

A+

[UNi[FR]]

Envoyé par fadex

par exemple :
Code le plus court :

Code :

Code le plus rapide :

Code :

Autre solution :

Code :

1
2
3
4
5
 
for ($i=0, $count = count($array); $i<$count; $i++)
{
  echo $array[$i];
}

Sinon pour bien programmer :

- Bien organiser son code (ne pas hésiter à chercher de nouvelles méthodes)
- Développer en POO
- Se créer des bibliothéques, librairies (ou utiliser de l'existant) pour faire le plus modulaire possible
- Bien documenter son code (de façon intelligente)
- Etre en constante veille technologique pour améliorer ses methodes de développement

...

Et bien d'autres choses mais je vais m'arréter là ;0)

[PascalEmd]

D'utiliser des simples cotes à la place de double ou toutes les autres petites recette de cuisine que je viens de voir ce n'est pas de l'optimisation. De faire de la POO non plus.

J'ai vu une quantité de développeurs s'imaginer qu'en faisant de la POO ils auraient un code propre et optimisé. Arrêtez de rêver. Pour faire de la bonne POO il faut faire une bonne conception objet. Et c'est autre chose que de fourrer son code dans des objets. Malheureusement avec PHP, l'objet se résume à cela. Et faire de l'objet avec un langage non typé qui ne gère pas la surcharge d'opérateur ça vous semble "optimisé" ?

Bon, ça c'était pour le coté objet, j'attaquerai le coté optimisation classique où "comment éviter d'appliquer bêtement des recettes de cuisine" plus tard !

[tofou.letram]

Envoyé par Sub0

• J'utilise les tableaux pour les constantes, variables, données... et la commande global pour les intégrer dans mes fonctions.

Personellement, je n'utilise jamais de déclaration global. Non seulement, cela rend le code beaucoup plus difficile à lire et à maintenir (surtout lorsqu'il y a plusierus developpeur sur un même projet) mais également moins sécurisé (une variable globale pouvant être modifié à n'importe quel endroit.
Pour rendre global des variable, j'utilise tout simplement le design-pattern "singleton".

Pour php 4, un singleton s'obtient par le code :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
 
<?php
class MySingleton {
 
    var $options;
 
    var $loaded;
 
    function isInstance($obj) {
        return is_object($obj) === false
            ? false
            : (is_a($obj, 'MySingleton') === false
                ? false
                : (is_subclass_of($obj, 'MySingleton') == false
                    ? false
                    : true));
    }
 
    function &getInstance() {
        static $instance;
        if (MySingleton::isInstance($instance) == false) {
            $instance = new MySingleton();
        }
 
        return $instance;
    }
 
    function MySingleton() {
        $this->options = array();
 
        $this->loaded = false;
    }
 
    function isLoaded () {
        return $this->loaded;
    }
 
    function getOptions () {
        return $this->options;
    }
 
    function fill ($file) {
        $this->options = parse_ini_file($file, true);
        $this->loaded = true;
    }
 
    function store ($key, $value) {
        $this->options[$key] = $value;
    }
 
    function has ($key) {
        return array_key_exists($key, $this->options);
    }
 
    function get ($key) {
        return $this->options[$key];
    }
 
 
}
 
 
?>

et s'utilise :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
// dans init.php, par exemple
// tres important, sans l'esperluette, vous obtener une copie du singleton
// et aucune modification ne sera appliquées à la propriété static $instance
// A noter : en php4, on ne peut pas faire : MySingleton::getInstance()->une_methode()
// vive le modèle objet de php4
$_s = &MySingleton::getInstance();
$_s->fill('./conf/db.ini');
 
// dans un autre fichier
// pour juste recuperer un valeur
MySingleton::getInstance()->get('bd_name');
 
// pour modifier une valeur
// cf ci dessus.
$_s = &MySingleton::getInstance();
$_s->set('db_name', 'db_test');

en php 5, le code est nettement plus simple:

• les objet n'étant plus manipulé en tant que copie mais en tant que référence
• php5 supportant les membres statique ainsi que la visibilité
• l'opérateur instanceof
• on peut enfin "enchainer" les fonctions

Ce qui donne :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
<?php
class MySingleton {
 
    static protected $instance;
 
    protected $options;
 
    protected $loaded;
 
    public function isInstance($obj) {
        return is_object($obj) === false
            ? false
            : ($oj instanceof MySingleton);
    }
 
    public function getInstance() {
        if (MySingleton::isInstance(self::$instance) == false) {
            self::$instance = new MySingleton();
        }
 
        return $instance;
    }
 
    protected function MySingleton() {
        $this->options = array();
 
        $this->loaded = false;
    }
 
    ...
 
 
}
?>

et s'utilise :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
// dans init.php, par exemple
// tres important, sans l'esperluette, vous obtener une copie du singleton
// et aucune modification ne sera appliquées à la propriété static $instance
// A noter : en php4, on ne peut pas faire : MySingleton::getInstance()->une_methode()
// vive le modèle objet de php4
MySingleton::getInstance()->fill('./conf/db.ini');
 
// dans un autre fichier
// pour juste recuperer un valeur
MySingleton::getInstance()->get('bd_name');
 
// pour modifier une valeur
// cf ci dessus.
MySingleton::getInstance()->set('db_name', 'db_test');

De façon générale, je pense qu'il faut toujours penser à utiliser les design-pattern de base (beaucoup sont décrit dans la section http://uml.developpez.com/ et on en trouve pas mal sur le site de zend ) et a découper le code metier de la vue a proprement dite (en utilisant un framework MVC ou bien en faisant marcher sa tête).

Pour ceux qui ne veulent / peuvent pas utiliser de framework dédié à la gestion du MVC, je conseillerais de toujours séparer le code "fonctionel" du code de l'affichage. Pour cela, la "construction" de page suivante, même si elle est extremement sommaire, le permet :

• si on a accès à la propriété auto_prepend, rajouter un script qui charge la configuration principale du site (source de données, configuration php, etc...). On peut également passer par mod_rewrite via apache mais c'est beaucoup moins bien
• la page commence par traité les actions possible de la page (traitement des formulaires, etc...)
• la page récupère les données a traiter
• on affiche la page avec les données récupérées précédement

Cette dernière démarche peut sembler evidente mais je connais beaucoup de développeur qui s'ammuse à imbriquer du SQL dans du HTML dans du traitement de formulaire.

Enfin, une dernière note (que j'ai failli oublier) : la première chose à faire est de savoir quel encodage de fichier on utilise (UTF-8 ou ISO - php 5 et inf. on de gros problème avec l'UTF-8, hélas), si on utilise des espaces à la place des tabulation et de formater son code en suivant un guideline (il y en a plein, personellement, j'utilise celui de SUN)...et ne pas avoir peur de bien aerer son code source...
Ceux qui pensent que cela est inutile non jamais fait de debuggage urgent sur un serveur de production ou il y a que VI...




Je pourrais continuer des heures et des heures comme à parler des meilleurs pratiques de codage - surtout pour le web - mais mon patron n'apprécirais peut-être pas

[wamania]

Bon, ça c'était pour le coté objet, j'attaquerai le coté optimisation classique où "comment éviter d'appliquer bêtement des recettes de cuisine" plus tard !

C'est bien la première fois que je lis ça.
L'utilisation de simpe quote n'est pas une "recette de cuisine", mais une règle. PHP autorise l'incorporation porc de variable directement dans des string, mais ça n'est PAS une utilisation normal.
Une variable est une variable et un string, c'est un string. Dans tous les langages c'est comme ça. Ensuite, pour un string, le simple quote est plus rapide car par déf, il n'est pas parsé. Donc pourquoi ne pas naturellement prendre le plus rapide?

J'ai vu une quantité de développeurs s'imaginer qu'en faisant de la POO ils auraient un code propre et optimisé.Arrêtez de rêver.

J'ai aussi vu un paquet de gens mettre des $_POST ou $_SESSION directement dans des classes, c'est effectivement porc. J'ai vu des gens mettre la couche métier dans la vue car ça va plus vite...On a tous vu plein de codes porcs.
La POO n'est-elle pas pour autant une très bonne manière de faire un code clair?
Pcq des gens s'en servent mal, il ne faut plus s'en servir?

Malheureusement avec PHP, l'objet se résume à cela. Et faire de l'objet avec un langage non typé qui ne gère pas la surcharge d'opérateur ça vous semble "optimisé" ?

PHP5 gére la surcharge de quelques opérateurs.
Je vois pas le lien entre optimisation et surcharge d'opérateur...
Le C ne gère pas la surcharge d'opérateur....pas optimisé

Bref, le sujet n'est pas l'optimisation, mais la propreté du code.
Tu as l'air d'en savoir long sur le sujet, pourtant, je vois rien de concret, que des remarques négatives, rien de constructif

Bon, ça c'était pour le coté objet, j'attaquerai le coté optimisation classique

Que ça soit Objet ou classique, je vois pas ce que tu as apporté à ce topic
Explique nous ceci par exemple

Code :

Pour faire de la bonne POO il faut faire une bonne conception objet.

80% des lecteurs n'ont à mon avis pas saisis le sens direct de ta phrase.

++

Pour tofou.letram
vive le singleton

[gazza]

Quelques "trucs et astuces" généraux et rapides pour PHP :

http://www.webdevlogs.com/php-speed-freaks/

On y trouve par exemple :

Code :

1
2
3
4
5
$i = 0;
$count = count($array);
while($i < $count){
    ++$i;
}

est mieux que :

Code :

1
2
3
4
$i = 0;
while($array[$i]){
    ++$i;
}

[wamania]

http://www.php.net/manual/fr/languag...verloading.php

[goodpz]

Envoyé par wamania

http://www.php.net/manual/fr/languag...verloading.php

C'est en partie vrai, d'accord
Mais ça n'est pas à proprement parler de surcharge d'opérateur dans le sens où la surcharge ne s'opère que si les membres de classe ne sont pas définis préalablement. Pouvoir surcharger purement et simplement "->" (comme en c++) serait encore plus fort.

[wamania]

C'est effectivement limité, mais c'est déjà un début.
Ce n'est d'ailleur pas une surcharge d'opérateur au sens le plus pure de la POO, mais ça montre qu'on y arrivera (PHP6 j'espere...)

[PascalEmd]

Merci d'avoir réagit à mon post.

Envoyé par wamania

C'est bien la première fois que je lis ça.
L'utilisation de simpe quote [...] Donc pourquoi ne pas naturellement prendre le plus rapide?

As-tu déjà mesuré l'impact en terme de performance de cette bonne pratique ?
Je ne suis pas sûr que ce soit flagrant. On doit gagner un petit peu.
Par contre au niveau de la lisibilité du code c'est la même chose.
Finalement c'est une bonne pratique "par principe".

La POO n'est-elle pas pour autant une très bonne manière de faire un code clair?

Non, c'est une manière différente, c'est tout. Une bonne manière de faire un code clair est d'avoir des algorithmes clairs.

Bref, le sujet n'est pas l'optimisation, mais la propreté du code.
Tu as l'air d'en savoir long sur le sujet, pourtant, je vois rien de concret, que des remarques négatives, rien de constructif

La propreté du code n'a-t-elle pas d'intérêt que si elle permet d'optimiser son temps de maintenance ou d'évolution ?
C'est donc bien lié.

Code :

Pour faire de la bonne POO il faut faire une bonne conception objet.

80% des lecteurs n'ont à mon avis pas saisis le sens direct de ta phrase.

C'est vrai que je n'ai pas été très clair.
La programmation objet est à la mode, ce qui entraine beaucoup de développeurs à penser que c'est mieux de faire de la POO que pas (cf. autres posts de ce topic).
Pour moi, soit on aborde un problème donné suivant une méthode de conception objet et donc on l'implémentera naturellement avec un langage objet. Soit on l'aborde d'une manière "fonctionnelle" et alors je ne vois pas l'intérêt d'utiliser des objets.
Tout ça pour dire que le choix de la POO n'a pas de sens c'est avant tout un choix sur une méthode de conception.
Et donc la POO n'est pas un gage de qualité, ni d'optimisation (ni de compétence...).

[goodpz]

Envoyé par PascalEmd

As-tu déjà mesuré l'impact en terme de performance de cette bonne pratique ?

Il y a des éléments de réponses ici: http://www.php.lt/benchmark/phpbench.php
Ainsi que dans les commentaires de la documentation online de la fonction print() (de mémoire)

Personnellement, je m'efforce d'utiliser les simples quotes tant que je n'ai pas à utiliser les double quotes.

En ce qui concerne la POO, c'est clair que c'est un paradigme ni meilleur ni pire qu'un autre. L'avantage de php c'est qu'il ne force pas l'utilisation de la POO (dieu merci ; )

[Sub0]

Envoyé par tofou.letram

Pour rendre global des variable, j'utilise tout simplement le design-pattern "singleton".

Je ne sais pas où tu as vu que c'était simple...
Tous comptes fait, je vais continuer à utiliser des variables globales...

Envoyé par PascalEmd

As-tu déjà mesuré l'impact en terme de performance de cette bonne pratique ?
Je ne suis pas sûr que ce soit flagrant. On doit gagner un petit peu.
Par contre au niveau de la lisibilité du code c'est la même chose.
Finalement c'est une bonne pratique "par principe".

Par principe alors, lis ça s'il te plait : http://pbnaigeon.developpez.com/tuto...phe-guillemet/

Envoyé par PascalEmd

La programmation objet est à la mode, ce qui entraine beaucoup de développeurs à penser que c'est mieux de faire de la POO que pas (cf. autres posts de ce topic).
Pour moi, soit on aborde un problème donné suivant une méthode de conception objet et donc on l'implémentera naturellement avec un langage objet. Soit on l'aborde d'une manière "fonctionnelle" et alors je ne vois pas l'intérêt d'utiliser des objets.
Tout ça pour dire que le choix de la POO n'a pas de sens c'est avant tout un choix sur une méthode de conception.
Et donc la POO n'est pas un gage de qualité, ni d'optimisation (ni de compétence...).

Entièrement d'accord avec toi.

[Thuliad]

A la place des variables globales, je préfère utiliser des variables statiques de classe.
Ce qui manque surtout en php c'est les espaces de noms...

Par contre un conseil pour tous : arrêtez d'utiliser des post-incrémentations quand vous pouvez utiliser des pré-incrémentations, c'est valable pour tous les langages.

a++ équivaudrait à :

Code :

1
2
3
b = a;
a = a +1;
return b;

et ++a :

Code :

1
2
a = a + 1;
return a;

(valable aussi pour les décrémentations évidemment)

[sekaijin]

ne jamais définir les parametre de configuration comme des variables
toujours des constantes chargées dès le début du script
ainsi il est impossible par quelque moyen que se soit de les modifier en cours d'exécution

choisir des règles de codages et s'y tenir
lire attentivement la littérature sur les design paterns concernant la programation (rechercher un élément dans une liste, tris, condition fonction etc.)

par exemple les règles de l'art disent sur une boucle un seul point d'entrée un seul point de sortie ce qui signifie pas de break les design patterns proposent toutes sorte d'algo pour respecter ce genre de contraintes

de même unfonction n'a qu'un point de sortie marqué par un retrun même si elle ne renvoie rien.

pour ma part j'y ajoute aucune chaine destiné (elle sont définies dans des fichiers dédiés) à l'interface n'apparait dans le code pas de print pas d'echo
il n'y a qu'un point qui envois la sortie
les éléments de production son stoqués indépendament du code (les templates permettent cela mais aussi DOM)
par exemple si je vérifie que la valeur d'un form est une date je ne fais pas

Code :

$error = 'Format de date invalide';

mais

Code :

$error = ERROR_STRING_INVALID_FORMAT;

ainsi il suffit de changer de template et de fichier de message pour adapter l'application.

je limites aussi les blocs de code à une 50ene de lignes plus généralement 20 à 30 audelà je fait des fonctions (methodes).

J'explicite toujours les indirections avec un commentaire
par exemple si j'ai un variable d'instance "map" qui contient le nom d'une classe je commente toujours

Code :

1
2
3
4
$this->map = 'MaClasseAMoi';
...
//intentiation de la classe de Mapping
$mappedObject = new $this->map($params);

car il est très difficiles de lire de telles indirection si la définition du nom de la référence est loin dans le code

je mets des acolade systématiques s'il peu y avoir une ambiguité de lecture

Code :

$this->$maVariable->myField;

est équivalent à

Code :

$this->{$maVariable}->myField;

et non à

Code :

$this->{$maVariable->myField};

par prevention je mets des accolades

Je sépare les différente couche de mon application
niveau View (interface externe GUI ou API)
niveau Logique d'interface (logique d'enchainement de l'interface)
niveau Logique Applicative (règles qui régissent ce que doit faire l'application)
niveau Logique metier (règles qui définissent les composants de l'application et non coment on les utilisent)
niveau accès aux données (DAO, File Net etc.)

L'accès au donné et utilisable par toute application
les objets metiers son commun à plusieurs applis
la logique applicative définit le coeur de l'application
la logique d'interface défini le comportement de l'interface
et la vue son apparence

A+JYT

[blbird]

Juste une petite précision sur les objectifs de base de la POO :

- la réutilisation maximum de tout ou partie de vos classes
- l'évolutivité de celles-ci

Tout les avantages (et inconvénients) de la POO découlent de ces 2 objectifs.

[kaymak]

Envoyé par fadex

sekaijin :

un exemple de ces design paterns

http://www.google.fr/search?client=f...cherche+Google

http://www.google.fr/search?hl=fr&sa...chercher&meta=

http://www.google.fr/search?hl=fr&sa...chercher&meta=

en voila plus d'un.

....

[Sub0]

Je n'arrive pas à assimiler ce concept... Utiliser la POO pour les bases de données, ou par exemple réaliser une classe mail, ok. Mais dans cette article par exemple, tout ce code serait plus simple que d'écrire directement le prix qui nous intéresse ? Je ne trouve pas ça vraiment optimisé, surtout vu le nombre de ligne qu'il faut en plus par rapport à une simple fonction, sans compter cette "embrouille de code" juste pour afficher un prix :

Code :

1
2
$local = new euro_de;
echo $local->translation('price').$local->currency(14.5)."\n";

Je ne sais pas où il a vu que son code était plus propre et surtout plus maintenable qu'une simple fonction claire et facile à comprendre du genre :

Code :

1
2
3
4
5
6
function DisplayPrice($price){
  return 'The price is '.sprintf('%01.2fFF',$price*6.55957);
}
...
 
echo DisplayPrice(14.5);

Car dans tous les cas, si on a besoin de gérer plusieurs pays, il est facile d'ajouter un paramètre à cette fonction :

Code :

1
2
3
4
5
6
function DisplayPrice($price, $pays){
  switch($pays){
  case 'en' : return 'The price is '.sprintf('¤%01.2f',$price/0.7);  
  case 'fr' : return 'Le prix est de '.sprintf('%01.2fFF',$price*6.55957);
  ...
}

Pour l'instant, je n'y vois aucun intérêt à utiliser ce concept. Expliquez moi s'il vous plait

[wamania]

Imagine que tu ais 3 algo incompréhensibles et dont on t'interdit de toute façon de toucher le code.
Il faut, pour un élément donné, le traiter par l'un des algos en fonction d'un paramètre arbitraire.
Ces algos comprennent de nombreuses phases qu'il faudra appeler, toutes les phases sont "comparables".
Par de simples fonctions, tu auras

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function phase1_algo1 {
}
function phase2_algo1 {
}
function phase1_algo2 {
}
function phase2_algo2 {
}
 
//utilisation
// phase 1
if (algo 1) {
phase1_algo1();
}
elseif (algo 2) {
phase1_algo2();
}
 
// phase 2
if (algo 1) {
phase2_algo1();
}
elseif (algo 2) {
phase2_algo2();
}

Avec son design pattern, tu auras autant de classes que d'algo, implémentant la même interface, te permettant ensuite ceci

Code :

1
2
3
4
5
6
7
8
9
10
 
if (algo1) {
$algo = new Algo1();
} elseif (algo2) {
$algo = new Algo2();
}
 
//ensuite, peu importe l'algo
$algo->phase1();
$algo->phase2();

L'ajout d'un nouvel algo devient très facile et rapide, plus besoin de scanner le code à la recherche de tous les appels aux fonctions.

[Sub0]

Merci wamania pour ta réponse!
Ça devient légèrement plus claire. Cela dit :

Envoyé par wamania

L'ajout d'un nouvel algo devient très facile et rapide, plus besoin de scanner le code à la recherche de tous les appels aux fonctions.

Justement, c'est là que je ne vois pas la différence car dans tous les cas, cela demande une recherche de code même si il s'agit d'une méthode de classe plutôt qu'une fonction, et cela demande également de développer une méthode pour chaque algo... non?

[wamania]

Justement, c'est là que je ne vois pas la différence car dans tous les cas, cela demande une recherche de code même si il s'agit d'une méthode de classe plutôt qu'une fonction. Prenons l'exemple d'affichage des prix.

Avec des fonctions, il faut rechercher TOUS les appels style

Code :

1
2
3
4
5
6
if (algo 1) {
phase1_algo1();
}
elseif (algo 2) {
phase1_algo2();
}

pour ajouter le nouvel algo.
T'en loupe un, ça marche pas, imagine par exemple dans un framework avec 200 fichiers, le code ci-dessus pour être appelé depuis N fichiers différents suivants certains paramètres...

Avec le "Strategy"
Il n'y a QU'UN ajout à faire, la dedans

Code :

1
2
3
4
5
if (algo1) {
$algo = new Algo1();
} elseif (algo2) {
$algo = new Algo2();
}

L'important est dans les mots en gras, c'est là tout l'avantage du "strategy"