The ASW - Programmation

Vous avez dit « Coding Style » ?

cgo2 — Fri, 14 Oct 2005 18:11:00 +0000

Le terme Coding style (appelé également Coding standard, ou Code convention), désigne l'ensemble des règles de mise en forme d'un code (nom des variables, indentation, etc.). Pour la plupart des projets informatiques, le Coding Style est un document indiquant aux développeurs, de manière plus ou moins exhaustive, comment présenter son code afin que le projet soit homogène et surtout, lisible par tous. Ce document peut-être rédigé par le service Qualité, ou par le chef de projet, ou encore par le geek de service pour les projets libres. Voyons en détails de quoi il s'agit...

Pourquoi est-ce utile ?

D'abord, quel est l'interet de mettre en forme son code ? La lisibilité ! Un code bien mis en forme est plus facile à lire, à comprendre, et donc à maintenir.

Ensuite, quel est l'interet d'avoir une même convention pour tout un projet ? Encore la lisibilité ! Si chaque développeur présente son code comme il l'entend, l'intégration risque de se faire dans la douleur. Les différents morceaux seront difficiles à lire, les noms des variables seront surement incohérents (avec risque de doublons), etc.

Enfin, quel est l'interet de rédiger un document ? Pouvoir entrer dans les détails. En effet, si on peut se mettre d'accord sur les grandes lignes (indentation notamment) par oral, cela devient plus difficile dès qu'on décide d'entrer dans les détails ; et croyez moi, certains Coding style sont tellement détaillés qu'ils vous imposeraient presque la couleur du caleçon...

Voyons maintenant les points essentiels de toute bonne convention de codage qui se respecte.

Conventions de nommage

La façon de nommer les variables et les fonctions (identifiers en anglais) est sans aucun doute le point le plus important d'un projet - et pourtant pas le plus médiatique. En effet, de bonnes règles de nommage permettront la plupart du temps de connaitre en un seul coup d'oeil certaines caractéristiques (au choix : type, portée (globale, locale, publique, privée, ...), appartenance, dépendance, etc.) et de savoir à coup sûr comment nommer une variable selon le contexte. A l'inverse, aucune règle amenera immenquablement à des noms de variables sans aucune logique (toto, tata et compagnie), et provoquera à coup sûr des erreurs parfois difficiles à detecter (exemple : Ah merde, je suis en train de détruire une variable globale là !).

Sur la mise en forme seule, il existe un grand nombre de possibilités, revelant plus du goût qu'autre chose :

Jouer sur la casse (Case en anglais) : miniscules, MAJUSCULES, MixedCase ou mixedCase ; et quid des abrévations, faut-il écrire trainSNCF ou trainSncf ? (désolé pour la SNCF, c'est le seul exemple qui m'est venu à l'esprit :)
Utiliser le caractère underscore « _ » : liste_double
Retirer les voyelles, ou les espaces : lst (liste)
Plus généralement, utiliser des variables courtes, cptList, ou des_variables_explicites ?

Là où ça devient interressant, c'est d'associer une mise en forme à un contexte. Par exemple, voici les conventions que j'utilise pour un projet de C++ :

Les variables globales et les macros en MAJUSCULES.
Les variables locales en minuscules_avec_des_underscores et un nom explicite.
Les variables internes à une classe finissent par un underscore_.
Les variables statiques dans une classe commencent par un _underscore.
Les fonctions membre d'une classe sont enMixedCase avec une minuscule au départ. Les abréviations sont également en minuscule (sauf la première lettre si besoin).
Les fonctions non-membres sont précédée du nom du modules si aucun namespace, et en mixed case, comme ça : module_mixedCase ou namespace::mixedCase.
Les classes sont en MixedCase avec une majuscule au départ.

Quelques styles célèbres

A vrai dire, le seul style que je connaisse qui porte un nom est le style hongrois (Hungarian notation) qui consiste à préfixer les variables par des lettres indentifiant leur type. Par exemple : ulToto est une variable de type unsigned long (int). Même si la démarche peut sembler interessante, elle s'avère à l'usage peut pratique et peut lisible. Personnellement je la déconseille.

Quelques liens :

Une page présentant différents style de nommage.
La page wikipedia sur les conventions de nommage.

Indentation

Indentation: Disposition particulière du texte d'un programme faisant apparaître des décalages de la marge dans l'écriture des divers blocs d'instructions.(source : Le Petit Robert)

L'indentation concerne non seulement la manière de décaler les blocs d'instructions, mais aussi le placement des accolades (ou autre élément délimiteur de bloc). Autant pour le nommage des variables il est facile de faire un peu ce qu'on veut et d'être spécifique à chaque type de programme, autant là, il vaut mieux se rallier à un camp existant ; d'une part parceque tout a déjà été inventé, et d'autre part parceque ça demande moins de temps d'adaption aux nouveaux développeurs.

Attention, l'indentation est un sujet extrêmement trollifère, et il est difficile d'en parler déclancher une guerre de religion. D'ailleurs, je ne vais pas m'en priver !

Quelques styles célèbres

Le K&R, est le style de Brian Kernighan et Dennis Ritchie, les inventeurs du langage C. C'est de loin le plus utilisé et le plus connus (et généralement celui qu'un débutant adopte naturellement). Il est notamment utilisé (avec quelques petites améliorations) pour le kernel Linux. Je ne vais pas y aller par 4 chemins : c'est mon style préféré.

void truc()
{
	if (x > y) {
		faire_un_truc();
	}
	fin();
}

Le Linux Kernel Coding Style est disponible dans les sources du noyau linux (dans Documentation/CodingStyle). Vous pouvez consulter la version disponible dans les sources du kernel 2.6.12.2

Le style GNU, est utilisé (de gré ou de force) pour tous les projets GNU. Dans mon environnement, c'est le deuxième et le seul autre style que je côtoie souvent.

void
truc()
{
  if (x > y)
    {
      faire_un_truc ();
    }
  fin();
}

Voir le Gnu Coding Style, section Formatting.

Pour plus d'informations sur les différents styles d'indentation, ainsi que les arguments pour et contre chacun, je vous conseille la page Wikipedia.

Trollons un peu : pourquoi utiliser des tabs ?

Pour mettre en retrait du texte, il y a deux écoles : les pro-espaces qui prônent l'utilisation de séquences d'espaces et les pro-tabs qui militent pour l'utisation du caractère « tabulation ». Et la guerre entre les deux fait rage depuis des années. Par exemple, taper les deux mots « indentation tabs » dans Google renvoie plus de 360 000 réponses, avec en des titres comme Tabs versus Spaces, Why I prefer no tabs in source code, Indentation wars end here, Space indentation is morally wrong, etc. Bref, tout un programme ! En ce qui me concerne, j'ai choisi mon camp, celui des tabulations, et je vais vous expliquer pourquoi.

A l'origine (c'est-à-dire au temps des machines à écrire), le caractère tabulation permet de déplacer le curseur jusqu'à un point d'arret marqué sur une réglette (tabstop en anglais). Cela évitait à l'opérateur d'avoir à taper une série d'espace pour aligner des éléments. Tiens donc, « aligner des éléments » ça ne vous rappelle rien ? Aujourd'hui, on retrouve le principe des réglettes et des tabstop dans les logiciels de traitement de texte tels que Microsoft Word ou OpenOffice Writer. La tab (parceque c'est une tabulation) permet par exemple de faire un retrait au début d'un paragraphe.

De manière plus générale, dans tout éditeur de texte moderne, il est possible de choisir la taille des tabs. Concrètement, vous pouvez définir qu'une tab fera 2 caractères ou 4 ou 8 ou autant que vous voulez ! Un seul caractère ASCII permet donc non seulement de remplacer efficacement une série d'espaces (et ainsi d'avoir un fichier plus petit), mais aussi de laisser celui qui consulte le fichier la possibilité de modifier son apparence visuelle par simple réglagle de son éditeur ! Exemple : vous avez un grand écran avec une grande résolution et vous préferez les tabs de 8 caractères ? Pas de problème. Vous passez le fichier à un ami qui a un tout petit écran et préfére des tabs de 2 caractères ? Pas besoin de toucher la moindre ligne du fichier, un simple réglage suffit.

Pour en savoir plus, voici quelques liens très utiles :

Tabs versus Spaces: An Eternal Holy War : L'auteur est pro-espaces, mais le rappel historique du caractère tabulation est très pertinent.
La page wikipedia sur le caractère tab.
Use Tabs in Source Code, ou pourquoi les tabs c'est mieux.
Tab-size independent source code formatting : Technique ultime d'indentation à base de tab permettant d'être complètement indépendant de la taille paramétrée.

Trollons un peu plus : pourquoi le GNU Coding Style est-il une erreur de la nature ?

Je n'aime pas Richard M. Stallman (RMS). Certes, il a fait énormement pour le libre (c'est l'inventeur de gcc, de la GPL, etc.), mais c'est un intégriste borné qui ne voit malheureusement pas plus loin que le bout de son clavier et qui se permet de donner son avis sur tout et n'importe quoi (oui, comme RAGE2000, cqp). A chaque fois que j'en entend parler, il a encore sorti une connerie plus grosse que lui. Tiens par exemple, la dernière fois il ordonnait à ses fidèles de ne pas acheter les livres Harry Potter (à quand une intifada ?). Et la fois d'avant, il se permettait de juger le projet de Constitution Européenne et d'affirmer que c'était une bonne chose d'avoir voter « non » (c'est un américain, qu'est-ce qu'il y connait ?). Et parmi toute les idioties de RMS, celle qui me pourri le plus la vie au quotidien est son GNU Coding Style...

Première chose : déclarer les fonctions sur deux lignes (ou plus !). Les ayatollah affirment que ça permet de retrouver facilement l'implémentation d'une fonction parmis des centaines de milliers de lignes de code. Explication : il leur suffit de rechercher la ligne commençant directement par le nom de la fonction recherchée. En effet, si on cherche le nom de la fonction simplement, on va tomber, non seulement sur la déclaration, mais également sur tous les appels à ladite fonction. Cet argument est valable, certes, mais on peut tout à fait trouver une astuce similaire pour un autre style, par exemple avec le K&R il suffit de rechercher une ligne contenant le nom de la fonction et aucun caractère « ; », ou bien une ligne contenant le nom de la fonction directement suivie d'une ligne débutant par une accolade... Une autre solution est d'utiliser un IDE moderne, qui permet de se rendre directement à l'implémentation par simple clic. Ah oui, mais ça, contraire à la religion des GNUistes, qui doivent utiliser GNU emacs.

Deuxième chose : les « demi-niveaux » d'indentation ; c'est-à-dire le placement des accolades à mi-chemin entre les deux blocs, comme ceci :

if (x > y)
  {
     faire_un_truc ();
  }

Ce que j'en pense, c'est qu'en plus d'être illisible, ça n'a pas grand interet. Mais bon, je veux bien admettre qu'il s'agit là d'une notion tout à fait subjective ; comme dirait ma grand-mère : Les goûts et les couleurs.... Alors discutons sur des choses objectives.

Premièrement, est-ce bien moral de « couper » l'indentation en deux, et de créer ainsi ces « demi-niveaux » ? Je ne crois pas. Ca casse l'imbrication et ça perturbe la lecture : la notion de « demi » n'est pas naturelle et on a l'impression que le bloc est en fait 2 niveaux en dessous.

Deuxièmement, la façon d'indenter. Pour créer ces « demi-niveaux », il faut impérativement utiliser des espaces au lieu des tabulations (voir ci-dessus). Cela à 2 inconvenients majeurs :

Il faut plusieurs caractères « espace » pour imiter un seul caractère « tabulation » ; ça prend plus de place pour le stockage (essayez avec un fichier de quelques centaines de lignes pour voir, la perte peut très vite se compter en kilo-octets), et donc rend la compilation un poil plus longue (parceque fichier plus gros à parser), ainsi que les commits et autre manipulation.
Les développeurs ne peuvent pas modifier la valeur de l'indentation selon leur goûts (2, 4, 8, ...)

Pour conclure ce petit troll, je vais citer Linus Torvalds (le papa du noyau Linux) : First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture. (« Avant tout, je vous suggère d'imprimer une copie du GNU Coding style, et de NE PAS le lire. Brulez-le, c'est un grand geste symbolique. »).

Encore plus loin...

Même si ces deux notions (nommage et indentation) sont les plus importantes (et les plus celèbres), il y a bien d'autres point à préciser si on veut rédiger un coding style complet. Parmi celles-ci :

Les espacements. Faut-il écrire : m = moyenne(a,b); ou m=moyenne(a,b); ou encore m = moyenne(a, b); ?
Les noms de fichiers, et l'arborescence du projet. Les noms de fichiers doivent-ils être en miniscules uniquement ? Faut-il faire une classe par fichier ?
On peut aller encore plus loin, en imposant par exemple un nombre de lignes limite pour les fonctions, un nombre de variable maximum, ou, comme je le disais en introduction, la couleur du caleçon à porter pour coder !

Bref, comme vous avez pu le constater, les standards de codage forment un sujet très vaste et particulièrement... délicat. Les guerres sont nombreuses, très nombreuses, à tel point qu'il est difficile d'en parler sans que ça dégénère (essayer de poser une question sur un forum de geek en postant un morceau de code : à tous les coups quelqu'un va venir vous dire que votre coding style n'est pas bon !). Et encore, là je n'ai survolé que les points les plus connus...

Note : Saviez-vous que, lorsqu'on parle de typographie, on dit une espace ?

Mon premier programme C/PHP

cgo2 — Mon, 02 May 2005 11:16:00 +0000

Comment embarquer PHP dans un programme C de la manière la plus basique possible.

Hello world

En guise d'"Hello World", nous allons essayer d'executer la commande phpinfo().

Avant tout, il faut initialiser le module php embed. Tout ceci n'étant absolument pas documenté, je ne saurais dire à quoi correspondent les paramètres.

static char *argv[2] = {"monboprog", NULL};

if ( php_embed_init(1, argv PTSRMLS_CC) == FAILURE ) {
	puts ("Impossible d'initialiser PHP");
	return -1;
}

Maintenant on peut executer une commande. On utilise zend_eval_string qui prend comme premier paramètre la commande à executer. Je ne sais pas à quoi correspond le deuxième (je laisse NULL). Quant au dernier, apparement on peut mettre n'importe quoi... Allez comprendre !

Zend (le parseur php) fournis des macros imitant le try-catch du C++, permettant de recuperer les erreurs de php. Il n'y a donc qu'à les utiliser. Et voila ce que ça donne :

zend_first_try {                                                                                                                   
	if ( zend_eval_string("phpinfo();", NULL, "php embed roulez") == SUCCESS )
		puts("Commande executée avec succès");
	else    
		puts("Impossible d'executer la commande");
} zend_catch {
	printf ("Exception %d", EG(exit_status));
} zend_end_try();

Enfin, on arrette php avec la commande suivante :

php_embed_shutdown(TSRMLS_C);

Il ne manque plus qu'à inclure php_embed.h, et on peut essayer de le compiler. Le programme complet d'exemple est disponible par ici

Compilation

Ca c'est la partie la plus galère, surtout quand rien n'est documenté. Je tiens d'ailleurs à remercier kermit, une star du Makefile, sans qui je ne serais sans doute jamais arrivé à compiler cette saloperie de programme.

En fait, php_embed.h demande pleins d'autres fichiers d'entetes, situés un peu partout dans les sources de PHP. Il faut donc rajouter un paquet de paramètres d'inclusion à gcc. Dans un makefile, ça donne :

# chemin des sources de php
PHPPATH=/home/cgo2/documents/prog/php/php-5.0.2
PHPFLAGS=-I$(PHPPATH) -I$(PHPPATH)/Zend -I$(PHPPATH)/TSRM -I$(PHPPATH)/sapi/embed

Pour le linkage, il faut utiliser la lib que l'on a compilé :

LDFLAGS=-L$(PHPPATH)/libs
LIBS=-lphp5

Le makefile pour ce programme d'exemple n'est pas encore parfait, puisque trop de paramètres sont hardcodés, mais bon...

Execution

Premier test :

$ ./monboprog
./monboprog: error while loading shared libraries: libphp5.so: cannot open shared object file: No such file or directory

Pas grave, il suffit d'ajouter le chemin de la libs dans la variable d'environnement qui va bien :

$ export LD_LIBRARY_PATH=~/documents/prog/php/php-5.0.2/libs/

Et voila :)

Conclusion

Il reste encore beaucoup à faire pour pouvoir embarquer facilement php : faciliter la compilation et le linkage (tout le monde n'a pas les sources de php sous la main), et également l'execution. Quant au code, dans un premier temps un découpage en fonctions permettant d'eviter de manipuler Zend directement s'impose. Il faut ensuite voir comment inclure des fichiers php, exporter des fonctions C pour les utiliser dans les scripts, etc... Mais au moins avec cet exemple vous pourrez dire : "moi aussi j'ai réussi à embarquer php" !

Quelques liens

LE programme sans lequel on aurait rien reussi : le module php-irssi qui permet de script irssi avec php. Malheureusement il n'y a aucun site officiel, et le projet semble mort. On peut encore recuprer les sources sur le CVS de php
Un PDF interressant par l'auteur de php-irssi

Compiler PHP avec le support embed

cgo2 — Sat, 02 Apr 2005 11:13:00 +0000

Etant donné l'absence complete de documentation sur le module "embed" de php, les articles ont tous été écrit à partir d'un travail de reverse engeenering effectué par kermit et moi-même (cgo2), et donc peuvent se reveler incorrects et/ou incomplets. Evidemment, tout ceci est fait sous Linux.

Première chose, nous allons recuperer les sources de PHP. A l'heure où j'écris cet article, la version la plus récente est la 5.0.2, disponible par ici : http://www.php.net/downloads.php

Après avoir décompressé l'archive, il faut configurer PHP avant la compilation. Pour l'instant on ne compile que la base avec le module "embed" (pour les autres modules, je vous conseille d'aller lire la doc)

$ ./configure --disable-all --enable-embed
$ make

La lib libphp5 (.so et .la) est placé dans le repertoire libs/, nous en aurons besoin par la suite pour le linkage.

Mais il va falloir également beaucoup de headers pour la compilation, gardons donc les sources de php intactes pour l'instant.

Tout est pret pour écrire notre premier programme C/PHP