Comment bien coder ?

Ceci n’engage que moi !

En préambule je souhaite dire que je code depuis trop longtemps pour retrouver le nombre exact d’années. Mais cela date des premiers ordinateurs personnels, avant même l’existence de Windows… Appelez moi Papi ! … Voilà que je viens de perdre 80% de mon audience !

Ce qui va être dit ici n’est pas forcément en corrélation avec ce qui est enseigné aujourd’hui ni même avec ce qui me l’a été à mes débuts. C’est le fruit de mon évolution, mon expérience et mon coté pragmatique.

Ne me faites pas dire ce que je veux pas dire ! Ca ne va pas être la fête du slip pour autant. Simplement je vais vous faire part de ce qui me semble primordial pour fournir un travail de qualité et gagner du temps. Ce qui n’est pas incompatible, bien au contraire !

Réfléchir avant, coder ensuite

Développer une application, quelle qu’elle soit, demande de la rigueur et de l’organisation. Que vous soyez en équipe ou non. Il n’est pas possible de partir bille en tête et de « pisser de la ligne » directement.
Cela demande de la méthode.

Je ne parlerai pas ici de méthodes enseignées dans les écoles mais uniquement de l’état d’esprit que vous devez avoir pour ne pas aller dans le mur. Vous ferez le choix de vos méthodes d’analyse et de conception vous même.

Réfléchissez !

Commencez par prendre un papier et un crayon. Essayez de découper le projet global en sous projets lorsque c’est possible.
Vous savez, le fameux « Comment manger un éléphant ? ben… une bouchée après l’autre! ».

Nommez bien ces sous-projets, notez les et organisez les entre eux. Notez les workflows pour mieux appréhender les subtilités et intégrer profondément la structure générale du projet.
Il apparaîtra forcément des contraintes de données, des contraintes logiques, des contraintes d’interface, des contraintes techniques… Notez !

Faites une ébauche des interfaces homme/machine. Cela vous permettra de détecter d’éventuels problèmes de logique et surtout, cela vous aidera à penser comme le futur utilisateur. Mon premier patron disait toujours « Penses à la caissière de chez Leclerc, si tu lui fais cliquer sur un bouton de trop elle te maudira ! »

Une fois que vous avez fait le tour, il peut être utile de passer par une phase de rédaction dans laquelle vous mettrez au propre, ce que vous avez analysé, et l’organisation modulaire de votre future application.

Recherchez !

Dans votre analyse vous avez sûrement détecté des « points difficiles », pour lesquels vous ne savez pas encore comment vous allez les résoudre.
Listez-les. Et recherchez (sur le web…) si il n’existerait pas des solutions déjà codées.
Evaluez-les, estimez si elles valent la peine d’être utilisées ou si vous devrez re-coder vous même, ce qui serait du temps supplémentaire à ajouter au développement.

Il peut toujours être utile de ne pas réinventer la roue !

Codez !

Lorsque vous aurez passé ces deux phases vous aurez une vision beaucoup plus précise du projet. Vous pourrez alors commencer à structurer votre code si vous ne travaillez pas avec un framework qui vous impose déjà sa structure.
Personnellement je commence à coder l’architecture générale du projet en laissant les fonctions unitaires vides. Puis progessivement vous « remplissez les cases ».

Commenter son code

L’entête du script

Que vous soyez freelance ou dev dans une grosse boite, chaque script devrait avoir une entête plus ou moins normalisée. Vous devriez y trouver des infos comme la date de création du script, l’auteur, le prototypage du script (les données qui peuvent arriver en entrée par exemple), éventuellement l’historique des modifications corrections, ses interactions avec d’autres scripts…
Bref toutes les infos qui permettent de cerner rapidement ce qu’il fait dès son ouverture dans l’éditeur.

[php]
//—————————————————————————————-
//– Maboitedeouf – 25/12/2021- Par HG
//– AJAX mises à jour client
//– En entrée : $_POST reçoit les infos
//– 12/01/2022 correction incrémentation lignes histo client
//—————————————————————————————-

if ($_POST[‘mode’]==’modif’){
….mon code
}
[/php]

Explication détaillée du script

Il est parfois utile de mettre une explication détaillée des processus du script. Parfois ils peuvent être complexe et vous serez heureux de retrouver cette explication générale lorsque vous devrez apporter une modification ou une correction.

[code language= »php »]
//—————————————————————————————-
//– Maboitedeouf – 25/12/2021- Par HG
//– Mise à jour CRON des produit à partir du CRM
//– Lancé à 12h et 20h
//—————————————————————————————-
//—————————————————————————————-
//– le script se connecte au serveur ftp pour récupérer le fichier CSV des produits
//– il va ensuite traiter tous les produits du CSV et
//– – activer le produit si besoin
//– – mettre à jour le produit
//– – l’id du produit est stocké dans le tableau $tabprodmaj
//– un rapport de mise à jour est généré dans la base de données
//– la table des produits est alors parcourue pour désactiver les produits
//– qui ne sont pas dans $tabprodmaj et un rapport de désctivation est généré dans la BDD
//—————————————————————————————-

//——– Connexion FTP——————————————————————————-
…
[/code]

Bien séparer les parties distinctes de votre code

Placer des commentaires en début (voire en fin aussi) de chaque partie de votre code permet visuellement de bien appréhender le script dans son ensemble. En commentant avec des lignes de « //—— » ou de « //====== » cela crée une rupture visuelle qui rend presque le code agréable à regarder. Sur de très gros scripts je vous garantis que c’est indispensable !

Commentez vos alternatives et répétitives

Les alternatives et répétitives sont des structures qui gagnent en lisibilité si vous indiquez clairement le sens de chaque cas. N’hésitez pas à le faire même si vous avez bien nommé vos variables ou si les valeurs sont claires.
[code language= »php »]
…
if ($status==35){
//— facture non validée
….
}else if ($status==48){
//— facture validée mais non réglée
….
}else if ($status==56){
//— facture réglée
….
}else{
….
}
…
[/code]

Bien écrire

Bien écrire son code n’est pas aussi simple que cela. Il s’agit en fait d’être constant. C’est en étant constant que votre cerveau aura plus de facilité à relire. Ne changez pas tous les jours votre manière d’écrire une alternative par exemple. Les langages de programmation proposent souvent des écritures simplifiées, condensées ou au contraire beaucoup plus verbeuses. Choisissez votre camp et restez y !

Si vous travaillez en équipe ou dans une entreprise avec plusieurs intervenants sur le code renseignez vous sur les conventions de codage en vigueur. Si vous les respectez vos collègues vous remercieront !

Le nommage des variables

Il existe des conventions de nommage ou d’écriture officielles. Le CamelCase par exemple. Vous pouvez vous y conformer mais le plus important est d’utiliser la même convention partout, tout le temps. En équipe respectez les règles. En freelance, définissez vos règles et respectez les.

Je n’utilise pas le camel case je prefere utiliser le caractère underscore « _ » dans mes variables. Il est trop facile d’oublier une majuscule…

[code language= »php »]
//— Camel Case
$maVariable=’ceci est une variable Camel case’;

//— Variables globales
$g_status_client=$client->get_status_client();

//– Compteurs ponctuels
$nb_tours=50;
$i=0;
for ($i=0; $i < $nb_tours ; $i++) { // code... } //-- l'important est de mettre en place vos propres conventions ! [/code]

Les sauts de lignes et structures

Respectez les indentations ! Un code a une structure et visuellement il est important de pouvoir l’appréhender d’un seul coup d’oeil.
J’utilise personnellement la tabulation pour les indentations et non les espaces.

[code language= »php »]
foreach ($tableau as $id=>$donnee){
if ($donnee[‘genre’]==1){
//code 1
}else{
//code 2
}
}
[/code]

Pour des raisons de lisibilité également je n’utilise pas les notations condensées des alternatives (sans les accolades). Même lorsque le code de l’alternative ne fait qu’une seule ligne je mets les accolades et je saute une ligne. Sauf parfois si il s’agit juste d’une simple affectation de variable. Histoire là aussi de gagner en lisibilité.

[php]
//– codage historique :
if ($toto==’Y’)
{
//mon code
}
else
{
//mon code 2
}

//– je préfère coder ainsi :
if ($toto==’Y’){
//mon code
}else{
//mon code 2
}

if (trim($siret)== »){$siret=’nc’;}
[/php]

Se méfier du copier/coller !

Le copier/coller est un faux ami ! Certes il peut faire gagner du temps. Mais il peut aussi en faire perdre beaucoup !
Vous pouvez l’utiliser pour reprendre des parties de code de vos anciens scripts ou sur le web. Mais surtout ! Assurez-vous de bien tout comprendre ! Vérifiez les noms des variables car c’est la première source d’erreur. Et vous aurez tendance à vous dire « Bon sang ! ça marchait avant ! »… Oui. Mais dans un autre contexte. Donc soyez méthodique si vous utilisez le copier/coller, relisez TOUT plusieurs fois. Car même si votre bout de code fonctionne au premier test rien n’empêche que dans un cas particulier non testé, une boulette ou un oubli pose problème… plus tard… quand le script sera en prod…

Astuces de débuggage

Lors d’un développement on est forcément confronté à des bugs. Et dans ce cas on a besoin d’analyser ce qui se passe… mal.

N’hésitez pas à afficher les contenus de vos variables :

[php]
print_r($ma_variable);
var_dump($ma_variable);
echo ‘ma variable : ‘.$ma_variable;
[/php]
De même pour retrouver une simple faute de frappe dans un code conséquent (et là, le fait de bien structurer votre code visuellement est utile) j’utilise souvent l’astuce de mettre tout le code en commentaire, puis de dé-commenter bloc par bloc en testant à chaque fois. Cela permet de cerner plus facilement la ou les lignes contenant la faute de frappe. Malheureusement souvent un « : » à la place d’un « ; » en ce qui me concerne … snif…

La POO

Mon avis sur ce point sera biaisé. En effet j’ai parfaitement conscience de l’utilité du concept objet et de la POO et c’est incontournable sur de gros projets.

Seulement je vois un énorme incovénient à la POO (en dehors du cadre de gros projets en équipe au sein d’une entreprise) c’est la difficulté à rentrer dans le code si vous n’avez pas une doc bien écrite. Il y a de quoi devenir fou si vous cherchez à corriger un bug sans connaître tous les prototypages, objets, méthodes etc…

Bien entendu sur des projets de grande envergure, la POO a de gros avantages si elle est utilisée au sein d’une équipe organisée, structurée et surtout PILOTEE ! Un projet mal piloté a vite fait de donner naissance à tout un tas de fonctions non documentées qui à terme rendront le code impossible à maintenir.

La programmation procédurale, les fonctions sont très souvent largement suffisantes pour atteindre les objectifs et conserver le projet viable, facile à maintenir et évolutif.

Je sais qu’ici je ne vais pas me faire des copains mais tant pis. La POO c’est bien dans certains cas, ça ne l’est pas dans d’autres c’est mon avis et ça n’engage que moi.

Le mieux est l’ennemi du bien !

Là encore je ne vais peut-être pas me faire des amis.
Je suis un amoureux du code astucieux, élégant, minimaliste et efficace ! Mais parfois mieux vaut un code bateau avec deux boucles qui se suivent et font le taf en 100ms plutôt qu’un code ultra optimisé qui le fera en 10ms… mais sera difficile à relire.

En effet si on se trouve dans le cas d’un traitement ponctuel, lancé par l’utilisateur, la performance est inutile. L’utilisateur ne verra pas la différence entre 100ms et 10ms et le serveur ne s’en trouvera pas surchargé pour autant.

Le code sera bien plus facile à lire si il est bien commenté avec deux boucles qui se suivent plutôt que deux boucles imbriquées par exemple.

Si par contre le traitement est long et est lancé fréquemment, le problème est différent. Vous aurez tout intérêt à optimiser ou même parfois à scinder les traitements.
Mais surtout dans ce cas ce sont les commentaires dans le code qui vous sauveront !
Relisez le paragraphe sur les commentaires 😉 !