[Prog] L’ultime débat, ou comment bien indenter son code…

Posté le 16 mai 2009 à 12h00 par jaguie

Bonjour à tous,

Comme vous avez pu le lire (ou le comprendre), je viens de commencer depuis deux semaines mon nouveau boulot aux USA. Le premier jour, après deux heures de travail il y a eu un drame interne dans la startup …

Mon boss et moi-même n’indentons pas du tout le code de la même façon… Et j’ajouterais même que l’on fait presque l’inverse sur tout ! Il s’en est donc suivi une intense et intéressante discussion autour de ce débat de type ’open-troll’. Je vais donc essayer de vous exposer la théorie du boss au sujet de l’indentation.

Bon pour les non-informaticiens qui trainent (encore ) par ici, ‘indenter’ signifie la façon de présenter son code. On peut facilement dire qu’il y a autant de méthode que de codeurs, cependant il existe deux principaux chemins.

Pour que les choses soient plus claires, je vais d’abord vous montrer comment j’indentais mon code jusqu’à il y a encore une semaine:

<?php
function exemple(UnObject $obj_un, $var_test){
	if($var_test){
		while(!$test){
			try{
				$test = $obj_un->checker($test);
				if($test == "quelquechose") break; 
			}catch(Exception $e){
				Log::Msg($e, array(	'une', 
									'explication', 
									'detaille'));
			}
		}
		return true;
	}else{
		return false;
	}
}
?>

Je codais donc principalement avec les conventions Zend FrameWork (et oui, Julien Pauli est mon maître spirituel ^^).

Maintenant la méthode de mon boss :

<?php
function exemple(UnObject $i_oUn, $i_varTest)
{
	if ( $var_test )
	{
		while ( $condition == false )
		{
			try{
				$o_sTest = $obj_un->checker($test);
				if($o_sTest == "quelquechose")
				{
					break; 
				}
			}catch(Exception $e)
			{
				Log::Msg($e, array(	'une', 
								'explication', 
								'detaille'
								));
			}
		}
		return $o_sTest;
	}
	else
	{
		return false;
	}
}
?>

Bon, pour les non-initiés, la différence ne saute pas forcément aux yeux, mais grosso modo, ce qu’il faut voir :

Le nommage du typage de la variable (o = object, i = integer, s = string …)
Le nommage du statut de la variable ($i_ pour un input et $o_ pour un output)
La présentation du texte par bloc (avec notamment un { à la ligne)
Des espaces en plus entre les boucles et les conditions ( if ( $cond ) au lieu de if($cond))
…

Bon, les points 1 et 2 sont plus sujets de la convention de nommage que de l’indentation. Mais j’ai fait ‘le package’ comme on dit .

Mon boss possède une bonne dizaine d’années d’expérience de code, il n’a donc pas fait ce choix par hasard et il me la même justifié !

En fait, vous avez surement déjà tous lu la célèbre étude de l’université de Cambridge :

Le cerveau est donc plus à l’aise pour voir les espaces et le début des ‘mots’ que les lettres qui le composent. De plus, tout programmeur vous le dira: « une fonction c’est 5 min à taper et 20 min à déboguer« , ou autrement dit, on passe beaucoup plus de temps à lire son code qu’à le taper, il faut donc mieux l’adapter à la lecture.

Voilà la justification de mon boss, et j’ai trouvé cette théorie corrélée à l’étude de Cambridge vraiment intéressante (et même pertinente !).

Et puis si vous vous posez encore la question, comme c’est le boss, je n’avais pas vraiment le choix et j’ai dû m’adapter ^^.

(Mais il m’a tout de même avoué qu’à l’époque il codait avec mon indentation initiale).

Et vous, vous indentez comment ?

Bonne journée à tous,

Enjoy ,

Jaguie

Partager et découvrir :

Billets similaires

Tags: PHP // 17 Commentaires »

17 Réponses pour “[Prog] L’ultime débat, ou comment bien indenter son code…”

lemoussel // Le 16 mai 2009 à 13h44 at 13:44

Hummm …..
Bin ALors ChroGeek tu respecte pas la méthode de ton boss :+

if($test == « quelquechose ») => -1
Correction : if ( $test == « quelquechose » )

}catch(Exception $e) => -1
Correction : } catch(Exception $e) => -1

Bon allez, chut … :blush:
Et en espérant que le boss ne lit pas ton blog
Araen // Le 16 mai 2009 à 15h54 at 15:54

J’ai toujours indenté mon code avec des tabulations (là aussi y’a le combat entre espaces/tabs), et je préfère en effet l’indentation de ton boss, même si je ne met pas d’espace entre if(cond), …
Pakito // Le 16 mai 2009 à 16h31 at 16:31

J’avoue que ma méthode de codage se rapproche plus de celle de ton boss, sauf pour les variables dont je ne spécifie rien de particulier … une $var est une $var, point.

Je fais des retours à la ligne pour les { et }, j’espace le contenu des parenthèses …
Godefroy (Skreo) // Le 16 mai 2009 à 16h39 at 16:39

J’indente comme tu le faisais jusqu’à maintenant. Et je ne pense pas changer mes habitudes
A ce propos, j’avais lancé une petite chaîne il y a près d’un an, invitant des développeurs à montrer leurs conventions en programmation sur leur blog :
http://www.skreo.net/article-2904-181807-mes-conventions-en-programmation.html
Tu peux y participer si tu veux, ce n’est pas trop tard ^^
Adrian Gaudebert // Le 16 mai 2009 à 16h48 at 16:48

J’indente comme ton boss. Dans les conditions, je ne rajoute des espaces entre les parenthèses que si le contenu est gros (si y a juste un $a == $b je met pas d’espace), et parfois je vais même à la ligne si y a un test très long.

J’apporte beaucoup d’attention à la qualité du code, j’espace au maximum, pour le plaisir des yeux et surtout parce que c’est bien plus facile à déboguer ensuite !

Pour les conventions de nommage, là j’estime qu’il faut s’adapter au projet. Moi j’ai les miennes que j’utilise sur mes projets (ou ceux que je manage), mais j’ai pas (ou peu) de problème à m’adapter à d’autres conventions.
AbriCoCotier // Le 16 mai 2009 à 18h08 at 18:08

Mouai. Autant pour les espaces dans les parenthèses, et pour les o_ et i_ avant les variables, je suis d’accord, c’est pas bête et ça permet aux autres de relire.

MAIS :

Pour ce qui est de sauter à chaque fois 15000 lignes et mettre des espaces partout, c’est plus lourd qu’autre chose. Le code peut-être dense, au moins on passe pas à chaque fois une seconde ou deux à retrouver où on est (ben oui : si le code est aéré, il prend plus de place, et donc plus de temps à se déplacer dedans).
Niaa // Le 16 mai 2009 à 20h12 at 20:12

Mouais, alors déjà il y a une faute moche dans le titre de cet article !

Sinon pour l’indentation comme c’est le sujet, je trouve que ton boss utilise aussi des choses lourdes pour pas grand chose : par exemple cette ligne :

while ( $condition == false )

En quoi est-elle moins claire que :

while( !$condition )

Toute personne ayant fait au moins 2 semaines de code dans sa vie (et donc apte à relire ton code sans se tirer une balle) saura que le ! en début de test sert à faire un non logique sur ce test.

De plus le langage le permet, ce n’est donc pas une mauvaise façon de coder. Et je dirais même que c’est plus clair selon moi.

Je suis peut-être attaquable sur les performances d’un tel raccourcissement de test, après tout… Mais dans ce cas j’ai toujours entendu que === était plus sur et plus rapide que == donc le boss aussi.

P.-S. : tu as fait une erreur à cette ligne dans le code du boss :

if($test == « quelquechose »)

sa variable ne s’appelle pas $test mais $o_sTest.

Voila, et comme c’est mon premier commentaire, j’adore ce que tu fais ;p et c’est avec plaisir que je Googleread ton blog !
benjaM1 // Le 16 mai 2009 à 20h37 at 20:37

Personnellement je fais un mix entre ta façon et celle de ton boss.
- pour les accolades je fais comme lui, je préfère voir ou commence et fini un block.
- pour les noms de variables je trouve ça inutile de mettre un i, o ou b selon le type de la variable dans le cas de php … php n’est pas typé!
- pour les noms de variables toujours, si elle contient deux mot je les écrits en entier (il vaut mieux des noms de variables expliciites que des abréviations qui peuvent induirent en erreur … on sait jamais) et je les sépare par un _ (jamais de majuscules pour les différencier des classes)
- dans ta fonction tu n’est pas obk-ligé de faire :
else
{
return false;
}
un « return false; » suffit puisque de toute façon si tu es rentré dans le if tu sors de la fonction et tu économises trois ligne :p
- enfin, je saute toujours une ligne avant un return comme ça je vois bien où se termine le traitement de la fonction

Sinon c’est comment les USA ?
jaguie // Le 16 mai 2009 à 21h49 at 21:49

Bonjour bonjour
@Araen, ok, je fais pareil, mais avec des espaces le cerveau arrive à mieux extraire les mots…
@Pakito, vouaip pour les variable, c’est justement parce que PHP n’est pas(assez) type. Ca permet donc de faire une sorte de validation.
@Skreo, copain de code ^^ . Vais aller voir ta chaine tout de suite.
@Adrian Gaudebert, +1 pour le nommage !
@AbriCoCotier, vouaip d’accord avec toi, mais vous qui connaissez le code vous comprennez l’esprit ! Parce qu’il faut absolument avoir à l’esprit que j’ai pas mal lutté avec wordpress pour qu’il me formate pas trop le code… Il a notamment fait n’importe que au niveau du array() … Sinon, plutot que de sauter plein de lignes, je suis assez friand du // ————- ou autre // ********INFO***********
@Niaa, merci merci Elle piquat sévère celle la! C’est corrigé, merci ! Pour le !$var contre le $var == , c’est un grand débat, moi ça depend du moment… Après il y a du benchmark sur le bordel, mais je ne sais pas si c’est vraiment falgrant la diff entre les deux… Merci pour ta conclusion ))

@TOUS, merci pour vos long et interessant commentaire. Passé une bonne fin de week-end:)
[Prog] L’ultime débat, ou comment bien indenter son code… | ChroGeek // Le 16 mai 2009 à 23h23 at 23:23

[...] [Prog] L’ultime débat, ou comment bien indenter son code… | ChroGeekwww.chrogeek.com/2009/05/prog-lultime-debat-ou-comment-bien-… par jaguie il y a quelques secondes [...]
Jérémy Faivre // Le 18 mai 2009 à 07h52 at 7:52

je ne nomme pas les variables en fonction de leur type, je ne trouve pas personnellement que ça facilite tant que ça la lisibilité, ça fait beaucoup de répétition dans le code, de noms qui se resemblent (plusieurs $i_*, $o_*, etc… ). D’autant plus qu’ils ont double sens, des fois du input/output, des fois du integer/object/… pour les mêmes lettres…

En revanche en ce qui concerne les espacements et les sauts de ligne, j’ai quasiment toujours codé comme ton boss
petrus // Le 18 mai 2009 à 13h44 at 13:44

1. Héritage de la notation hongroise (http://fr.wikipedia.org/wiki/Notation_hongroise). Notation motivée par la programmation procédurale et fonctionnelle, à bannir selon moi
2. En conjonction avec 1. Cela doit être terrible.
3. Habitude du pseudo-code. J’utilise encore parfois pour des blocs algorithmiques complexes, sinon j’utilise le refactoring de l’IDE.
4. Utile pour la lisibilité, quand on ajoute des opérateurs de différentes nature dans une expression riche.
zigazou // Le 20 mai 2009 à 08h41 at 8:41

Hello !

Voici comment j’aurais écrit ton code :

checker($test);

// Explication du test en une ligne
if($test== »quelquechose ») break;
} catch(Exception $e) {
Log::Msg($e,array(‘une’,'explication’,'detaille’));
}
}
return true;
} else {
return false;
}
}
?>

Note : le code doit être vu avec une fonte monospace et une indentation de 2 espaces.

Perso, quand je lis un code que je n’ai pas écrit, la première chose que je cherche à faire c’est de comprendre sa structure.

Et une fonction de 10 lignes de code et 50 colonnes qui se transforment en 30 lignes et 120 colonnes, ça ne m’aide pas du tout à en comprendre la structure : tu passes alors ton temps à déplacer ton regard à droite et à gauche quand tu ne le perds pas à faire défiler ta fenêtre…

Il faut ajouter que les commentaires ne sont pas faits pour les chiens car si ton code met en place un superbe algorithme, il est plus intéressant de savoir comment il marche que de savoir que telle ou telle variable est un entier ou une chaîne.

Enfin, la coloration syntaxique est un aide beaucoup plus précieuse que bon nombre de règles d’écriture de code.

Concernant le nom des variables, j’ai une petite règle : j’utilise les pluriels et les singuliers.

Par exemple :

Voilà, c’est mon avis perso, et je le partage
zigazou // Le 20 mai 2009 à 08h44 at 8:44

Flute, je donnais un exemple et le commentaire a tout mangé :

function exemple(UnObject $obj_un,$var_test) {
⋅⋅// Explication du test en une ligne
⋅⋅if($var_test) {
⋅⋅⋅⋅// Explication de la boucle en une ligne
⋅⋅⋅⋅while(!$test) {
⋅⋅⋅⋅⋅⋅try {
⋅⋅⋅⋅⋅⋅⋅⋅// Explication de l’appel de fonction
⋅⋅⋅⋅⋅⋅⋅⋅$test=$obj_un->checker($test);
⋅
⋅⋅⋅⋅⋅⋅⋅⋅// Explication du test en une ligne
⋅⋅⋅⋅⋅⋅⋅⋅if($test== »quelquechose ») break;
⋅⋅⋅⋅⋅⋅} catch(Exception $e) {
⋅⋅⋅⋅⋅⋅⋅⋅Log::Msg($e,array(‘une’,'explication’,'detaille’));
⋅⋅⋅⋅⋅⋅}
⋅⋅⋅⋅}
⋅⋅⋅⋅return true;
⋅⋅} else {
⋅⋅⋅⋅return false;
⋅⋅}
}

foreach($clients as $client) {
⋅⋅// traitement
}
David // Le 26 décembre 2011 à 12h56 at 12:56

Bonjour,

je suis web developer senior dans une société de site web.
J’interviens car je suis assez d’accord sur ton article, mais je voudrais mettre mon grain de sel

Pour le retour à la ligne de l’accolade ouvrante, pour ma part j’ai laissé tombé depuis de longues années. Pourquoi ? Je trouve que le fait d’indenter correctement son code avec les tabulation suffise au cerveau pour discerner les différents blocs, et donc mettre cette accolade à la ligne te fait perdre une ligne à l’écran pour rien. Dans un algorithme complexe pour lequel tu as besoin de voir un maximum de bloc simultanément, si il faut chaque fois scroller, ça devient pénible, et si on perd une ligne à chaque parenthèse ouvrante, c’est dommage.

Sinon par rapport à la fameuse études, je suis assez d’accord, mais alors je suis étonné de voir que tu ne met pas d’espace entre les ( ).

Pour moi :

function salut() {
return strtolower($salut);
}

sera moins lisible que :

function salut() {
return strtolower( $salut );
}

Car comme tu le dit le cerveau recherche les espace entre les mots.

C’est comme quand je vois ceci dans un template créé par un intégrateur :

… CODE HTML ….

Le fait que la ligne commence par <?php ça ne permet pas au cerveau de voir directement que c'est un if, for, etc… et donc l'ensemble est moins lisible.

Moi j'écris :

… CODE HTML …

Ici effectivement c’est contradictoire avec ce que je dis plus haut par rapport aux lignes en plus inutile, mais dans un template on aura jamais des algorithme compliqué, car ce n’est que de l’affichage de données, ou alors il y a un problème de conception car du code de template doit être compris par des non-développeur. (intégrateur)

Enfin bref, les goûts et les couleurs ça ne se discutent pas, mais lorsqu’on travaille ne équipe il est bon de s’accorder sur une méthode commune d’écriture.

Voilà en espérant avoir apporté ma pierre à l’édifice, si je puis dire

A+
David // Le 26 décembre 2011 à 12h57 at 12:57

Arf mon indentation à pas été prise en compte, je me permet de reposter le message? tu peux effacer le plus ancien

Bonjour,

je suis web developer senior dans une société de site web.
J’interviens car je suis assez d’accord sur ton article, mais je voudrais mettre mon grain de sel

Pour le retour à la ligne de l’accolade ouvrante, pour ma part j’ai laissé tombé depuis de longues années. Pourquoi ? Je trouve que le fait d’indenter correctement son code avec les tabulation suffise au cerveau pour discerner les différents blocs, et donc mettre cette accolade à la ligne te fait perdre une ligne à l’écran pour rien. Dans un algorithme complexe pour lequel tu as besoin de voir un maximum de bloc simultanément, si il faut chaque fois scroller, ça devient pénible, et si on perd une ligne à chaque parenthèse ouvrante, c’est dommage.

Sinon par rapport à la fameuse études, je suis assez d’accord, mais alors je suis étonné de voir que tu ne met pas d’espace entre les ( ).

Pour moi :

function salut() {
. . . . return strtolower($salut);
}

sera moins lisible que :

function salut() {
. . . . return strtolower( $salut );
}

Car comme tu le dit le cerveau recherche les espace entre les mots.

C’est comme quand je vois ceci dans un template créé par un intégrateur :

. . . . CODE HTML

Le fait que la ligne commence par <?php ça ne permet pas au cerveau de voir directement que c'est un if, for, etc… et donc l'ensemble est moins lisible.

Moi j'écris :

. . . . . . . . CODE HTML

Ici effectivement c’est contradictoire avec ce que je dis plus haut par rapport aux lignes en plus inutile, mais dans un template on aura jamais des algorithme compliqué, car ce n’est que de l’affichage de données, ou alors il y a un problème de conception car du code de template doit être compris par des non-développeur. (intégrateur)

Enfin bref, les goûts et les couleurs ça ne se discutent pas, mais lorsqu’on travaille ne équipe il est bon de s’accorder sur une méthode commune d’écriture.

Voilà en espérant avoir apporté ma pierre à l’édifice, si je puis dire

A+
David // Le 26 décembre 2011 à 13h03 at 13:03

Non d’une patate ! Les tags php sont disparu

<?php if( … ) : ?>
. . . . CODE HTML
<?php endif; ?>

moins lisible que :

<?php
. . . . if( … ) :
?>
. . . . . . . . CODE HTML
<?php
. . . . endif;
?>

ChroGeek