Quelques bonnes pratiques à utiliser dans votre code !

Arrière plan avec du code, logo pouce levé en premier plan

Pour commencer, le fait d’écrire un code source lisible est une des bonnes pratiques que tout bon développeur doit savoir faire. Je ne vais pas tout détailler ici car il y a déjà un article sur ça. Sachez juste qu’avoir un code source propre est facilement lisible a beaucoup d’avantages, même si cela demande un peu plus de réflexion. Il en existe d’autres, pas forcément obligatoires, mais qui permettent d’éviter quelques erreurs ! c’est parti !

Les accolades facultatives

Sur la plupart des langages, les accolades sont optionnelles sur certaines instructions quand il n’y a qu’une seule ligne comme dans if, while ou for. Pour faire un peu de place, il est tentant de supprimer les accolades :

	if(condition)
		jefaituntruc();

Mais admettons qu’à un moment donné, vous rajoutez une ligne supplémentaire dans la condition, ça donne ça :

	if(condition)
		jefaituntruc();
		jefaitunautretruc();

Oops, j’ai oublié d’ajouter des accolades, quel étourdi que je suis ! Évidemment, c’est une erreur qui arrive quand on est pas suffisamment attentif, mais le simple fait de ne pas mettre d’accolade peut être une source d’erreur pour plus tard. Alors autant nous assurer qu’il n’y en aura jamais en mettant systématiquement des accolades ! Et pour vous dire honnêtement, je fais tout le temps l’erreur d’oublier les accolades, donc je les mets tout le temps !

	if(condition){
		jefaituntruc();
	}

Alors au final, les accolades ne sont pas si facultatives que ça, car les erreurs que ça peut induire, elles, ne le sont pas !

Le passage de paramètres nommés

Passer des paramètres dans une fonction se fait en général par position. L’ordre dans lequel ils ont été définis dans une fonction influe sur quelle position envoyer un paramètre. Si une variable taille est déclarée en première position alors il faut lui envoyer une valeur en respectant cette position lors de l’appel :

	CalculImc(174,70);

Mais que se passe-t-il si par mégarde, j’intervertis les deux chiffres (juste parce que je ne fais pas attention, hein), et bien catastrophe ! La fonction ne marche pas comme prévu ! Par contre si je prends le soin de nommer les paramètres de la fonction :

	CalculImc(taille=174,poids=70);
	CalculImc(poids=70,taille=174);

Plus de problèmes d’étourderies et le code source gagne en lisibilité en prime !

Nommer les arguments permet de corriger des sources potentielles d’erreurs, car l’ordre des paramètres n’est plus pris en compte. Par contre, peu de langages donnent la possibilité de le faire. Le JAVA, le PHP ou le C++ par exemple ne le permet pas comparé au C# ou à l’objective C.

Éviter les duplications

Bon, les 2 premiers faisaient partie des bonnes pratiques qui permettent d’éviter de petites erreurs d’inattention, celui-là est beaucoup plus important. La duplication de code, alias ctrl-c/ctrl-v, alourdit considérablement la lisibilité, la maintenance et la performance d’un code source.

	echo '<li> Liste 1 </li>';
	echo '<li> Liste 2 </li>';
	echo '<li> Liste 3 </li>';
	echo '<li> Liste 4 </li>';
	echo '<li> Liste 5 </li>';

Mieux vaut faire ça :

	afficherListe(5);
	
	function afficherListe($elements){
		for($i = 0;$i < $elements;$i++){
			echo '<li> Liste ' . ($i+1) . ' </li>';
		}
	}

Alors oui, il faut écrire une fonction supplémentaire. Mais que se passe-t-il si je veux effectuer une modification sur les éléments de la liste du style changer « Liste » en « Élément » ? Dans le premier exemple je change les 5 lignes, dans le deuxième seulement qu’une ! Et je ne parle même pas des cas où il y a plus de 10 répétitions !

De plus, si je veux rajouter des éléments supplémentaires, je n’ai juste qu’à changer le paramètre, simple et rapide ! Si vous avez la possibilité de simplifier votre code en repérant et en supprimant les duplications, prenez le temps de le faire, mais faites-le ! Le temps que vous « perdez » à faire les choses propres sera du temps gagné lors de la maintenance et dans la résolution de problèmes !

Il y a un autre soucis que les duplications causent, c’est lorsque vous copier et coller un morceau de code dans une autre partie du programme dont le code n’est pas adapté pour ça. Ce problème est le fameux anti-pattern copier/coller 😎 à éviter au maximum, si vous avez la possibilité d’utiliser l’extraction de méthode, préférez le aux copier-coller ou mieux, utilisez une fonction et évitez les duplications !

	function afficherListe($elements){
		for($i = 0;$i < $elements;$i++){
			echo '<li> Liste ' . ($i+1) . ' </li>';
		}
	}
	
	
	function afficherLienListe($liens){
		for($i = 0;$i < $elements;$i++){
			echo '<li><a> Liste ' . ($i+1) . ' </a></li>';
		}
	}

Ici, on voit bien que j’ai fait que la fonction afficherLienListe n’est qu’un bête copier-coller de afficherListe. Mais je l’ai fait sans modifier la variable $éléments de la boucle, ça va poser un petit souci :-(.

Vous me direz, c’est encore une erreur d’inattention ! Mais en y pensant, c’est ce qui représente la plupart des erreurs en programmation. Et en plus, je fais une répétition de code avec la boucle ! Un code qui évite les répétitions ressemblerait plutôt à ça :

	function afficherListe($elements){
			echo construireListe($elements);
	}
	
	function afficherLienListe($elements){
		$liste = construireListe($elements);
		$recherche = array('<li>','</li>');
		$remplace = array ('<li><a>','</a></li>');
		
		// Ajout de balises <a> dans les éléments de la liste
		$liste = str_replace($recherche, $remplace, $liste);
		
		echo $liste;
		
	}

	function construireListe($elements){
		$liste = '';
	
		for($i = 0;$i < $elements;$i++){
			$liste .= '<li> Liste ' . ($i+1) . ' </li>';
		}
		
		return $liste;
	}

Nettement plus complexe, mais cela fait partie des bonnes pratiques à mettre en place 🙂

Les optimisations à tout va !

Ça part sur un bon principe, vouloir un code qui soit hyper performant. Mais le problème c’est qu’optimiser un logiciel qui ne fonctionne pas est un petit peu inutile. Le code doit être à 100% fonctionnel, propre et lisible avant de penser à d’éventuelle optimisation. L’optimisation qui vise à gagner 0.001 seconde de performances contre 3h de travail est à éviter.

Attention, il ne faut pas non plus que ça soit une excuse pour écrire quelque chose de lourd. Si une fonction utilise un algorithme pour un traitement avec une complexité de O(n²) et qu’il est possible de faire mieux avec un O(n), il faut utiliser le plus performant, même s’il est plus compliqué à implémenter. C’est délicat, il faut savoir peser le pour et le contre lors de l’écriture d’un code optimisé. Cela doit être pensé avant même la conception du programme. Repérez les traitements lourds et réfléchissez sur le code qui serait le plus adapté.

L’erreur en fait c’est de perdre du temps et de la clarté dans le code source pour quelque chose qui ne vaut pas vraiment le coup. Un exemple flagrant d’une mauvaise optimisation est de changer le langage de programmation alors même que le projet n’est pas terminé, juste pour grappiller quelques secondes de performances. Le gain est insignifiant comparé au temps que cela prendrait.

First make it work, then make it right

Encapsulation des données

Principe fondamental de la programmation orienté objet, chaque objet doit avoir ses données et ses méthodes bien à lui. Le fonctionnement d’une classe n’intéresse absolument pas les autres classes ni les utilisateurs d’ailleurs. De plus, tous les attributs d’une classe doivent être privés ou protégés. Elles doivent fournir des méthodes spéciales qu’on appelle des accesseurs, et qui permettent justement d’accéder à ces attributs.

L’erreur à ne pas commettre est d’avoir des variables accessibles un peu partout dans le code, surtout si elles peuvent changer le comportement d’un objet. Et non, même si c’est un pattern, le Singleton ne remplace pas les variables globales.

Conclusion

  • Mettez les accolades même si c’est optionnel
  • Nommé les arguments lorsque vous appelez une fonction ou une méthode si possible
  • Évitez la répétition dans votre code et le copier-coller en général.
  • N’optimisez pas votre code d’emblée ! Faites quelque chose qui marche et qui soit propre dans un premier temps
  • Faites attention à la portée des attributs, le fonctionnement interne d’une classe doit être masqué.
  • Lors d’un développement, testez votre code régulièrement, avancez à petits pas, mais avancez surement !
  • Pensez module ! Pour chaque nouvelle fonctionnalité que vous faites, faites des fonctions qui fonctionnent en totale indépendance par rapport à son environnement !
  • Ayez un code source lisible !
  • La lisibilité du code source prime sur les autres règles ! Si vous appliquez une des bonnes pratiques au détriment de la lisibilité, ne le faites pas !

Avec ces bonnes pratiques, vous voilà paré pour faire du code de qualité !

A++ 🙂

Partager l’article :
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.