La qualité du code est actuellement LE sujet dans le monde du dev (et avec raison !). Si vous êtes développeur.se pro et passionné.e, vous n’êtes sans doute pas passé à coté !

Donc, si le TDD est votre religion, que vos tests unitaires sont nickels et couvrent 100% du code, qu’Xcode ne retourne plus un seul warning, et que Sonarqube est devenu votre meilleur ami… Et bien vous pouvez encore vous améliorer, grâce à SwiftLint !

Si Sonarqube fera l’objet d’un autre article de blog, je vais aujourd’hui vous parler de SwiftLint.

SwiftLint, c’est un outil créée et maintenu par Realm pour améliorer le respect des conventions d’écritures en Swift, disponible ici : https://github.com/realm/SwiftLint

Comme souvent, il y a plusieurs manières de l’intégrer dans un projet, personnellement, j’aime bien Cocoapods !

Comme code d’exemple, je vais reprendre la démo « InfoKayak », mise à jour pour Swift 5.

Sans SwiftLint, Xcode 11.3 ne trouve rien à redire au code (pas de warning, pas d’erreur) :

Editez maintenant le fichier Podfile en y ajoutant la ligne :  » pod ‘SwiftLint’  » :

Mettez à jour et installer les pods, puis rouvrez le projet avec Xcode. Pour le moment, il n’y a pas de changements 🙂

En fait, pour activer SwiftLint, il faut un petit script. Dans les « Build Phases » du projet, cliquez sur le « + » , ajoutez une « New run script phase », et mettez-y ce script :

On Build et Oh ! 286 warnings et 22 erreurs 😦 WTF ?

Allez, avant de faire un burn out, une bonne nouvelle, SwiftLint est capable de corriger automatiquement une grosse partie de ces problèmes 🙂 .

Pour cela, depuis un terminal, mettez vous dans le dossier de votre projet, et exécutez la commande « ./Pods/SwiftLint/swiftlint autocorrect« .

Ensuite, effacez le dossier de build d’Xcode, et au besoin, relancez l’IDE. Normalement, la situation devrait s’être grandement améliorée : il n’y a plus que 2 erreurs et 5 warnings à corriger manuellement, chose que je fais immédiatement… 😉

Dans certaines situations, on ne peux pas corriger (cas de librairie externes lesquelles nous n’avons pas la main…), il est donc possible de paramétrer SwiftLint plus finement.

Pour tout ce qui est règles globales, il faut créer un fichier .swiftlint à la racine de votre projet. Par exemple, le mien contient ceci :

Lorsqu’il s’agit d’un besoin temporaire, on peut désactiver une règle directement dans le code avec l’instruction // swiftlint:disable <rule> . La liste des règles se trouve ici : https://realm.github.io/SwiftLint/rule-directory.html

Voilà, j’espère que cette petite introduction vous aura donné envie de vous mettre à Swiftlint et à vous mettre à la qualité ! En tous cas moi, je suis accro !