SpipLab:StyleDeProgrammation

Le texte ci-dessous poursuit, et modifie (remplace) pour certains points, le document [->http://www.spip.net/fr_article825.html].

Reprendra au maximum le style défini par spip:

Présentation:

- Indentation: un caractere de tabulation (Yannick n'aime pas et préfererait "deux espaces". Babass : 1 tab est plus rapide que 2 espaces ;). Marcopol :  d'accord pour 2 espaces)
_ (PiiF)un éditeur bien foutu sait montrer les tab en largeur 4 et mettre les tabs comme il faut => ok
- Longueur maximale d'une ligne: 80 caracteres. Passer à la ligne ensuite ou écrire des expression plus courtes.
- (PiiF) quand on passe à la ligne, indenter une fois de plus

Typographie:

- Lors de l’utilisation de parenthèses ou de crochets, il ne faut pas laisser d’espace après la parenthèse ouvrante ni avant la parenthèse fermante. (Babass : Pourquoi ???)
- Lors de l’utilisation d’opérateurs binaires (+, =, *, AND, ...), il faut laisser un espace de part et d’autre de l’opérateur. Exception manifeste dans cette phrase, où les opérateurs sont mentionnés et non utilisés en tant que tels.
- Les opérateurs unaires (!, -, ...) doivent être collés au paramètre auquel ils s’appliquent.
- L'opérateur ternaire ???
_ (PiiF) de toutes façons c'est illisible => je propose <code>(...) ? ... : ...</code>  (les parenthèses rendent presque
  lisible à défaut de mieux ...)
- Appel de fonction avec parenthèses ???
_ (PiiF) ben c'est marqué juste en dessous non ? => <code>tralala(pouet, pouet);</code>
- Par convention, lors d’un appel de fonction, il n’y a pas d’espace devant la parenthèse ouvrante : « f($x) » et non « f  ($x) ». A contrario, et pour bien distinguer, on laisse un espace devant la parenthèse quand il s’agit d’une structure de contrôle intégrée au langage : « <code>if (!$x)</code> » et non « <code>if(!$x)</code> ».
_ (PiiF) : bof, un if on sait que c'est pas une fonction non ?
- Les virgules et points-virgules sont suivis mais non précédés d’un espace.
- accolades ouvrantes en fin de ligne ou en dessous ?
- commentaires en #, /* ou // ?
_ /** pour la doc inline, // pour le reste ?

Nommage :

(NicolasHoizey) Avec l'internationalisation de l'interface de publication et la gestion du multilinguisme, on accueille des utilisateurs du monde entier, mais on continuerait à les empêcher de participer aux évolutions ? Je ne suis pas obtu, je comprends en partie, mais c'est il me semble un vrai débat à mener.

* Variables et fonctions :

- les noms de variables et de fonctions seront en minuscules ; les noms composés, de la forme variable_composee. (Yannick: comment on distingue une variable d'une fonction? Antoine: les variables sont préfixées par le signe « $ »)

Je suggererais:
- Les noms de fonctions globales commencent toutes par 'spip_', les noms de variables globales par 'vspip_'
- Les classes commencent par SPIP_ (bof... cf. paragraphe précédent "en minuscules"), les méthodes par (?) les variables membres par (?).

(PiiF) y'a que du spip donc le prefixe sert à rien. le «v», y'a le «$» qui fait pareil, les méthodes et membres : comme les fonctions et variables (le «la_classe->» faisant la distinction).
_ D'accord, si on met du spip avec un bout d'autre chose, ça permet de pas tout confondre, mais ça implique de tout renommer dans l'existant ...

-* Je ne suis pas d'accord sur le fait que "le prefixe sert à rien". Le prefix permet de faire des backup ciblés des tables concernées et de l'arborescence Agora. Ce qui permet dans le cas de multi-site sur un seul intranet de n'avoir qu'une base tout en permettant la restauration par partie.

-* (NicolasHoizey) Pourquoi ne pas se pencher sur des styles de programmation de plus en plus répandus, à savoir ceux de PEAR ?
-** (PiiF) parce que dans ce cas, on est bon pour commencer à tout réécrire. => autant garder (et compléter) le style actuel.
-*** (NicolasHoizey) Il y aura sans doute de toute façon pas mal de choses à réécrire si j'en crois les chantiers proposés, donc autant se rabattre sur des choses externes répandues pour faciliter la prise en main par les développeurs

* (GasparD) Documentation du code !! selon phpDocumentor, ça peut être minimal :
<cadre>
/** 
  * Petite description rapide.
  *
  * Longue explication pour les programmeurs consciencieux. Cette
  * partie peut faire plusieurs lignes.
  * @author Gaspard
  */
function spip_documente () {
}</cadre>

* (GasparD) Programmation objet, un fichier par classe. Et tout est beaucoup plus lisible.

http://lab.spip.net/spikini/DerniersChangements