Discussion :

[UNi[FR]]

...
je trouve aussi qu'il vaut mieu utiliser Vertrigo Serv comme serveur local....

Pourquoi celui-là plus qu'un autre ??

[Gavroche7]

* Parcequ'il est plus rapide à démarrer que easyPHP ,

* est parce qu'il supporte PHP5 aors que easyPHP supporte la ersion PHP4.3 (jusqu'à sa esrion easyH1.8 à mon saoir) ,

* et parcequ'il ne crashe pas aussi souvent que easyPHP qui, une fois qu'il présente un problème, il faut formaer son windows et tou réinstaller à nouveau !!

[Fladnag]

* Parcequ'il est plus rapide à démarrer que easyPHP ,

* est parce qu'il supporte PHP5 aors que easyPHP supporte la ersion PHP4.3 (jusqu'à sa esrion easyH1.8 à mon saoir) ,

* et parcequ'il ne crashe pas aussi souvent que easyPHP qui, une fois qu'il présente un problème, il faut formaer son windows et tou réinstaller à nouveau !!

http://easyphp.org/telechargements.php3

* bah, faut pas abuser, par rapport au lancement d'eclipse, easyPHP c'est une F1 !

* ding ! pas la derniere version !

* jamais formaté... tu exageres un poil la, tu serais pas marseillais ?!

[UNi[FR]]

...
De toute façon , c'était mon expérience que je vous ai faits partger,
quanjd à easyPHP j'ai cessé d'utiliser il y a 2 ans , quand il s'agissait de la ersion 1.8,
j'essayerai la dernière version quand j'aurai le temps

As tu essayé WAMP5 ?? www.wampserver.com

[Sub0]

Très intérressant tout ça, je ne connaissais pas
Au fait, pour celles et ceux qui utiliseraient mon petit prog, sachez que vous avez la possibilité de copier plusieurs fois le programme (renommer par exemple firefox.exe ou ie6.exe) et de définir un navigateur pour chacun dans le fichier INI du même nom. Vous pourrez ainsi tester la compatibilité de vos scripts PHP avec différents navigateurs sans difficultés. Perso, pour choisir le navigateur dans lequel le script PHP s'exécutera, j'utilise le menu "Ouvrir avec" du bouton droit dans l'explorateur de fichiers...

J'espère que cela vous simplifiera le développement, à+

[is_null]

J'avais la même approche que Sub0 avec iMacro pour firefox, j'utilise Selenium depuis, qui permet de faire des assertions en PHP au niveau du client, totalement compatible avec l'AJAX, IE, FF et Safari.

Pour ce qui est du contrôle de versionnage de sources, subversion est très bien lorsqu'on est tout seul, mais on choisira un systême avec décentralisation du dépot comme git, bazaar ou mercurial lorsqu'on est plusieurs.

Pour ce qui est de l'environement de gestion de projet, Trac est à la mode et pour cause : il intègre interface-web à svn et git, un systême de feuille de route, un systême de gestion de tickets (bug, requêtes etc ...), dispose d'une interface CLI, et est vraiment extensible.

phpUnderControl permet de gerer la croisière d'un projet, utile si l'on fait du developpement test-d'abord, mais rapporte aussi les erreurs et avertissement au sujet de la syntaxe aussi bien dans les commentaires PHPDoc que dans le code si vous utilisez des regles pour maintenir la consistence homogene du code dans votre projet. C'est sans parler du detecteur de "bordel", de "copier-coller", et autres statistiques.

PDV fournis une config et des scripts pour etre confortable avec vim en PHP, notamment grace aux fonctions de commentaires PHPDoc

L'usage de linux est indispensable : pouvoir utiliser facilement plusieures configurations afin de reproduire celle du serveur en compilant facilement PHP, HTTP serveur et SGBD.

Enfin, je conseille quelques livres, disponnibles a prix reduit en ebook :

• PHP|Architect : Security
• PHP In Action par Marcus Baker
• PHP5 Power Programming par Derick Rethans
• PHP|Architect : Design patterns

J'espere que ce message inspirera ceux d'entre-vous qui cherchent des techniques pour ameliorer le confort dans le developpement.
Notez que je ne cite que des logiciels libres conformement aux notions democratiques de notre societe evoluee.
Notez que je concois aussi que le controle de qualite des applications developpees a sources fermees ne necessite pas d'impliquer de telles techniques.

[mon_nom_est_personne]

Je recommande fortement d'avoir toujours un oeil sur ces liens

http://www.moskalyuk.com/blog/php-op...tion-tips/1272
http://forge.mysql.com/wiki/Top10SQLPerformanceTips

Sur des petits projet on vois pas trop de differenece mais sur des tres gros projet avec une forte frequentation les difference sont monstrueuses (des requetes sql qui prennent 3s, le serveur load qui explose litteralement)

[FrankOVD]

J'ai quelques questions qui me sont venues à l,esprit en lisant plusieurs posts.

1 - Pourquoi des simples quotes plutôt que des doubles? Quelle est la différence?

2 - J'utilise echo comme une fonction normale, c'est à dire avec des parenthèses. Pourquoi plusieurs développeurs n'utilisent pas de parenthèses?

3 - Voici un code exemple, c'est très facile à comprendre et à déboguer pour moi grâce à la coloration syntaxique. Est-ce que fonctionner comme ça pose problème? Faire suivre la même indentation au code PHP ainsi qu'à l'HTML rend le code vraiment clair pour moi.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
<?
function ma_fonction() {
  $query  = "SELECT ..."; //Je ne suis pas a l'aise avc le here_hoc
  $query .= "FROM ...";
  $query .= "WHERE ...";
  if($query = mysql_result($query)) {
?>  <select id="mon_id">
<?    while($produit = mysql_fetch_assoc($result)) {
?>      <option value="<?=$produit["id"]?>"><?=$produit["nom"]?></option>
<?    }
?>  </select>
  }
}
?>

[mon_nom_est_personne]

Pour repondre a la question des parentheses la reponse est tres simple: en php les strcutures de controle peuvent etre utiliser sans parenthese. C'est pour ca que tu vois ecrit echo("blabla")/echo "blabla" ou encore include "file.php"/include("file.php").

Sinon desole de te dire ca mais ton code est un exemple de mauvaise pratique en php
A mon sens bien programmer en php c'est une architecture MVC (model view controler) qui dans les grandes lignes te dis de separer ton code php de ton code html. Soit en utilisant un moteur de template (smarty, haml et consor) ou comme suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
<?php
//ici on inclue un fichier avec toute ses requetes sql et autre operation
include "include.php";
?>
<html>
<head><title></title></head>
<body>
<?php if($num_prod > 0){ ?>
<select id="mon_id">
<?php while($produit){ ?>
   <option value="<?=$produit['id']?>"><?=$produit['nom']?></option>
<?php } ?>
</select>
<?php } ?>
</body>
</html>

include.php

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
$query  = "SELECT ..."; //Je ne suis pas a l'aise avc le here_hoc
$query .= "FROM ...";
$query .= "WHERE ...";
if($query = mysql_result($query)) {
$produit = mysql_fetch_assoc($result);
}else{
$produit = array();
}
$num_produit = count($produit);
?>

c'est pas tres propre, c'est procedural, mais ca a l'aventage si tu dois redesigner le site, tu n'as pas a refaire le code. Mais bon on va pas chipoter sur un petit exemple pareil

[FrankOVD]

Je comprends ton point, dumoins pour ce qui est de séparer le PHP du HTML, pour ce qui est de l'indentation, j'aime bien pouvoir cerner facilement une balise qui est situé dans une boucle même si cette boucle est en PHP et la balise du HTML.

Je crois que je vais intégrer ces nouvelles notions dans mes prochain projets, il faut toujours évoluer!

[Sylvain71]

Bonjour à tous,

J'ai lu le sujet un peu en diagonale donc je ne suis pas sûr à 100% que ça n'a pas déjà été dit donc je tente quand même le coup.
Pour tout ce qui concerne le nommage des variables, fichiers, classes, l'indentation etc., je vous recommande très fortement de lire la charte de codage proposée par Zend :
http://framework.zend.com/manual/fr/...-standard.html

Sinon je pense qu'il serait intéressant de discuter de la structure interne des classes pour ceux qui codent en objet. Comment les organisez vous généralement (méthodes redondantes, gestion des erreurs etc) ? Utilisez vous des bons vieux accesseurs/mutateurs en dur dans le genre getXXX() setXXX() ou passez plutôt par les méthodes magiques __get __set ?

[sekaijin]

pas de méthodes redondante je ne vois pas comment on peut en avoir.

pour ce qui est des gestion d'erreur j'applique les règles de Meyer sur la programmation par contrat
J'utilise donc les exception et les traites au plus près. par contre je n'utilise pas d'exception lorsque le contrat n'est pas respecté. en claire je ne lève pas d'exception lorsqu'on me passe un paramètre erroné. je provoque une erreur fatale
Si on appelle une méthode avec de mauvais paramètre c'est que le programme est FAUT ce n'est pas un dysfonctionnement. c'est à l'appelant de savoir ce qu'il fait.

je définit donc des classes d'exceptions propre à chaque package que j'écris.
Cela permet de ne capturer que les exception que je sais traiter à ce moment là.

J'utilise les accesseurs __get et __set lorsque cela est pertinent, le plus souvent les membres de mes classes n'ont pas à être lu ou écrit comme ça, je propose plutôt des méthodes plus ciblées
par exemple getFirstname getName et getFullName et non
getUsrName getUsrFirstName qui correspond aux noms de mes membres

de façon général les membre sont protected ou private. s'il doivent être accédé alors j'utilise __get et __set
A+jyt

[Delprog]

Bonjour,

Je me permet d'ajouter une remarque puisque personne (enfin je crois) ne l'a abordé.

Personnellement dès le départ j'ai préféré m'habituer à lire et à coder des instructions IF simples de cette manière :

Code :

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

1
2
 
$lsVar = ($lsTruc == 'machin') ? 'bidule' : 'muche';

équivalent à :

Code :

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

1
2
3
4
5
6
7
 
if ($lsTruc == 'machin') {
  $lsVar = 'bidule';
}
else {
  $lsVar = 'muche';
}

Si vous préférez cette méthode, il est plus lisible de mettre des accolades pour chaque bloc, même s'ils ne contiennent qu'une seule instruction.
Eviter :

Code :

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

1
2
if ($lsTruc == 'machin') $lsVar = 'bidule';
else $lsVar = 'muche';

Je ne sais pas...je déteste ça, après c'est peut-être idiot de ma part.

Et c'est valable pour tous les langages.

De la même manière éviter ce genre de notations :

Code :

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

1
2
3
4
5
 
$lbTest = false;
if ($lsBidule == 'toto') {
  $lbTest = true;
}

et préférer :

Code :

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

1
2
 
$lbTest = ($lsBidule == 'toto');

Je trouve ça bien plus lisible et ça évite de surcharger le code.

Après c'est un avis perso

Concernant le nommage (ça se dit ça ?:p) normalisé des variables. Il faut réfléchir dès le départ à une convention personnelle. En php plus particulièrement puisque les variables ne sont pas typées.

Exemple :

Local String : commence par $ls
Local Integer : commence par $li
Local Bool : commence par $lb

Pour les variables globales la même chose avec "$g" au lieu de "$l" (même si c'est rare de globaliser des variables en php, enfin pas rare pour certains, mais mieux vaut éviter et définir des constantes, ce qui est plus souple, plus court et plus strict).

etc.

Sinon, tout ce qui est dit dans ce topic est plus ou moins pertinent.
L'idée à retenir je dirai, c'est qu'un bon codeur commence déjà par s'interdir les feintes.
Quelque soit le langage il existe des conventions (nommage, tiens encore ce mot, des variables, indentation, constantes, différentes couches pour le web, etc.) qu'il faut respecter car tout le monde les connait et quand on aborde un nouveau code, nouveau langage et nouveau secteur, on est toujours contents de retrouver ces mêmes conventions.

On ne peut pas vraiment dire : "Comment bien coder en PHP ?", mais plutôt "Comment bien coder ?" tout court. Même si évidemment certains langages apportent des notions supplémentaires, comme la programmation pour le WEB.

Topic très intéressant en tout cas, même si je le prend très en retard.

A plus,

Benjamin.

[berceker united]

Je suis en partie d'accord avec toi. Par contre, au niveau des variables, je trouve que c'est inutile de préfixer le type de la variable. Car, je ne vois pas l'intérêt réelle de savoir le type. Avant de connaitre le type d'une variable on cherche à savoir son rôle. Si nous connaissons son rôle nous connaissons son type. Bien évidemment, cela marche s'il y a un certain protocole et que au court du script la variable change de type.

Dans mon protocole, aucune variable à le rôle de prostitué. Ce que j'appelle une variable étant une prostitué est une variable servant à tout et n'importe quoi.


A titre personnel, je préfère l'utilisation de variable à courte porté ayant un nom explicite. Le protocole que je me donne c'est au niveau des paramètre. $p_xxxx signifie que la variable provient d'un paramètre de ma méthode et si seulement elle n'a pas été modifié dans la méthode.
Exemple

Code :

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

1
2
3
4
5
private function maMethode($p_parametre){
    echo $p_parametre;
    $maVariable = $this->maMethode($p_parametre);
    echo $maVariable;
}

Pour le SQL c'est le même principe. Les paramètre a mes fonctions et procédures stockés p_xxxx et les variables à l'intérieur le protocole est d'utiliser v_xxxx

[Delprog]

Par contre, au niveau des variables, je trouve que c'est inutile de préfixer le type de la variable. Car, je ne vois pas l'intérêt réelle de savoir le type.

L'intérêt est personnel. De mon côté, j'utilise la même convention quelque soit le langage. Ca me permet par exemple de connaitre la portée d'une variable rien qu'en lisant son nom (pas besoin d'analyser les blocs).

Ca me permet également au moment d'assigner une valeur à une variable de me rendre compte immédiatement si je suis en train de faire n'importe quoi (par exemple $lbVar = 'toto' alors que c'est un booléen), je sais immédiatement qu'un truc cloche.

Evidemment on maitrise notre code, et en PHP ça n'aura aucune incidence et moins d'intérêt, mais il s'agit là de se construire une logique appliquée à n'importe quel langage et dont l'idée est de savoir que le code peut-être lu par d'autres personnes (je trouve ça plus explicite). Comme je le disais c'est une logique strictement personnelle, après on y trouve un intérêt ou non.

et si seulement elle n'a pas été modifié dans la méthode.

Oui et j'espère que ça n'arrive jamais sauf si la fonction se comporte comme une "procedure" et que le paramètre est une référence (opérateur &) à une variable externe à qui on souhaite assigner une valeur.

Encore ici, de mon côté je distingue les paramètres "$pb_param1", pour un booléen par ex., d'un passage par référence "&$pR_param1". Si quelqu'un d'autre lit le code, il comprend alors immédiatement qu'il s'agit d'une référence et fera attention (ou comprendra mieux en lisant les instructions de la fonction).

[vtuning.net]

Personnellement (et ce n'est que mon avis), j'ai utilisé plusieurs style de codage.
Je suis revenu au IF très classique. C'est à dire :

Code :

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

1
2
3
4
5
6
7
 
$true = true;
 
if ( $true === false )
{
    echo 'ok';
}

J'évite absolument la syntaxe sensée raccourcir le code.

Par exemple :

Code :

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

1
2
3
4
 
$a = $b = $c = $d = true;
 
$a = ( true ) ? true : false;

Ce que je conseille en général est d'aérer le code.
Faites le test un code aéré pèse autant en RAM qu'un code compressé devenu quasiment illisible.
De plus, ça permet en un coup d'oeuil de repérer les condition, les boucles, etc...

Je n'adhère pas trop non plus à :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
if (true) {
    echo 'true';
} else {
   echo 'false';
}
 
// Ni à
if (true)
    echo 'true';
else
   echo 'false';

Un peu de lecture :

http://www.developpez.net/forums/sho...52#post2631252

[Delprog]

De plus, ça permet en un coup d'oeuil de repérer les condition, les boucles, etc...

Justement, je ne suis pas d'accord avec ça
Après comme je disais c'est une habitude, aujourd'hui je lis beaucoup plus vite et d'un seul coup d'oeil les "IF" du type :

Code :

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

$truc = ($machin == 5) ? 'toto'  : 'tata';

que le reste.
Je précise qu'il s'agit ici de condenser uniquement les IF simplistes qui pour moi, au contraire et s'ils sont nombreux, rendent le code moins lisible.

Faites le test un code aéré pèse autant en RAM qu'un code compressé devenu quasiment illisible.

Je ne parlais pas d'alléger le code d'un point de vue "Machine" mais simplement à l'oeil du codeur.

[vtuning.net]

Oui, l'essentiel est que ta méthode te conviennes.
Fais quant même attention si quelqu'un doit reprendre ton projet.

Par contre, j'utilise quelque fois la méthode dont tu parles pour déclarer des tableaux assez longs. Quoique, je l'utilise de moins en moins.

Code :

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

1
2
3
 
array( 'abcd' => ( true ) ? true : false, 
         'efgh' => ( true ) ? true : false );

Tu as déja essayé le "code folding" (déplier et replier des bouts de code)? Je trouve ça vraiment pratique en cas de code trop long. Plusieurs IDE le permettent dont Eclipse.

[berceker united]

Pour l'histoire des if, je suis partagé.
Il m'arrive d'utiliser ceci :

Code :

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

$var = ($toto==true)?'ok':'pas ok';

ou

Code :

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

echo ($toto==true)?'ok':'pas ok';

Dans mon projet spécifique qui sera OpenSource, donc susceptible d'être lu par d'autre, je n'ai pas fait le choix de faciliter la lecture pour les autres mais en premier lieu pour moi. Je sais, mais je rentre dans ce cas, j'en finirais pas de me poser des questions. Par exemple, il y a beaucoup de développeurs qui place l'accolade en dessous de la condition.

Code :

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

1
2
3
4
5
6
7
if(...)
{ ...
}
else
{
...
}

et d'autre

Code :

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

1
2
3
4
5
if(...){ 
...
}else{
...
}

Je suis de l'école de la deuxième et je ne supporte pas le premier. Avant tout, il faut coder de manière à ce comprendre en premier mais tout en étant pas dans l'optique de compresser pensant que ça va augmenter la vitesse. Je ne pense pas qu'il y ait de gain réelle. Si gain il y a c'est l'ordre de microseconde mais le temps à retrouver ses petits lorsqu'il y a un problème est l'ordre de plusieurs minutes et de "Pfff mais qu'est ce que j'ai voulu faire là!... "

[Delprog]

Je reviens aussi sur les différentes couches de l'application, fonctionnelle et vue pour simplifier (il y en a d'autres).

Tout le monde parlent de templates et se met en tête de vouloir absolument séparer intégralement le php du html.
Je suis d'accord il ne faudrait jamais voir du HTML dans du PHP, mais l'inverse ? Je me pose la question quand même...

J'ai envie de dire que tout dépend du but final de l'application. S'il s'agit de créer (comme les forums phpbb par ex.), une usine à gaz qui pourra être personnalisée par n'importe qui dans la couche vue sans prendre le risque de modifier la partie fonctionnelle d'accord. Mais je le redis, il s'agit en général d'usines à gaz, et tout le monde sait que les hébergeurs (en mutualisé surtout) n'aiment pas beaucoup ce genre d'application.

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

Maintenant admettons qu'on ait un projet abordé avec une bonne conception Objet, des classes propres et bien construites, n'intégrant aucun html biensur.

Si ce projet était de proposer différents "templates" pour des sites clients permettant de lister par exemple des produits en fonction de critères de recherche (très répandu hein).

Par exemple mes produits seraient des "trucs" ok. Sur ma page d'accueil, j'ai une liste de "trucs" et le détail d'un seul "truc".

Qu'y-a-t'il de mauvais à avoir par exemple :

Code :

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

1
2
3
4
5
6
7
8
// Avant ça création de la connexion à la BDD avec une classe générique
// et on aurait au final un objet $db
 
$listeTrucs = new ListTrucs($db, $id_client);
$listeTrucs->getListBySearch($criteres, $_POST);
 
$monTruc = new Truc($db);
$monTruc->getTrucById($listeTrucs->items[0]['id_truc'] );

J'invente hein, evidemment ce serait plus réfléchis que ça.

Mais qu'est-ce qui empêche vraiment pour la vue de faire directement dans le HTML :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
$count = count($listeTrucs->items);
for ($i = 0; $i < $count; $i++) { ?>
 
<div id="items-list">
  <div class="item"><?=$listeTrucs->trucBidule?></div>
</div>
 
<?php
}
?>

Ok c'est moins lisible, mais n'est-ce pas bien plus performant ?

Je vous pose la question, la séparation totale des couches a-t-elle un autre intérêt que la lisibilité ? Perso, j'essaie de séparer au maximum aussi, mais je me pose quand même la question sur l'intérêt réel.


Benjamin.