[spip-dev] normalisation : variables de configuration vs. constantes

Dans ma série “je pinaille pour pas grand chose”, je me demandais s’il existait une convention pour le code de SPIP sur :

  • les constantes qui commencent pas ‘_’ (ex. _DIR_IMG_PACK)
  • les autres constantes (ex. SPIP_ERREUR_REPORT)
  • les variables PHP utilisée dans ecrire/inc_version (ex. $mysql_debug, $spip_version_branche, $table_prefix, $taille_des_logs)

Il me semble qu’il y a une certaine confusion.

Je propose qu’on réserve l’usage des variables pour des éléments qui sont susceptible d’évoluer, et de passer en constante les autres :
donc :
$taille_des_logs => _TAILLE_DES_LOGS
$table_prefix => _TABLE_PREFIX
etc…

A mon avis, ça limiterait les appels de type $GLOBALS[’…’] pour des constantes, et ça clarifierait le code.

Qu’en pensez-vous ?

je me réponds à moi-même, car je pense avoir compris quelque chose :

une constante PHP, même si elle est définie dans un fichier chargé plus tard (par exemple inc/utils.php) peut avoir été définie en amont dans config/mes_options.php :

Du coup c’est une méthode pour personnaliser certains éléments sans modifier le code de SPIP, même si ça génère un message de type NOTICE.

Seule limite : les constantes définie dans inc_version.php ne peuvent être modifiées dans mes_options.php (qui est chargé après).

J’ai tout juste ?

.Gilles

Question annexe :
Afin de ne déclencher aucune erreur, ne pourrait-on pas utiliser @define() au lieu de define() ?

2010/3/13 Gilles VINCENT <gilles.vincent@gmail.com>

@ a un cout important en terme de performance, il est donc à éviter au maximum et j’en avais viré pleins.
A defaut un
(if !defined(‹ xxx ›)) define(‹ xxx ›);
est plus approprié même si plus long à écrire.

Cédric