J’aurais évité autant que possible il y a 15 ans, aujourd’hui je suis amoureux des import
explicites en début de fichier, sans aucun symbole externe qui ne soit importé explicitement. Pas de symbole chargé ou défini dans un autre fichier magiquement accessible ailleurs, pas même d’import *
. Si je m’écoutais en ce moment je voudrais même importer les types de base du langage.
Mon historique PHP et Ruby m’ont longtemps fait voir l’absence de tout ça comme un avantage. Ça n’est vrai qu’avec de très bon IDE. En pratique ça ne permet pas de savoir où est défini le symbole, s’il existe vraiment, ni de gérer correctement les conflits de noms et surcharges locales.
Il y a souvent tellement peu de modules, classes et fonctions externes différentes dans un fichier bien structuré que l’explicite apporte bien plus de bénéfices que de pénibilité. Si on dépasse la dizaine c’est le symptôme que quelque chose ne va pas par ailleurs
Côté syntaxe j’apprécie celle de Python qui montre ce qui est important systématiquement en fin de ligne.
from xxx import A, B, C as D
Les imports Javascript sont pratiques mais la partie la plus significative se retrouve en milieu de ligne, pas toujours là où c’est visuellement le plus identifiable (sans compter la dualité entre import A
et import { A }
)
Soyons fous, on pourrait même importer les objets de base du langage avec un import { String, Integer, Array } from StdLib
. On n’en utilise pas plus d’une poignée dans un même fichier. Point bonus si ça permet que "hello"
, 42
, ou [1, 2, 3]
soient des raccourcis de syntaxe vers les classes ainsi déclarées en haut de fichier et n’utilisent pas forcément les classes natives du langage.
import { String, Integer } from Stdlib
import { MyArray as Array } from MaLibPerso
import { MACONSTANTE, MaClasse } from MonAutreLibPerso
Quitte à faire une liste de course, pourrait-on faire que les imports avec un chemin absolu « /dir/sub/fichier » référencent la racine du projet et pas la racine du système de fichier ?
Laisser un commentaire