Pierre Le Bot

Maniaque dans la vie courante (voire très maniaque), cela se reproduit (en général) sur mon travail. Un code, qu’il soit HTML, PHP, CSS ou n’importe quel autre langage, DOIT être “propre”. Devant le code que je peux rencontrer parfois au boulot, il me semble important de faire un point sur ce qu’est un langage propre, et comment l’obtenir. Ce n’est pas que pour mon plaisir personnel de petit maniaque, je vous assure que c’est très utile…

C’est quoi un code propre ? Eh bien, ça commence avant tout par une structure claire et architecturée : un code qui dispose d’une vraie organisation.

Pourquoi c’est important ? Déjà si un chieur maniaque comme moi passe voir votre code et se sent obligé de passer la nuit à tout recommencer à zéro juste pour assouvir son besoin de perfection. J’exagère à peine, hélas, mais avant de penser aux autres, pensez à vous : si vous revenez dans plusieurs mois sur un développement, quel qu’il soit, et que vous n’êtes pas capable de savoir pourquoi vous avez mis ça ici ou là, pourquoi vous avez appelé ce fichier ainsi ou cette fonction comme cela, vous allez passer deux fois plus de temps car il va vous falloir replonger dans un code que vous ne comprenez pas alors que c’est le votre. Au delà de ça, un code propre permet aux autres développeurs, intégrateurs, bidouilleurs, de maintenir votre code facilement, si ce n’est pas vous qui vous retrouvez à modifier ledit code une fois celui-ci terminé.

Faire un code propre c’est principalement comme ça que ça marche. Il est possible que dans la liste qui suive vous ne soyez pas d’accord avec ce que je mets ou bien que j’oublie des points fondamentaux. N’hésitez pas à commenter ce billet pour vous manifester

• Ne pas appeler ses fichiers n’importe comment, au même titre que ses variables, fonctions, règles… Adoptez une convention de nommage !
  • Pour tous vos dossiers, fichiers, variables, fonctions : choisissez entre le français ou l’anglais (ou n’importe quelle autre langue) ;
  • Evitez de mélanger tout et n’importe quoi pour séparer les mots : entre le tiret, l’underscore et la majuscule à chaque mot, faites un choix et tenez-vous à ce choix !

  Mon conseil : l’anglais est non seulement la langue universelle et permet à quiconque de maintenir votre code, mais il permet également d’éviter des pièges que nous rencontrons en français : verbes conjugués, accentuation bordélique, etc. De même, le tiret me parait être un caractère tout à fait adapté à la séparation des mots dans un fichier, une variable ou une fonction…

• Commentez le code : des conventions existent là aussi. En PHP ou en JAVA, par exemple, si vous utilisez les conventions existantes, vous pourrez générer une documentation automatique grâce aux outils adéquates. Pour le HTML, il n’est pas forcément nécessaire de commenter à outrance comme dans un “vrai” langage de programmation : zones principales, explications brèves sur des choix spécifiques, et basta. En CSS, si vos règles ont des noms clairs et évidents, vous n’aurez quasiment pas besoin de commenter ;
• Indentez correctement le code ! Une indentation correcte est normalement faite avec le caractère tabulation, qui correspond à la touche tabulation, et non pas avec la touche espace enfoncée dix fois de suite. Pour ma part j’utilise une tabulation = 4 espaces ;
• Evitez également d’aller à la va-vite pour faire votre code : logique et sémantique sont deux ingrédients pour pondre un code propre, conforme aux normes, facile à maintenir, respectant les standards, les normes d’accessibilité ou le référencement naturel (j’extrapole, mais c’est volontaire : avec un bon code, tout devient possible).
  On peut facilement faire un site qui fonctionne en adoptant la politique du “je fais du qui marche”, mais on peut aussi faire un site qui fonctionne en adoptant la politique du “je fais quelque chose de propre, logique et réfléchi quitte à y passer du temps” ;
• Un peu de logique aussi, ça peut aider : une fonction qui transforme un texte et l’envoie par mail peut difficilement s’appeler “TransTxPlusEnvMèl”… Niveau maintenance, on fait mieux quand même

Si je me suis mis à faire un billet sur ce sujet, c’est pas (que) pour le plaisir, c’est surtout parce que dans mon boulot actuel, je suis amené à intégrer des templates dans un CMS (j’en ai déjà parlé… suivez un peu !). Ces templates sont créés par des développeurs appartenant à une communauté de ce fameux CMS, mais aussi (parfois, souvent), par des développeurs de la boite dans laquelle je travaille. Leur boulot étant de développer, ils développent, et par conséquent ne sont pas forcément adeptes voire experts du HTML/CSS et optent justement pour cette fameuse règle dite du “qui marche”. Je ne vais pas leur jeter la pierre, loin s’en faut : ce n’est pas leur travail de faire des templates HTML parfaits, c’est le mien. Néanmoins, voici ce que peut donner un code “sale” suivi de mon code “propre”, qui respecte tous les points énoncés ci-dessus : standards, accessibilité, indentation, logique, nommage…

Code sale

<table ###TPARAMS###>
    <tr ###TITLESTYLE###>
        <!--<td width="16" ###ICONSTYLE###>###ICON###</td>-->
        <td nowrap="nowrap" class="titre" width="100%">
            <!--<span ###TNUMBERSTYLE###>###RESULTNUMBER###: </span>-->
            <p>###TITLE###</p>
        </td>
        <!--<td nowrap="nowrap"><p ###PERCENTSTYLE###>###RATING###</p></td>-->
    </tr>
    <!--###RESUMSECTION###-->
        <!--###RS_ITEM###-->
            <tr>
                <!--<td colspan="2" ###STYLEDESCRIPTION###><p>###DESCRIPTION###</p></td>-->
				<td><span class="description">###DESCRIPTION###</span></td>
            </tr>
            <tr>
                <!--<td ###INFOSTYLE### nowrap="nowrap">
		<p>###SIZE### - ###CREATED### - ###MODIFIED###<br>-->
                   <!-- ###PATH###</p>-->
                <td><span class="description">###SIZE### - ###CREATED### - ###MODIFIED###</span></td>
                <!--<td ###INFOSTYLE2### align="right"><p>###ACCESS### ###LANGUAGE###</p>-->
            </tr>
        <!--###RS_ITEM###-->
    <!--###RESUMSECTION###-->

    <!--###HEADERONLY###-->
        <!--###HO_ITEM###-->
            <tr>
                <td ###STYLEDESCRIPTION###><p>###DESCRIPTION###</p></td>
            </tr>
        <!--###HO_ITEM###-->
    <!--###HEADERONLY###-->

    <!--###SUBROWTITLE###-->
        <!--###SR_TITLE###-->
            <tr>
                <td><p><br>###LOTHERMATCHING###<br><br><p></td>
            </tr>
        <!--###SR_TITLE###-->
    <!--###SUBROWTITLE###-->

    <!--###SUBROWS###-->
        <!--###SR_ITEM###-->
            <tr>
                <td><p>###SUBROW###</p></td>
            </tr>
        <!--###SR_ITEM###-->
    <!--###SUBROWS###-->
</table>

Code propre

<dl>
	<dt class="titre">###TITLE###</dt>
	<dd class="description">###DESCRIPTION###</dd>
	<dd class="description">###SIZE### - ###CREATED### - ###MODIFIED###</dd>
</dl>

Vous préférez lequel vous ? Etonnement, je préfère le mien

Le problème qui se pose, au niveau de la maintenance principalement, c’est qu’en devant repasser sur ce fameux template afin de rendre le code plus propre, le travail est fait deux fois : le développeur créé un template qui n’est pas conforme PUIS l’intégrateur repasser derrière pour intégrer ça au mieux.

Dans le cas où le développement de ce template a été fait par un développeur tiers, on s’en fout : le template arrive tout cuit dans les mains de l’intégrateur. Néanmoins, si ce template avait été créé par un développeur de la même société, alors la création et l’intégration de ce template a nécessité deux personnes, donc deux fois plus de temps, et deux fois moins de disponibilités sur un autre projet auquel auraient pu s’atteler l’intégrateur et le développeur.