Fork me on GitHub

Ebauche des normes de codage de XOOPS 3.0

200912
FĂ©vrier
  DuGris Core team 13061

Merci à la communauté francophone pour cette traduction

Auteur :

Portée

Ce document fournit les normes et les directives de codage pour les développeurs et les équipes travaillant sur ou avec le projet XOOPS. Les sujets traités sont :


RĂŽles des DĂ©veloppeurs :
  • DĂ©veloppeurs XOOPS : DĂ©veloppeurs qui contribuent aux 'frameworks' XOOPS, incluant
    • DĂ©veloppeurs du noyau : DĂ©veloppeurs qui contribuent au SVN du noyau de XOOPS et dont le code sera employĂ© par des dĂ©veloppeurs d'application XOOPS.
    • DĂ©veloppeurs du 'framework' : DĂ©veloppeurs qui contribuent aux 'frameworks' de XOOPS qui pourraient ĂȘtre adoptĂ©s dans le noyau de XOOPS Ă  l'avenir.
    • DĂ©veloppeurs d'interface utilisateur : DĂ©veloppeurs qui travaillent sur les thĂšmes de XOOPS et les 'templates' de modules.
  • CrĂ©ateurs d'applications XOOPS : DĂ©veloppeurs qui crĂ©ent leurs propres applications sur la plate-forme XOOPS
    • DĂ©veloppeurs de modules : DĂ©veloppeurs qui construisent des modules tiers utilisant la plate-forme et les bibliothĂšques XOOPS.

Objectifs

De bonnes normes de codage sont importantes dans n'importe quel projet de dĂ©veloppement, en particulier lorsque plusieurs dĂ©veloppeurs travaillent sur un mĂȘme projet. Avoir des normes de codage aide Ă  s'assurer que le code est de qualitĂ©, a peu de bogues et est facile Ă  maintenir.

Les buts abstraits que nous poursuivons :

  • simplicitĂ© extrĂȘme
  • outil convivial, Ă  travers l'utilisation des signatures de mĂ©thode, constantes et modĂšles qui soutiennent des outils d'IDE et les propositions automatisĂ©es lors de la saisie de nom de mĂ©thode, de classe et noms de constantes.

Au vu des buts ci-dessus, chaque situation exige un examen des circonstances et de l'Ă©quilibrage des compromis.



Formatage des fichiers PHP

Généralités

Pour les fichiers qui contiennent du code PHP, le tag fermant ("? >") doit ĂȘtre inclus lorsque c'est nĂ©cessaire.

Indentation

Employez une indentation de 4 espaces, sans tabulation. Les Ă©diteurs de texte doivent ĂȘtre configurĂ©s pour convertir les tabulations en quatre espaces afin d'empĂȘcher l'injection de tabulations dans le code source.

Longueur maximale des lignes

L'ojectif de longueur de ligne à respecter est de 80 caractÚres ; c'est-à-dire que les développeurs doivent s'appliquer à conserver le code aussi prÚs que possible de la barriÚre de 80 colonnes. Cependant, de plus longues lignes sont acceptables. La longueur maximale de n'importe quelle ligne de code de PHP est de 120 caractÚres.

Fin de Ligne

La fin de ligne est la méthode standard pour les fichiers textes sous Unix. Les lignes doivent se finir avec un retour à la ligne (LF). Les retours à la ligne sont représentés comme le nombre ordinal 10, ou 0x0A en hexadécimal.

N'employez pas les retours chariot (CR) comme les ordinateurs Macintosh (0x0D).

N'employez pas le retour de chariot/retour Ă  la ligne (CRLF) comme les ordinateurs Windows (0x0D, 0x0A).

Les lignes ne doivent pas contenir d'espaces en fin de ligne. Afin de faciliter cette convention, la plupart des Ă©diteurs peuvent ĂȘtre configurĂ©s pour supprimer les espaces en fin de ligne lors de la sauvegarde du fichier.

Conventions de nommage

Proposition globale

  1. Les noms pour toutes les classes et fonctions à l'intérieur de XOOPS doivent commencer par Xoops
    1. La premiĂšre lettre des noms de fonction doit toujours ĂȘtre en minuscule; si nĂ©cessaire les noms doivent ĂȘtre sĂ©parĂ©s en utilisant des tirets bas « _ », pas de CamelCaps (explication sur CamelCaps en bas de cette page):
      • les fonctions du noyau doivent commencer par xoops_
      • le 'framework' et les fonctions de bibliothĂšque doivent commencer par xoops_ ['framework' ou identifiant de bibliothĂšque]_
    2. Les noms de classe doivent toujours ĂȘtre sĂ©parĂ©s en utilisant des CamelCaps (explications sur CamelCaps en bas de cette page);
  2. Les noms des variables partagées, produites par XOOPS doivent commencer par $xoops suivi de CamelCaps.
    • Pour les variables privĂ©es (ou non partagĂ©es) nous vous encourageons Ă  suivre le mĂȘme modĂšle
  3. Les applications tierces, y compris les modules, ne doivent pas commencer par Xoops_ mais par le préfixe de l'application
    • Les noms de classe de modules doivent commencer par [identifiant du module, habituellement nom de rĂ©pertoire] en respectant le style CamelCaps, par exemple : NewbbPost
    • Les noms de fonctions de modules doivent commencer par [identifiant du module, habituellement nom de rĂ©pertoire]_,par exemple : newbb_getPostCount ()
    • Les variables de modules doivent commencer par $[identifiant du module], par exemple $newbbPostCount

Abstractions utilisées dans les api (interfaces de classes)

En créant une API à l'usage des développeurs d'application, si les développeurs d'application doivent identifier des abstractions en utilisant un nom composé, séparez les noms en utilisant des tirets bas (underscore), pas les CamelCaps.Quand le développeur emploie une chaine de caractÚres, il faut la normaliser en lettres minuscules. Lorsque cela est possible, utilisez des constantes.

Classes

Les noms de classe du systĂšme, du noyau ou du 'framework'' doivent commencer par Xoops, comme XoopsCaptcha.

Les noms de classe de module doivent commencer par [identifiant du module], comme NewbbPost

Interfaces

Les classes d'interface doivent suivre les mĂȘmes conventions que les autres classes (voir ci-dessus), mais doivent finir avec «_Interface», comme : XoopsLogger_Interface

Noms des fichiers

Pour tous les fichiers, seuls les caractÚres alphanumériques, les tirets bas et le tiret haut(« - ») sont autorisés. Les espaces sont interdits.

N'importe quel fichier contenant du code PHP doit finir avec l'extension « .php ».

Les noms de fichiers doivent ĂȘtre en minuscules.

Noms des dossiers

Pour tous les dossiers, seuls les caractÚres alphanumériques, les tirets bas et le tiret haut(« - ») sont autorisés. Les espaces sont interdits.

Les noms de rĂ©pertoire doivent ĂȘtre en minuscules.

Fonctions et méthodes

Le nom des fonctions du noyau et du module systĂšme doivent commencer par xoops_doSomething ([...])

Les noms des fonctions du 'framework' doivent commencer par xoops_ [identifiant en minuscule], comme xoops_pear_doSomething ([...])

Les noms des fonctions de modules doivent commencer par [identifiant du module en minuscule]_ , comme newbb_getTopic ([...])

  • Les noms de fonction doivent seulement contenir les caractĂšres alphanumĂ©riques et les tirets bas. Les nombres sont autorisĂ©s dans des noms de fonctions, mais ne sont pas recommandĂ©s.
  • Les noms de fonction doivent toujours commencer par une lettre minuscule.
  • La clartĂ© est encouragĂ©e. Les noms de fonction doivent ĂȘtre aussi parlant que nĂ©cessaire pour augmenter la comprĂ©hension.
  • Pour la programmation orientĂ©e objet, les mĂ©thodes d'accĂšs doivent toujours ĂȘtre prĂ©fixĂ©es avec ou « get » ou « set ».
  • Les mĂ©thodes de classes qui sont dĂ©clarĂ©es comme protĂ©gĂ©es ou privĂ©es sont encouragĂ©es Ă  suivre le mĂȘme modĂšle que les mĂ©thodes publiques bien que certains 'frameworks' externes nĂ©cessitent de commencer par un tiret bas (underscore).
  • Des fonctions de portĂ©e globale, ou « fonctions flottantes» sont autorisĂ©es mais non recommandĂ©es. Nous recommandons que ces fonctions soient embarquĂ©es dans une classe et dĂ©clarĂ©es comme Ă©tant statiques.
  • Les mĂ©thodes ou les variables dĂ©clarĂ©s avec une portĂ©e « statique » dans une classe en gĂ©nĂ©ral, ne doivent pas ĂȘtre « privĂ©es », mais plutĂŽt "protĂ©gĂ©es". Employez « final » si la mĂ©thode ne peut pas ĂȘtre Ă©tendue.

ParamĂštres optionnels

Employez « NULL » comme valeur par défaut au lieu de « FALSE », pour des situations comme ceci :

public function foo($required, $optional = NULL)

quand $optional n'a pas ou n'a pas besoin d'une valeur par défaut particuliÚre.

Cependant, si un paramĂštre facultatif est boolĂ©en, et que sa valeur par dĂ©faut logique devrait ĂȘtre vrai, ou faux, l'utilisation de vrai ou faux est acceptable.

Variables

  • Les variables globales systĂšmes doivent commencer par $xoops, comme $xoopsConfig
  • Les variables globales de modules doivent commencer par $[identifiant du module en lettre minuscule] suivi du style camelCaps, comme $newbbPostCounter
  • Noms de variables pour les 'frameworks/bibliothĂšques' tiers
    • Les noms variables contiennent habituellement seulement des caractĂšres alphanumĂ©riques. Les tirets bas et les nombres sont autorisĂ©s dans des noms variables mais ne sont pas recommandĂ©s.
    • Les variables de classe dĂ©clarĂ©es « public » ne doivent jamais commencer par un tiret bas.
    • Pour les variables de classe dĂ©clarĂ©es comme 'protected' ou 'private' nous vous encourageons Ă  suivre le mĂȘme modĂšle que les variables publiques, cest-Ă -dire sans tiret bas au dĂ©but.
    • Comme les noms de fonction, les noms de variables doivent toujours commencer par une lettre minuscule et suivre la convention de nommage «CamelCaps».
    • La clartĂ© est encouragĂ©e. Les noms variables doivent ĂȘtre aussi parlant que nĂ©cessaire pour augmenter la comprĂ©hension. Des noms de variables laconiques tels que « $i » et « $n » sont uniquement conseillĂ© pour un compteur dans une boucle. Si une boucle contient plus de 20 lignes de code, les variables pour de tels index ou compteurs doivent avoir des noms plus descriptifs.

Constantes

Variables

Les constantes systĂšme commencent par XOOPS_ : XOOPS_URL

Les constantes de 'framework' doivent commencer par XOOPS_[identifiant]_ : XOOPS_PEAR_CONSTANT

Les constantes de module doivent commencer par [identifiant du module]_ : NEWBB_CONSTANT

DĂ©finitions de langue

Commencez toujours par le tiret bas : _XOOPS_LANGUAGE_CONSTANT, _NEWBB_LANGUAGE_CONSTANT

  • Les constantes peuvent contenir des caractĂšres alphanumĂ©riques et le tiret bas. Les nombres sont autorisĂ©s dans les noms de constantes.
  • Les noms de constantes doivent toujours ĂȘtre en majuscules.
  • Pour amĂ©liorer la lisibilitĂ©, les mots dans les noms de constantes doivent ĂȘtre sĂ©parĂ©s par des tiret bas. Par exemple, « XOOPS_EMBED_SUPPRESS_EMBED_EXCEPTION » est autorisĂ© mais « XOOPS_EMBED_SUPPRESSEMBEDEXCEPTION » n'est pas autorisĂ©.
  • Des constantes doivent ĂȘtre dĂ©finies comme membres de classe en employant le constructeur « const ». Les constantes de portĂ©e globale dĂ©finies en utilisant « define » sont autorisĂ©es mais non recommandĂ©es.

Booléens et la valeur NULL

Comme dans la documentation PHP, XOOPS utilise les lettres capitales pour les valeurs booléennes et la valeur « NULL ».

Noms des 'templates' de modules

A compléter

ModĂšle de codage

DĂ©limiteur de code PHP

Le code PHP Ă  l'intĂ©rieur de XOOPS doit toujours ĂȘtre dĂ©limitĂ© par les Ă©tiquettes complĂ©tes standard de PHP :


? >

Les tags courts ne sont jamais autorisées.

ChaĂźnes

Constantes de chaĂźne

Les doubles « guillemets » ou le simple guillemet « apostrophe » sont autorisés pour une chaine qui est littérale (ne contient aucune substitution de variable), l'« apostrophe » est encouragé :

$a = 'chaine exemple' ;

Constantes de chaĂźne contenant des apostrophes

Quand une chaine littérale contient des apostrophes, elle est autorisée à délimiter la chaine avec des « guillemets ». Ceci est particuliÚrement encouragé pour des commandes SQL :

$sql= "`SELECT 'id', `name` from `people` WHERE `name'= 'Fred' OR`name' = 'Susan'" ;

La syntaxe ci-dessus est préférable à l'échappement des apostrophes.

Substitution de variable

La substitution de variable est encouragée en utilisant le crochet.

Encouragé :

$greeting = "bonjour {$name}, bienvenue !" ;

OK mais non recommandé :

$greeting = "bonjour $name, bienvenue !" ;

Pour l'uniformité, cette notation n'est pas autorisée :

$greeting = "bonjour ${nom}, bienvenue !";

Concaténation de chaine

Des chaines peuvent ĂȘtre concatĂ©nĂ©es en utilisant l'opĂ©rateur " . ". Un espace doit toujours ĂȘtre ajoutĂ© avant et aprĂšs " . " pour amĂ©liorer la lisibilitĂ© :

$project = 'Xoops' . ' ' . 'Project';

Lors de la concatĂ©nation de chaĂźnes avec l'opĂ©rateur " . ", il est permis d'Ă©crire l'instruction sur plusieurs lignes pour amĂ©liorer la lisibilitĂ©. Dans ces cas, chaque ligne doit ĂȘtre complĂ©tĂ©e avec des espaces de telle sorte que l'opĂ©rateur " . " soit alignĂ© sous l'opĂ©rateur " = " :

$sql = "SELECT `id`, `name` FROM `people` " "
       . "WHERE `name` = 'Susan' " "
       . "ORDER BY `name` ASC ";

Tableaux

Tableau à index numérique

Les nombres négatifs ne sont pas autorisés comme index de tableau.

Un tableau indexé peut commencer par tout nombre non négatif, toutefois ceci n'est pas recommandé. Nous recommandons que tous les tableaux aient un index commençant à 0.

Lors de la dĂ©claration de tableau indexĂ© via le constructeur de tableau, un caractĂšre d'espacement doit ĂȘtre ajoutĂ© aprĂšs chaque virgule pour amĂ©liorer la lisibilitĂ© :

$sampleArray = array(1, 2, 3, 'XOOPS', 'Project');

Il est Ă©galement autorisĂ© de dĂ©clarer des tableaux indexĂ©s sur plusieurs lignes via le constructeur de tableau. Dans ce cas, chaque ligne doit ĂȘtre complĂ©tĂ©e avec des espaces de telle sorte que les lignes respectent l'alignement ci-dessous :

$sampleArray = array(1, 2, 3, 'XOOPS', 'Project',
                              $a, $b, $c,
                              56.44, $d, 500);

Tableaux associatifs

En dĂ©clarant des tableaux associatifs via le constructeur de tableau, il est prĂ©fĂ©rable de dĂ©clarer le tableau sur plusieurs lignes. Dans ce cas, chaque ligne successive doit ĂȘtre complĂ©tĂ©e avec des espaces de telle sorte que les clefs et les valeurs soient alignĂ©es :

$sampleArray = array('firstKey'        => 'firstValue',
                             'secondKey'    => 'secondValue');

Classes

DĂ©clarations de classes

Des classes doivent ĂȘtre appelĂ©es en suivant les conventions de nommage.

L'accolade est toujours Ă©crite sur la ligne, juste sous le nom de la classe.

Chaque classe doit avoir un bloc de documentation qui se conforme Ă  la norme de phpDocumentor.

Le code dans une classe doit ĂȘtre indentĂ© avec le standard des quatre espaces.

Il est recommmandé d'écrire une seule classe par fichier PHP.

L'écriture de code additionnel dans un fichier de classe est autorisé mais non recommandé. Deux interlignes doivent séparer la classe du code additionnel dans le fichier PHP.

/**
 * Class Docblock Here
 */
class XoopsClass
{
    // entire content of class
    // must be indented four spaces
}

Variables de classe

Des variables de classe doivent suivre les conventions de nommage.

Toutes les variables de classe doivent ĂȘtre dĂ©clarĂ©es au dĂ©but de la classe, avant avant la dĂ©claration de toute fonction.

Le constructeur 'var' n'est pas autorisée. Les variables de classe définissent toujours leur visibilité en employant une des constructeurs 'private', 'protected', ou 'public'. L'accÚs aux variables directement en les rendant publique est autorisé, dans certains cas, c'est en faveur de méthodes d'accÚs ayant les préfixes set / get.

Fonctions et méthodes

Déclaration de fonctions et de méthodes

Les fonctions et les mĂ©thodes de classes doivent ĂȘtre crĂ©Ă©es en suivant les conventions de nommage.

Les méthodes doivent toujours déclarer leur visibilité en employant une des constructeurs 'private', 'protected', 'public'.

L'usage dans la communauté PHP, consiste à déclarer les méthodes statiques en premier :

public      static foo()    { ... }
private     static bar()    { ... }
protected   static goo()    { ... }

Comme pour les classes, l'accolade d'ouverture pour une fonction ou une méthode est toujours écrite sur une ligne juste sous le nom de fonction ou de méthode. Il n'y a aucun espace entre le nom de fonction ou de méthode et la parenthÚse d'ouverture pour les arguments.

Voici un exemple acceptable de déclaration de méthode :

/**
 * Class Docblock Here
 */
class XoopsFoo
{
    /**
     * Method Docblock Here
     */
    public function sampleMethod($a)
    {
        // entire content of function
        // must be indented four spaces
    }
    
    /**
     * Method Docblock Here
     */
    protected function _anotherMethod()
    {
        // ...
    }
}

La valeur de retour ne doit pas ĂȘtre incluse entre parenthĂšses. Ceci peut gĂȘner la lisibilitĂ© et peut Ă©galement modifier le code si une fonction ou une mĂ©thode est ultĂ©rieurement modifiĂ©e pour obtenir une valeur de retour par rĂ©fĂ©rence.

function foo()
{
    // WRONG
    return($this->bar);
 
    // RIGHT
    return $this->bar;
}

L'utilisation du "type hinting" est encouragé lorsque c'est possible. Par exemple,

class XoopsComponent
{
    public function foo(SomeInterface $object)
    {}
 
    public function bar(array $options)
    {}
}

Utilisation des fonctions et méthodes

Les fonctions de portée globale sont fortement déconseillées.

Les arguments de fonction sont séparés par un espace simple aprÚs la virgule. Voici un exemple acceptable d'un appel de fonction pour une fonction qui prend trois arguments :

threeArguments (1, 2, 3) ;

Call-time pass by-reference est interdit. Pass-by-reference est autorisĂ© dans la dĂ©claration de fonctions seulement. Des arguments Ă  passer par rĂ©fĂ©rence doivent ĂȘtre dĂ©finis dans la dĂ©claration de fonction.

Pour les fonctions dont les arguments permettent des tableaux, l'appel de fonction peut inclure le constructeur de " array " et peut ĂȘtre coupĂ© en plusieurs lignes pour amĂ©liorer la lisibilitĂ©. Dans ce cas, les normes pour l'Ă©criture des tableaux s'appliquent :

threeArguments(array(1, 2, 3), 2, 3);

threeArguments(array(1, 2, 3, 'XOOPS', 'Project',
                              $a, $b, $c,
                              56.44, $d, 500), 2, 3) ;

Instructions de contrĂŽle

If / Else / Elseif

Les instructions de contrÎle basées sur les constructeurs "if", "else ", et le " elseif" doivent avoir un espace simple avant la parenthÚse ouvrante de la condition, et espace simple entre la parenthÚse fermante et l'accolade.

Dans les instructions conditionnelles, Ă  l'intĂ©rieur des parenthĂšses, les opĂ©rateurs doivent ĂȘtre sĂ©parĂ©s par des espaces pour plus de lisibilitĂ©. Les parenthĂšses sont conseillĂ©es pour amĂ©liorer la logique de groupement des longues conditions.

L'accolade d'ouverture est Ă©crite sur la mĂȘme ligne que l'instruction de condition. L'accolade de fermeture est toujours Ă©crite sur sa propre ligne. Le contenu Ă  l'intĂ©rieur des accolades doit ĂȘtre indentĂ© Ă  l'aide de 4 espaces.

if ($a ! = 2) {
    $a = 2 ;
}

Pour les instructions "if" qui incluent "elseif" ou "else", le formattage doit ĂȘtre comme dans ces exemples :

if ($a != 2) {
    $a = 2;
} else {
    $a = 7;
}
 
if ($a != 2) {
    $a = 2;
} elseif ($a == 3) {
    $a = 4;
} else {
    $a = 7;
}

PHP autorise quelquefois ces instructions Ă  ĂȘtre Ă©crites sans accolades. Les normes de codage ne font pas de diffĂ©rence et toutes les instructions "if", "elseif", ou "else" doivent utiliser les accolades.

Switch

Les instructions de contrĂŽle, Ă©crites avec le constructeur "switch" doivent avoir un espace simple avant la parenthĂšse ouvrante de l'instruction de condition, ainsi qu'un espace simple entre la parenthĂšse fermante et l'accolade ouvrante.

Les instructions "case" Ă  l'intĂ©rieur du "switch" ne doivent pas ĂȘtre indentĂ©es. Le contenu Ă  l'intĂ©rieur de chaque instruction "case" doit ĂȘtre indentĂ© avec 4 espaces.

switch ($numPeople) {
case 1:
    break;

case 2:
    break;

default:
    break;
}

Le constructeur "default" ne doit jamais ĂȘtre oubliĂ© dans une instruction "switch".

Documentation intégrée

Format de documentation

Tous les blocs de documentation ("docblocks") doivent ĂȘtre compatibles avec le format de phpDocumentor. Pour plus d'information, visitez http://phpdoc.org

Tout le code source écrit pour la plate-forme XOOPS ou opérant avec cette plateforme doivent contenir un "file-level docblock" tout en haut de chaque fichier et un"class-level docblock" juste au-dessus de chaque classe.

Le diĂšse, ' # ', ne doit pas ĂȘtre employĂ© pour commencer un commentaire.

Fichiers

Chaque fichier contenant du code PHP doit avoir au dĂ©but du fichier, un bloc d'en-tĂȘte contenant au moins ces tags de phpDocumentor :

/**
 * Short description for file
 *
 * Long description for file (if any)...
 *
 * LICENSE
 *
 * You may not change or alter any portion of this comment or credits
 * of supporting developers from this source code or any supporting source code
 * which is considered copyrighted (c) material of the original comment or credit authors.
 *
 * @copyright   The XOOPS Project http://sourceforge.net/projects/xoops/
 * @license       http://www.fsf.org/copyleft/gpl.html GNU public license
 * @author       Author   Name
 * @version      $Id$
 * @since         File available since Release 3.0.0
 */

Classes

Chaque classe doit avoir un docblock qui contient au moins ces tags de phpDocumentor :

/**
 * Short description for class
 *
 * Long description for class (if any)...
 *
 * @copyright   The XOOPS Project http://sourceforge.net/projects/xoops/
 * @license       http://www.fsf.org/copyleft/gpl.html GNU public license
 * @author       Author  Name
 * @version      $Id$
 * @since         File available since Release 3.0.0
 */

Fonctions

Chaque fonction, y compris des méthodes d'objet, doit avoir un docblock qui contient au moins :

  • Une description de la fonction
  • Tous les arguments
  • Toutes les valeurs de retour possibles
/**
 * Does something interesting
 *
 * @param   Place       $where Where something interesting takes place
 * @param   integer     $repeat How many times something interesting should happen
 * @return  Status
 */

public function xoops_doSomethingInteresting(Place $where, $repeat = 1)
{
   // implementation...
}

Require / Include

Si un composant emploie un autre composant, alors le composant utilisĂ© est responsable du chargement de l'autre composant. Si l'utilisation est conditionnelle, alors le chargement devrait Ă©galement ĂȘtre conditionnel.

Si le(s) fichier(s) pour l'autre composant doivent toujours ĂȘtre chargĂ©s avec succĂšs, indĂ©pendamment de l'entrĂ©e, alors utiliser l'instruction PHP require_once.

Utiliser XoopsLoad::load() pour charger les classes configurées.

Les instructions include, include_once, require, et require_once ne doivent pas utiliser de parenthĂšses.

Erreurs et exceptions

Le code du projet de XOOPS doit ĂȘtre conforme E_STRICT. Le code de XOOPS ne doit pas Ă©mettre d'avertissement de PHP ( E_WARNING, E_USER_WARNING ), notice ( E_NOTICE, E_USER_NOTICE ), ou strict ( E_STRICT ) quand la variable "error_reporting" est initialisĂ©e Ă  E_ALL | E_STRICT.

Voir sur http://www.php.net/errorfunc/ pour plus d'information sur E_STRICT.

Le code de XOOPS ne doit pas afficher des erreurs de PHP, si c'est raisonnablement possible. Au lieu de cela, indiquez chaque erreur avec les messages signicatifs en utilisant la fonction XOOPS "trigger_error" puis XOOPS utilisera le gestionnaire d'erreur personnalisé pour effectuer le traitement ultérieur.

Explications :
  1. camelCaps - Lorsqu'une chaĂźne est composĂ©e de plus d'un mot, la premiĂšre lettre de chaque nouveau mot doit ĂȘtre mise en majuscule. Ceci est couramment appelĂ© la mĂ©thode "camelCaps".

À partir de Zend framework PHP Coding Standard (draft)

Note: 10.00 (1 vote) - Noter cet article -

Partager Twitter Partagez cette article sur GG+
Format imprimable Envoyer cet article à un ami Créer un fichier PDF à partir de cet article
Les commentaires appartiennent Ă  leurs auteurs. Nous ne sommes pas responsables de leur contenu.
Xoops accro
Inscrit le: 15/07/2004
De:
Contributions: 4771
blueteen PostĂ© le: 13/02/2009 08:07  Mis Ă  jour: 13/02/2009 08:07
 Re: Ebauche des normes de codage de XOOPS 3.0
Semi pro
Inscrit le: 13/04/2007
De:
Contributions: 665
nendo PostĂ© le: 13/02/2009 09:55  Mis Ă  jour: 13/02/2009 09:55
 Re: Ebauche des normes de codage de XOOPS 3.0
Bonjour

Merci pour ce document trés complet.

Et merci aussi a blueteen pour la traduction.

A+
Semi pro
Inscrit le: 14/05/2004
De:
Contributions: 1827
JJDai PostĂ© le: 13/02/2009 10:25  Mis Ă  jour: 13/02/2009 10:35
 Re: Ebauche des normes de codage de XOOPS 3.0
Merci pour ce document.
JJDAI
Xoops accro
Inscrit le: 20/02/2008
De: Belgium
Contributions: 2700
Ghia PostĂ© le: 13/02/2009 15:44  Mis Ă  jour: 13/02/2009 15:46
 Re: Ebauche des normes de codage de XOOPS 3.0
Dommage que les extraits de code sont placee dans une quote et pas dans une bloc code avec une font invariable comme monospace ou courier new. Comme ca certaines subtilitees sont perdue, comme chez l'example SQL en Concaténation de chaine, qu'il faut se montree comme ceci:
$sql "SELECT `id`, `name` FROM `people` " "
     . "
WHERE `name` = 'Susan' " "
     
"ORDER BY `name` ASC ";
Xoops accro
Inscrit le: 25/02/2004
De: RĂ©gion parisienne
Contributions: 2527
DuGris PostĂ© le: 13/02/2009 16:06  Mis Ă  jour: 13/02/2009 16:06
 Re: Ebauche des normes de codage de XOOPS 3.0
plus de deux heures de travail (sans compter la traduction de blueteen), et encore et toujours un mécontent. ça me gonfle !!!

@blueteen, dĂ©solĂ© mais comme le fichier se trouvait sur le svn, j'ai pensĂ© que c'Ă©tait kris. Merci tout de mĂȘme.
Admin Frxoops
Inscrit le: 04/02/2003
De: Blois
Contributions: 3073
philou PostĂ© le: 13/02/2009 16:32  Mis Ă  jour: 13/02/2009 16:32
 Re: Ebauche des normes de codage de XOOPS 3.0
Merci beaucoup pour ce travail !

C'est indispensable comme doc, dommage que cela n'ai pas existé plus tÎt !!! :-o
Xoops accro
Inscrit le: 15/07/2004
De:
Contributions: 4771
blueteen PostĂ© le: 13/02/2009 18:13  Mis Ă  jour: 13/02/2009 18:13
 Re: Ebauche des normes de codage de XOOPS 3.0
Y a pas de mal, c'était une pensée pour jlz78

Sinon, d'accord avec toi pour la remarque :
Ghia, je ne vois aucune différence entre ton code et celui de l'article, on distingue parfaitement les apostrophes, les guillemets, etc.
Xoops accro
Inscrit le: 15/07/2004
De:
Contributions: 4771
blueteen PostĂ© le: 13/02/2009 19:14  Mis Ă  jour: 13/02/2009 19:14
 Re: Ebauche des normes de codage de XOOPS 3.0
oui je sais pour les simple quotes, mais si je copie/colle le code de la doc et celui de ghia, je n'ai aucune différence visible (ou alors ça me crÚve les yeux).

Open in new window
Semi pro
Inscrit le: 13/12/2004
De: Lyon
Contributions: 1364
MusS PostĂ© le: 13/02/2009 23:23  Mis Ă  jour: 13/02/2009 23:23
 Re: Ebauche des normes de codage de XOOPS 3.0
Juste un mot...
Super ;)
Merci pour ce boulot
Xoops accro
Inscrit le: 20/02/2008
De: Belgium
Contributions: 2700
Ghia PostĂ© le: 15/02/2009 02:37  Mis Ă  jour: 15/02/2009 02:39
 Re: Ebauche des normes de codage de XOOPS 3.0
Citation :
plus de deux heures de travail (sans compter la traduction de blueteen), et encore et toujours un mécontent. ça me gonfle !!!

Quand on reste mecontente avec du critique positive, on va rater des chances pour s'ameliorer.
Citation :
oui je sais pour les simple quotes, mais si je copie/colle le code de la doc et celui de ghia, je n'ai aucune différence visible (ou alors ça me crÚve les yeux).
C'est ne pas une question du code mais du style et formatage et de le montrer par l'example.
Open in new window
Quand on lit dans le texte:
Citation :
Dans ces cas, chaque ligne doit ĂȘtre complĂ©tĂ©e avec des espaces de telle sorte que l'opĂ©rateur " . " soit alignĂ© sous l'opĂ©rateur " = " :
Maitenant regardez encore une fois a l'image.
Alors, quelle bloc de code est en concordance avec l'explication pour l'alignement dans le texte?

Mais peutetre on n'a pas bien compris le sentence originale Anglaise?
Citation :
In these cases, each successive line should be padded with whitespace such that the "." operator is aligned under the "=" operator:

Je le traduis d'abord comme:
Dans ces cas, chaque ligne doit ĂȘtre complĂ©tĂ©e avec des espaces de telle nombre que l'opĂ©rateur " . " soit alignĂ© sous l'opĂ©rateur " = " :
ou
Dans ces cas, a la debut de chaque ligne on doit inserée une nombre des espaces, que l'opérateur " . " est aligné en dessous l'opérateur " = " :
Xoops accro
Inscrit le: 15/07/2004
De:
Contributions: 4771
blueteen PostĂ© le: 15/02/2009 10:07  Mis Ă  jour: 15/02/2009 10:07
 Re: Ebauche des normes de codage de XOOPS 3.0
pour améliorer un projet la critique n'est pas le seul moyen, il faut agir aussi.

ah ben voilĂ , lĂ  au moins ton explication Ă©tait trĂšs claire.
c'Ă©tait peut-ĂȘtre plus simple de dire ça dĂšs la premiĂšre fois ?
en effet, le code est mieux respecté à l'intérieur des balises code que quote.

Maintenant, désolé que sur la totalité de la traduction de la page, il y ait une coquille comme ça qui soit passée (et tu vois bien que la phrase en anglais a bien été comprise, puisqu'elle est correctement traduite).
C'est juste le rendu du code qui a été altéré.
Ce sera bien entendu corrigé.
Xoops accro
Inscrit le: 18/01/2004
De: Ma Caverne
Contributions: 2841
Marco PostĂ© le: 15/02/2009 13:29  Mis Ă  jour: 15/02/2009 13:29
 Re: Ebauche des normes de codage de XOOPS 3.0
Citation :

C'est indispensable comme doc, dommage que cela n'ai pas existé plus tÎt !!!

oui, mais c'est juste la reprise de ce que DJ a mis il y a 18 mois dans le wiki fourre tout de xoops.org, tout de suite aprĂšs avoir repris les rennes du dev xoops.
Newbie
Inscrit le: 15/09/2010
De:
Contributions: 1
svetorim PostĂ© le: 15/09/2010 18:03  Mis Ă  jour: 15/09/2010 18:03
 Re: Ebauche des normes de codage de XOOPS 3.0
Interesting!
Propulsé avec XOOPS | Graphisme adapté par Tatane, Grosdunord, Montuy337513

28 Personne(s) en ligne (1 Personne(s) connectée(s) sur Articles) | Utilisateur(s): 0 | Invité(s): 28 | Plus ...