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 (...) ? ... : ... (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 ? => tralala(pouet, pouet); 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 : « if (!$x) » et non « if(!$x) ».
(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 :
En français
(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 ...
* (GasparD) Documentation du code !! selon phpDocumentor, ça peut être minimal :
* (GasparD) Programmation objet, un fichier par classe. Et tout est beaucoup plus lisible.
http://lab.spip.net/spikini/DerniersChangements