PC & Mobile

Écrire du code lisible et maintenable dans TypeScript.

Écrire du code lisible et maintenable dans TypeScript.


Vous pourriez dire que l'écriture du code dans le deuxième exemple prendrait plus de temps que dans le premier. C’est probablement vrai. Cependant, vous gagnerez du temps en rendant la fonction plus facile à utiliser.

Vous n’êtes pas obligé de regarder cette fonction parce que vous savez ce qu’elle fera. Les saisies faciliteront l’utilisation de cette fonction car Intellisense de votre IDE vous expliquera comment l’utiliser. Vous pouvez également localiser plus facilement les bogues car il est beaucoup plus facile de lire le code, ce qui vous permet de le comprendre plus rapidement et plus en profondeur.

La fonction tableau de blocs peut être un exemple trivial, mais pour un code plus complexe, la même logique s'appliquera.

5 astuces pour améliorer votre code et celui de votre équipe

Je vais partager certaines des choses que j'ai apprises en travaillant sur des projets TypeScript au sein d'une équipe. Ce sont toutes des choses qui, selon mon expérience, ont facilité la lecture et la maintenance de notre code. Cela a également réduit le temps nécessaire aux nouveaux membres de l'équipe pour devenir productifs, car ils pouvaient rapidement comprendre le code.

N'écrivez pas de code pour vous-même, écrivez du code pour les autres.

Ce que j’essaie de dire, c’est que vous devez toujours considérer que d’autres personnes liront votre code. Ce ne sera peut-être pas aujourd'hui ni même la semaine prochaine, mais cela se produira.

1. Vous rendre tsconfig aussi strict que possible

C’est probablement le conseil le plus important que je vais vous donner dans cet article. Laissez TypeScript faire ce qu’il est censé faire, c’est fait pour éviter les erreurs humaines. La meilleure façon de procéder consiste à activer les options TypeScript qui vous obligeront à respecter certaines règles.

Ne vous contentez pas d'activer toutes les fonctionnalités TypeScript, réfléchissez bien aux options qui pourraient améliorer votre équipe. Dans certaines situations, l'activation de certaines fonctionnalités peut s'avérer contre-productive.

Options strictes

Il y a quelques options strictes dans TypeScript que je vous recommande fortement d'utiliser:

--noImplicitAny
Génère une erreur sur les expressions et les déclarations avec un type quelconque.
--noImplicitThis
Raise error sur les expressions “this” avec un type implicite quelconque.
- toujoursStrict
Analyser en mode strict et émettre «utiliser strict» pour chaque fichier source.
--strictNullChecks
En mode de contrôle null strict, les valeurs null et indéfinie ne sont pas dans le domaine de tous les types et ne peuvent être assignées qu’à elles-mêmes et à n’importe laquelle (la seule exception étant que indéfini est également assignable à void).
--strictFunctionTypes
Désactiver la vérification des paramètres bivariants pour les types de fonction.

J'appelle ces options strictes car elles sont toutes définies lorsque vous utilisez le --strict drapeau. Quelques options supplémentaires pourraient être définies, mais elles peuvent être gênantes à utiliser selon le framework que vous utilisez.

Par exemple, en utilisant --strictPropertyInitialization avec des affrontements angulaires un peu avec le @Contribution, @Sortie et @ViewChild (ren) décorateurs.

Options non strictes

Il y a beaucoup plus d'options disponibles qui améliorent la qualité du code, et je vous suggère fortement de jeter un coup d'œil. Vous pouvez trouver toutes les options disponibles dans le manuel TypeScript: https://www.typescriptlang.org/docs/handbook/compiler-options.html

2. Privilégier la lisibilité par rapport aux performances

Noms de variables et de fonctions

Ne soyez pas ce type qui utilise toujours des variables à une lettre. Bien sûr, vous pourriez économiser quelques millisecondes. Quelques lignes même. Mais tout cela se fait au détriment de votre lisibilité.

Posez-vous toujours la question suivante: «Quelqu'un comprendra-t-il ce code la première fois qu'il le lira? Si la réponse est oui, vous vous donnez une tape dans le dos. Si la réponse est non, pensez à un bon nom qui explique clairement le but de cette variable. Cela peut vraiment rendre votre code plus facile à comprendre.

Il en va de même pour les noms de vos fonctions. Si vous voyez le nom d’une fonction, ses paramètres et la classe à laquelle elle appartient, vous devez savoir ce que fait la fonction. Sinon, il n’a pas de nom propre.

Performance

Tout dépend du type de projet sur lequel vous travaillez, mais dans la plupart des cas, il ne vaut pas la peine de gagner une milliseconde si cela rend votre code encore plus difficile à comprendre. Un code difficile à comprendre peut facilement causer des bugs.

Concentrez-vous d'abord sur l'exactitude, puis sur la clarté et enfin, si nécessaire, sur les performances.

Si vous avez besoin de la performance, assurez-vous d'utiliser le nom approprié et d'ajouter des commentaires de clarification. Vous éviterez ainsi que vos coéquipiers perdent leur temps à essayer de comprendre votre code complexe.

3. Linting

Si vous n'appliquez pas de style de code, tout le monde codera comme il le souhaite. Certains utiliseront des virgules de fin, d'autres 4, des préfixes, d'autres préfixeront leurs variables privées d'un trait de soulignement… En bref, chaque fichier sera différent.

Avec des outils tels que TSLint et / ou Prettier, vous pouvez définir des règles pour l’apparence du code. Essayez de rendre vos peluches aussi strictes que possible. Bien sûr, cela peut être gênant si vous oubliez une virgule ou un point-virgule, mais il sera plus facile de lire le code des autres peuples car vous saurez à quoi vous attendre.

4. Structure du projet

Une autre chose qui peut prendre beaucoup de temps est d’avoir une structure de projet qui n’a pas de sens. Cela peut être vraiment ennuyeux lorsque vous essayez de résoudre un bogue, mais vous ne pouvez pas trouver le fichier qui gère cette logique spécifique.

Je ne peux pas vous suggérer de structure de projet. Ce que je peux suggérer, c'est que vous réfléchissiez avant de commencer à créer des dossiers et des fichiers de manière aléatoire. Peut-être même asseyez-vous avec votre équipe et essayez de créer une structure de projet où tout le monde pourra trouver ce qu’ils cherchent. Sinon, qui sait avec quoi vous allez vous retrouver?

5. Programmation en binôme

Parfois, lorsque vous résolvez des problèmes complexes, il peut être utile de le faire en binôme. Travailler en couple présente plusieurs avantages par rapport au travail en solitaire. La première est que non pas une mais deux personnes comprendront ce problème complexe. Le deuxième avantage est que quatre yeux détecteront les insectes plus rapidement que deux yeux.

L'autre personne pourrait aussi avoir une solution différente en tête. En combinant vos solutions, vous obtiendrez peut-être une solution encore meilleure que celle que vous auriez proposée si vous travailliez seul.

Cependant, ne travaillez pas toujours en couple. Vous devez également pouvoir programmer indépendamment. Vous ne pouvez pas toujours compter sur quelqu'un d'autre.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

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

Close
Close