Les petites manies…

J’ai quelques petites manies en Typescript qui ont évoluées avec le temps, mais semblent plutôt bien installées maintenant. Je ne sais pas s’il s’agit réellement de bonnes pratiques, mais chaque codeur a les siennes…

Un code en anglais

Tout mon code, mes commentaires, mes logs sont en anglais.

Un codeur passe quand-même un certain temps sur les docs et les forums pour résoudre certain problèmes, se documenter, progresser… et il faut bien avouer que l’anglais est la langue reine sur Internet.
Je pense que je parle presque couramment anglais uniquement grâce à mes années passées sur les forums et blogs en quête d’une réponse, d’une bonne pratique ou d’une nouvelle techno intéressante…

Et quand on a du code à partager, autant qu’il soit lisible pour tout le monde (voir le paragraphe sur les noms de variables plus bas)… et donc si vous voulez une réponse sur StackOverflow, autant qu’il y ait le plus de gens possible capables de comprendre la question…

Après tout comment savez-vous que vous n’êtes pas en train de coder le prochain projet OpenSource qui va vous rendre « célèbre mais humble »/ »millionaire mais misanthrope »/ »le nouveau Linus Torvald »/etc… ?
Autant s’éviter un lourd travail de traduction au moment de le mettre sur GitHub 😋

Accro au typage

Le typage de Typescript est à mon avis implémenté de manière très élégante et amélioré à chaque nouvelle version. C’est presque en langage à lui tout seul!
Le but du typage fort, c’est de savoir à n’importe quel endroit du code à quelles données on a à faire… mais là c’est un sujet qui ne peut pas se traiter en un point. Je ferai un autre article uniquement dédié à cet aspect du code.

Si des fois sur un bout de script court, ou script de test, je cède à la tentation du as any, je compile toujours en mode strict. L’inférence, sacrément au point quand-même, permet d’alléger le code sans rien concéder à la rigueur du développement.
A moins d’un mauvais typage d’une librairie codée en Javascript (souvent via @types/<package>), compiler en mode strict n’est pas si contraignant que çà (et sauve des vies! Si, si, la santé mentale lors d’un refactoring c’est fragile…)

Nom de variable > commentaire

Si les commentaires sont essentiels au travail en équipe, quand on est solo sur son code on brode moins. Mais cela n’empêche pas qu’il est important d’avoir d’un code clair, ne serait-ce que pour pouvoir revenir dessus après plusieurs mois/années ou le transmettre (dans ce dernier cas, une bonne code review avec ajout de commentaires est la moindre des politesses).

Pour un code lisible, j’utilise beaucoup:
– les lignes vides pour séparer les différentes étapes de mes algos
– des noms de variables bien explicites: je préférerai par exemple un userCanReadPost à juste canRead (ou pire r – je ne juge pas, j’ai déjà fait 😅). Au bout d’un certain temps passé à coder, on maitrise son clavier et ce n’est pas quelques caractères en plus qui vont nous ralentir…

DRY: Les valeurs dans des variables

« Don’t repeat yourself ». Là, on n’est pas dans la petite manie, mais dans la bonne pratique de base. Si on ne devait en retenir qu’une seule, à mon sens ca devrait être celle-ci…

Une des applications de ce DRY, c’est de ne jamais utiliser une valeur directement dans votre code. Vous ne savez jamais quand vous aurez besoin de la réutiliser, et ca peut vous mener à un vieux copier-coller, puis à une erreur quand cette valeur va devoir changer…
Donc quand on voit une chaîne de caractères ou un nombre dans un code, c’est souvent (des exceptions existent) qu’on va au devant d’un problème, théorique mais qui peut devenir bien concret!

Donc, on met ces valeurs soit dans un paramètre pour une fonctions, soit dans une propriété statique pour une classe, soit dans une constante pour un script classique…

Dans le code suivant, un calcul classique de prix HT -> TTC et vice-versa. Dans le deuxième cas, on peut utiliser une TVA différente (il y a 4 taux de TVA en France, et le code devient compatible avec tous les pays)… tout en gardant la possibilité de ne pas transmettre la TVA grâce à la constante…

// PAS BIEN !!! :-(
function exclTaxToIncl(price: number) {
	return price * 1.2;
}

function inclTaxToExcl(price: number) {
	return price / 1.2;
}

// BIEN !!! :-D
const VAT = 20;

function exclTaxToIncl(price: number, percentVAT: number = VAT) {
	return price * ((100 + percentVAT) / 100);
}

function inclTaxToExcl(price: number, percentVAT: number = VAT) {
	return price / ((100 + percentVAT) / 100);
}

export default

Je n’utilise que très rarement export default… en effet, je préfère largement avoir à écrire les accolades lors de l’import. Et chose toute bête, quand on décide de changer de nom de classe/function/variables, tout se propage avec VSCode!

Les namespaces pour organiser

J’aime les noms de classes courts pour tout ce qui est « data » (mes composants React ont des noms de 3km par contre 😅), mais sans que cela enlève à la pertinence de leur nom. Pour çà, j’utilise à outrance les namespaces:

export type Article = {
	id:number;

	name:string;
	price:number;

	status: Article.Status;
}

export namespace Article {
	export enum Status {
		ACTIVE = 'article/active',
		ENDED = 'article/ended',
		DELETED = 'article/deleted',
	}
}

A suivre…

Voilà, voilà pour l’instant…
Ce type d’article est certainement voué à revenir avec d’autres chapitres…
Et vous, c’est quoi vos manies en code, je suis prêt à adopter… 😉

Laisser un commentaire

Votre adresse e-mail 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.