[Coding style] Vos solutions pour un code lisible ?

[Tagu]

Je suis comme naholyr, la méthode 2 est la mieux.
Pour ce qui est de la non verbeusité de Ruby, je ne suis pas fan. Après cela devient du code aussi chiant à lire que le perl si l'on ne connaît pas tous les raccourcies du langage.

[Sephi-Chan]

Ce que je recherche, ce sont vos exemples.

Je donnais les miens pour illustrer l'une des choses dont je parlais : la façon d'indenter (ou de ne pas le faire :p). Il y doit y avoir des dizaines de façon de faire, en découvrant la façon de faire de certains développeurs, on peut parfois avoir des révélations.

On ne peut pas commenter un langage sans l'avoir pratiqué quelques temps. Ça n'a pas de sens. Je parle de la lisibilité de Ruby, mais je le dis après avoir codé longtemps en PHP, un peu en C, en C++, en Objective-C (très à part, celui-ci…), en Java, en VB.net et quelques autres. Après mes plus ou moins courtes expériences, je n'ai jamais lu du code aussi agréable à lire.


Sephi-Chan, et Perl n'est pas un langage réputé pour sa lisiblité (comment peut-on l'être quand on utilise -> dans la notation objet ? :p)

[naholyr]

Un exemple très récent, le seul bout de code partageable du projet sur lequel je bosse :

Code PHP :

<?php 

class StringTools

{

  

  /**

   * Removes all accents from given string

   * @param string $string

   * @param string $encoding

   * @return string the clean string

   */

  public static function removeAccents($string, $encoding = null)

  {

    if (is_null($encoding)) {

      $encoding = sfConfig::get('sf_charset');

    }

    



    return iconv($encoding, 'us-ascii//TRANSLIT', $string);

  }

  

  /**

   * Cleans a URL parameter

   * @see ***.clever-age.***/***

   * @param string $string

   * @return string The clean string

   */

  public static function cleanURLParameter($string)

  {

    // * Toutes les lettres accentuées perdent leurs accents é->e, à-> a 

    $string = StringTools::removeAccents($string);

    

    // * Tous les caractères spéciaux et espace doivent être transformés en tiret, sauf si le caractère fait vraiment parti du nom du produit.

    // ex : le caractère + devient "plus"

    $string = str_replace(array('&', '/', '+'), array(' et ', ' slash ', ' plus '), $string); // replace standard characters

    $string = preg_replace('/[^\w_]+/', '-', $string); // remove special characters

    $string = preg_replace('/^-*(.*?)-*$/', '$1', $string); // trim

    

    return $string;

  }

  

} 

[OncleJames]

+Typer les noms de variables iNombre / sString / aArray / oObjet
+Différencier les commentaires :
/**
*
*
*/
Servant à présenter l'objectif d'une fonction/class/ ou autre
//
En fin de ligne expliquant un contenu
+ Nom de fichier des class class.nom.php
+ Nom de fichier des fonctions func.nom.php
+ Utiliser la syntaxe de PHPDOCgenerator
+ Début des fonctions private par _

[naholyr]

Moi j'ai en horreur cette notation polonaise (ou je sais plus quoi) qui consiste à préfixer les variables avec une lettre en fonction de leur type. Je trouve ça discriminant et je pense toujours que si on a besoin de préciser le type dans la variable, c'est qu'on l'a mal nommée.
Je suis bien content de n'avoir jamais vu cette règle imposée dans les différents projets auxquels j'ai participés.

C'est ce que j'avais en tête en disant ça :
- Nommer les fonctions en fonction de ce qu'elles font et non pas en fonction de leurs types d'entrée/retour.
- Nommer les variables en fonction de ce qu'elles sont et non pas en fonction de leur type.

C'est comme mettre son ASV dans son pseudo, je m'appelle naholyr, pas M_28_naholyr >< Mon identification n'a pas à porter mes propriétés

[SorenS]

+1 pour naholyr. Je trouve ça moche en plus. Perso, j'utilise les commentaires types phpdoc. Du coup ça donne :

Code PHP :

<?php 

/**

* classe servant à ....

*/

class xy{



     /**

     * nom de la personne

     * @type string

     * @access private

     */

     private $name;



     /**

     * retourne ce qui est demandé, false si la variable n'existe pas

     * @param $var string nom de la variable demandée

     * @acces public

     * @return mixed

     */

     public function get($var){

          if(if(!empty($this->$var))

               return $this->$var;

          else

               return false;

     }

} 

[Sephi-Chan]

Je ne suis pas fan non plus de la notation Hongroise. Je trouve qu'un bon nommage est bien plus pratique. Si on un à un tableau d'objet User, on peut le nommer users et ça reste hyper clair. De même pour une chaîne : on se doute que name sera une chaîne de caractères.


Sephi-Chan

[NicoMSEvent]

moi par contre, je préfixe mes variables en fonction de leur portée.
g_ pour les gobales
l_ pour les locales
s_ pour les statiques
p_ pour les paramètres passés (éventuellement pi_ po_ pio_ pour les paramètres en entrée/sortie si le langage le permet (comme PL/SQL), sinon en général ma valeur de retour pour une fonction sera tjs l_ret

[OncleJames]

Travaillant en équipe et à distance, cette notation nous a fait gagner bien du temps.
Elle ne demande pas de changer le nom, sa fonction, .. juste de préciser ce qu'elle contient.

Dans des listes de fonctions, savoir ce que l'on doit passer en argument juste en regardant son nom, c'est très agréable (et gain de temps par la même occasion, au lieu d'embêter ses voisins à comprendre ce qu'ils ont programmés :non.

[Anthor]

Travaillant en équipe et à distance, cette notation nous a fait gagner bien du temps.
Elle ne demande pas de changer le nom, sa fonction, .. juste de préciser ce qu'elle contient.

Dans des listes de fonctions, savoir ce que l'on doit passer en argument juste en regardant son nom, c'est très agréable (et gain de temps par la même occasion, au lieu d'embêter ses voisins à comprendre ce qu'ils ont programmés :non.

Les commentaires phpDoc sont fait pour ça Généralement tout bon IDE te les affichent au dessus de la fonction.

Pour ma part, avec ou sans Zend : http://framework.zend.com/manual/en/codi...ndard.html