# Matomo/CodingStandard

* Présentation
* Installation
* Configuration
* Fonctionnalités
* Fonctionnement
* Traductions
* Soutien
* À propos
* CodingStandard
* Réflexion Version 2
* SearchEnginesDetection
* Réflexions version2 test
* interfaces club
* Présentation
* Installation
* Configuration
* Fonctionnalités
* Fonctionnement
* Traductions
* Soutien
* À propos
* CodingStandard
* Réflexion Version 2
* SearchEnginesDetection
* Réflexions version2 test
* interfaces club
[ Modifier le sommaire ]

## Pourquoi adopter un style commun ?

Extrait de http://www-portal-stage.oracle.com/technology/tech/opensource/PHP_Coding_Standard.htm

## Pourquoi Piwik n'impose pas un coding style 'standard' ?

Nous pensons que les coding guidelines sont trop parfois trop restrictives, et parfois incomplètes. Nous préférons donc faire un résumé de ce qui nous semble indispensable et important. Nous avons pour cela utilisé plusieurs guides différents (5 au total) et fait un résumé bilan des meilleures idées et concepts, pour présenter l'ensemble des règles suivantes. Les points non soulignés sont donc laissées à la liberté d'expression du développeur !

## Introduction

Quelques notions introductives :
* noms de fonctions, noms de variables, noms de classes et de méthodes, en anglais
* fonctions documentées en anglais selon la norme javadoc, la documentation est générée par phpDocumentor
* les commentaires au sein des fonctions sont à écrire en priorité en anglais. Si vraiment vous ne pouvez ou ne voulez pas, le français est autorisé. L'anglais reste très largement conseillé
* les fichiers code source sont tous encodés en UTF-8. Cela permettra à tous les développeurs d'avoir exactement le même rendu final, quel que soit leur pays et leur langue. Ce sera notamment utile pour les noms des développeurs étrangers.
* la programmation objet n'est pas obligatoire mais fortement encouragée Marco

## Général

Commentaires généraux sur le style de codage à utiliser obligatoirement
* largeur maximum des lignes : 100 caractères (et non 80)
* utiliser des tabulations et non des espaces. Chacun règle la taille de ses tabulations (4 semble être un bon chiffre). Ne pas transformer automatiquement ses tabulations en espace comme le proposent certains logiciels !
* pour les if then else les 2 écritures classiques sont tolérées
et
La première semble plus claire et est conseillée ! Moi je conseille la deuxième, beaucoup plus simple à lire et plus concise :-P !
* faire une bonne utilisation des espaces pour les blocs d'égalité
* en cas de multiples tests bien mettre en avant sur des nouvelles lignes plus indentées les tests logiques
* ne pas mettre plus d'une action par ligne (statement).
* utiliser <?php et non <? en début de fichier (et veillez à ne pas laisser de ligne vide au début ou à la fin des fichiers
* mettre les mots clés SQL en majuscule
* mettre les index des tableaux entre guillemets simples

## Commentaires

* pour les commentaires en une ligne utilisez le style
* pour les commentaires sur plusieurs lignes utilisez le style
* commentaires de fonctions, classes, méthodes respectent la norme javadoc

## Conventions de nommage

Cette partie est très importante et doit être scupuleusement suivie !
* variables : utiliser le style "studly caps". Chaque premier caractère d'un nouveau "mot" doit être une majuscule, sauf le tout premier.
* fonctions : utiliser le même style que les variables. De préférence sous forme de verbes (les fonctions effectuent, il existe forcément un verbe pour cet effet... !).
    Note : ne pas utiliser la notation pdf2html mais plutôt pdfToHtml pour plus de clarté (confusion possible entre pdf2Html sinon...)
* classes : elles suivent également le style StudlyCaps, mais avec une majuscule au début
* utilisez à bon escient les préfixes ou suffixes 'naturels' comme *Count, temp*, etc.
* ne pas utiliser des noms de variables à 1 caractère seulement, excepté des index dans les boucles ($i, $j, $k, etc.)
* pour combler le manque de précision de php sur le type des variables, il faut typer les array, string, integer, bool avec un préfixe
* également pour les variables globales
* écrire true, false, et null en minuscule

## Programmation

* ne pas utiliser les variables globales sauf s'il n'y a pas d'autre solution, et dans ce cas se concerter entre développeurs auparavant.
* il faut initialiser les variables
* connaître et savoir utiliser === et !==
* dans le switch, quand on fait un 'return' ne pas oublier le 'break'
* utiliser des 'foreach' plutôt que des 'while(list($t, ) = each($t2))'
* pas de magic numbers, ces nombres qui apparaissent dans le code sans justification particulière, comme par magie. Définir des constantes ou variables ayant comme valeurs ces magic number, mais ne pas faire les tests directement !
* optimiser les boucles for et autres, notamment lors de l'utilisation des sizeof
* de même que pour le if on peut écrire
* utilisez plutôt sizeof que count
* utilisez plutôt strpos que strstr
* ne pas utiliser la possibilité de Smarty de mettre du code PHP dans les templates via les tags . C'est dangereux et l'on peut faire sans !
* quand une fonction doit retourner un bool, retournez un bool soit true soit false et non pas 1 ou 0

### IMPORTANT fonctions propres à Piwik

* pour récupérer une variables utiliser la fonctions getRequestVar qui sécurise les données
* pour stripslasher utiliser la fonction stripslashesPmv qui prend en compte les magic_quote
* pour faire des requêtes utiliser query au lieu de mysql_query