Quelques images de la dernière guitare sortie de mon petit atelier !

Voilà quelques photos de ma dernière guitare en date, qui porte le doux nom de Brigitte ! J'en ai perdu quelques unes, donc je ne pourrais pas vous montrer toutes les étapes de fabrication, mais il y a déjà de quoi se faire une idée.

Tête, avec incrustation et cache pour la tige de réglage.

Je travaille en ce moment sur un port d'essence en JavaScript, qui me sert de sandbox pour mieux comprendre la programmation fonctionnelle. Comme pour la librairie originale, je voulais conserver la possibilité de tout configurer par injection de dépendances.

La première idée qui m'est venue est d'utiliser des factory functions, de cette manière :

function fetchUserFactory(fetch) {
  return function fetchUser(id) {
    return fetch('http://example.com/api/users/' + id);
  };
}

Depuis le début de l'histoire de la French Tech, j'avais comme un sentiment de truc pas net... Jusque là, je ne comprenais toujours pas ce qui me dérangeais tant, à part bien sûr tout ce franglais que je trouve assez étrange d'utiliser de la part d'un État, qui, aux dernières nouvelles, est juste français. (Je passerais là-dessus, étant donné qu'en tant que développeur, je passe mon temps à utiliser des termes anglais au milieu de mes phrases...)

Bref, c'est en lisant l'article de présentation de la French Tech que j'ai compris le hic. Je vous recommande vraiment de le lire en essayant de comprendre le but de l'opération. Qu'est-ce que la French Tech ? À quoi ça sert ? Qu'est-ce qu'on va bien pouvoir en tirer ? Qui va en profiter ?

Beaucoup de développeurs suivent des conventions de codage pour développer leurs applications. Elles sont bien sûr importantes, voire indispensables notamment pour un travail en équipe, mais elles ne sont finalement que des considérations esthétiques.

Tout le monde connait ces interminables débats sur comment nommer ses fichiers, ses objets, ses méthodes ou variables, et beaucoup d'entre nous aiment tailler le bout de gras histoire de bien prouver qu'ils ont raison, moi y compris... Pourtant, peu importe le style, rien de tout cela ne permet de certifier qu'un code sera intelligent et efficace.

Je vous propose donc quelques unes de mes guidelines.

Il est courant qu'une fonction puisse retourner une valeur par défaut.

Par exemple, imaginez une méthode qui fouille dans les données d'un objet pour retourner une partie de ces données. Si cette méthode ne trouve pas ce qu'elle cherche, on choisira en général entre 2 options : lancer une exception ou retourner une valeur par défaut.

Le traitement d'exception pouvant se révéler un peu lourd à gérer, particulièrement sur des méthodes souvent utilisées, on préférera la plupart du temps retourner une valeur par défaut.

class Collection {

	protected $_data = array( );

	public function getData( $key ) {
		if ( isset( $this->_data[ $key ])) {
			return $this->_data[ $key ];
		}
		return false;
	}
}

Il y a fort longtemps, vous avez codé une classe une peu pourrie (si, si, on l'a tous fait), qui était capable de dire quelque chose. La voici :

class VieilleClassePourrie {

	public function direQuelqueChose( ) {
		echo 'quelque chose';
	}
}

Mais voilà, vous aimeriez bien dire autre chose maintenant... Motivé, vous décidez d'écrire une nouvelle classe qui déchire tout, que vous pourrez utiliser dans vos nouveaux projets qui déchirent tout. La voilà :

class NouvelleClasseQuiTue {

	public function dire( $phrase ) {
		echo $phrase;
	}
}

Mille fois mieux pensée, cette classe permet de dire tout et n'importe quoi !

Et là, c'est le drame. Vous devez désormais maintenir deux versions de cette classe, pour vos anciens et vos nouveaux projets.

Si vous perdez le contrôle sur votre outil de travail, vous perdez le contrôle sur la qualité de votre produit. Imaginez un marteau qui vous glisse des mains, vous risquez fort de rater le clou, ou pire, de vous écraser méchamment les doigts.

La programmation demande une rigueur extrême et une attention constante.

Une fois introduit un morceau de code un peu hasardeux, trop spécialisé ou mal pensé pour être maintenu correctement, les ennuis commencent. A un moment ou à un autre, vous aurez à modifier ce code, à y faire des corrections ou des ajouts de fonctionnalités, et si il n'est pas naturellement intégré au reste de votre application, vous allez devoir ruser pour l'utiliser comme vous l'entendez.

Alors quelles solutions à ce problème ?

C'est le moment de relancer l'éternel débat sur l'indentation ! Je ne vais pas vous rappeler combien il est important d'indenter correctement son code, je pense que vous le savez déjà.

Je voudrais plutôt aborder la question de comment indenter. Là, on se retrouve entre 2 camps : ceux qui utilisent des espaces, et ceux qui préfèrent les tabulations. Pour ne rien vous cacher, j'ai un énorme parti pris pour les tabulations, et je m'en va vous dire pourquoi...

Entre les contrôleurs et les vues, il est parfois un peu difficile, voire pénible, de maintenir les différents liens de vos applications. Si ils sont tous codés "en dur", ils chargent le code inutilement et doivent être modifiés un par un si une règle de routage est changée.

Pour mieux s'y retrouver, je vous propose une petite astuce qui vous fera sûrement gagner du temps, et vous évidera bien des emmerdements.