En introduction de ce cours, je vous ai dit que vous alliez apprendre à être autonome et à rédiger du code propre. Vous savez maintenant résoudre tous les types de bugs que vous pouvez rencontrer, ce qui vous fait beaucoup gagner en autonomie !
Ici, nous allons commencer à parler de la propreté de votre code, un sujet au moins aussi important !
Gare à votre style
En programmation, chacun a son style. On a tous notre propre façon d'écrire du code. Par exemple, les deux codes suivants sont équivalents techniquement, mais très différents pourtant :
Cette différence de style (on parle aussi de syntaxe) n'est pas sans conséquence ! Si les deux styles ci-dessus cohabitent dans un même projet, le projet va avancer beaucoup moins vite !
Je ne vois pas pourquoi, tant que le code marche, c'est bon non ?
Hé non ! 80% de l'activité d'un développeur, c'est de lire du code pour dénicher des bugs, analyser un problème ou préparer le code qu'il va produire. Ce n'est pas une activité si aisée pour le cerveau, alors si en plus vous lui imposer de lire des choses qui ne se ressemblent pas du tout, ne comptez pas sur lui pour progresser et aller plus vite !
D'autre part, si vous êtes en équipe et que chacun a son style, cela pose déjà une question sur la cohésion de l'équipe, mais surtout cela finit vite en guerre de style où chacun essaye d'imposer sa syntaxe sur le code d'autrui et au final tout le monde perd du temps.
Un code uniforme, c'est donc la base d'un projet sain !
Un guide syntaxique
Pour résoudre ce problème, il faut décider de la syntaxe que l'on va adopter. Et comme cela représente un très gros travail, en général, on choisit un guide syntaxique (ou style guide) parmi ceux disponibles sur internet.
En Swift, il en existe deux particulièrement populaires :
Ray Wenderlich Swift StyleGuide : le plus complet et le plus populaire.
Github Swift StyleGuide : très populaire et utilisé dans SwiftLint dont on parlera dans une minute.
Ces guides détaillent une syntaxe à suivre, qui privilégie la lisibilité du code. Cela va du nombre de lignes à sauter entre chaque méthode, à la façon de nommer les variables en passant par la bonne manière de déballer un optionnel.
Découvrez SwiftLint
Une fois que vous avez choisi et lu un guide, vous n'avez qu'une hâte, c'est d'appliquer toutes les conventions pour que votre code soit magnifique ! Mais vous êtes humains et vous risquez de ne pas tout retenir ou de faire des fautes.
Pour pallier à ce problème, il existe un outil que l'on appelle lint. Cet outil se base sur les guides syntaxiques et lit votre code pour vérifier automatiquement qu'il est conforme ! Il saura dénicher le moindre espace de trop ! On dit qu'il fait l'analyse statique de votre code.
Le plus connu en Swift s'appelle SwiftLint. Vous pouvez le retrouver à cette adresse.
Installez SwiftLint
Allons-y, installons SwiftLint ! Pour cela, il suffit de suivre les instructions données à cette adresse.
Installez HomeBrew
Il existe plusieurs façons de l'installer. Je vous propose de choisir la première qui utilise HomeBrew. HomeBrew est un gestionnaire de paquets pour Mac. Son rôle est d'installer et mettre à jour des petits programmes comme SwiftLint.
Pour l'installer, il vous suffit d'aller sur le site de présentation de HomeBrew. Les instructions sont très simples, il suffit de copier la commande suivante dans votre terminal :
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Et c'est tout, HomeBrew est installé !
Installez SwiftLint sur votre Mac
Maintenant, nous pouvons installer SwiftLint. En restant dans le terminal, il vous suffit d'entrer la commande suivante :
brew install swiftlint
Et voilà ! SwiftLint est installé sur votre Mac !
Ajoutez SwiftLint dans votre projet
Il ne nous reste plus qu'une petite étape, rajouter SwiftLint dans notre projet d'application. Ainsi, SwiftLint va pouvoir lire le code contenu dans notre projet pour y signaler des irrégularités de style.
Vous vous souvenez, il y a deux étapes en Swift : la compilation et l'exécution. C'est à l'étape de compilation que le code est interprété et traduit dans un autre code exécutable par la machine.
Notre objectif ici va être de rajouter une séquence à la compilation : l'analyse statique de SwiftLint. Pour rajouter cette séquence à la compilation (on parle parfois de build), on va suivre 5 étapes :
Sélectionnez le projet dans le navigateur.
Sélectionnez la target.
Sélectionnez l'onglet build phases.
Appuyez sur plus.
Choisissez New Run Script Phase.
Vous pouvez retrouver toutes ces étapes dans l'illustration ci-dessous :
Une fois cela effectué, notre nouvelle séquence à la compilation (ou phase du build) est créée.
Nous allons maintenant la modifier pour qu'elle utilise SwiftLint. Pour cela, il suffit de copier le script suivant à l'endroit prévu à cet effet :
if which swiftlint >/dev/null; then
swiftlint
else
echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fiA la fin, la phase doit ressembler à ceci :
Ça y est ! SwiftLint est prêt à l'emploi ! Bravo !
Utilisez SwiftLint
Nous avons installé SwiftLint comme la dernière étape de la compilation de notre code, donc pour qu'il fonctionne, il nous faut compiler le code. Pour cela, nous avons deux options :
Lancer le programme avec le gros bouton play en haut à gauche ou le raccourci cmd + r. Cela va lancer la compilation (build) puis l'exécution (run).
Lancer seulement la compilation (build) avec le raccourci cmd + b.
Le deuxième choix suffit donc je vous invite à essayer ! SwiftLint s'exécute et génère une vingtaine d'erreurs (18 dans mon cas). La bonne nouvelle, c'est que ce sont souvent des erreurs faciles à résoudre. Les trois plus courantes sont :
line_length : une ligne trop longue, SwiftLint incite à faire des lignes de moins de 120 caractères pour qu'elles tiennent à l'écran.
vertical_whitespace : trop de sauts de lignes entre deux lignes de code.
trailing_whitespace : une ligne vide qui contient des espaces : il faut supprimer les espaces inutiles.
Ces erreurs sont simples donc je vous laisse les résoudre tout seul. Mais il y en a une un peu plus sophistiquée qui a attiré mon attention :
For Where Violation: `where` clauses are preferred over a single `if` inside a `for`. (for_where)
Cette erreur intervient pour le code suivant dans Match.swift :
private func getWinner() -> Player? {
for (player, score) in scores {
if score == Match.maxNumberOfWonSets {
return player
}
}
return nil
}Dans ce code, on a une boucle for qui itère sur un dictionnaire, et cette boucle for contient un unique if. Dans ce cas courant, il existe un mot clé qui permet de condenser les deux lignes en une seule : le mot clé where. Il s'utilise comme ceci :
private func getWinner() -> Player? {
for (player, score) in scores where score == Match.maxNumberOfWonSets {
return player
}
return nil
}Grâce à cette analyse de SwiftLint, notre code est plus concis, plus clair et nous avons découvert la clause where. C'est un exemple qui illustre bien la puissance de la relecture syntaxique !
Quelques remarques
Avant de passer à la suite, je me permets trois petites remarques :
Niveaux d'erreurs
SwiftLint utilise les deux niveaux d'erreurs d'Xcode :
les warnings qui n'empêchent pas le lancement de l'app
les erreurs rouges qui empêchent le lancement de l'app
Par exemple, si une ligne est trop longue et qu'elle dépasse 120 caractères, on va avoir un warning. Mais si elle dépasse 200, là c'est vraiment exagéré et on obtient une erreur rouge.
Build time vs Run time
Si vous allez dans le navigateur des erreurs, vous trouverez deux sous-onglets. Ils permettent de distinguer les erreurs à la compilation (build time) et les erreurs à l'exécution (run time). Et comme vous pouvez le constater, toutes les erreurs de SwiftLint sont bien du côté de la compilation.
Choisir ses règles
SwiftLint est installé avec plus de 75 règles prédéfinies. Vous pouvez les modifier et les désactiver. Je ne détaillerai pas le fonctionnement de ces configurations ici, mais c'est expliqué assez clairement sur le dépôt github du projet.
En résumé
Dans un projet, la propreté du code passe en premier par une uniformité de la syntaxe.
Pour assurer cette uniformité, on utilise un guide syntaxique (ou style guide).
Un lint permet de faire l'analyse statique du code, en se basant sur les règles définies dans un guide syntaxique. SwiftLint est le plus populaire pour Swift.
Dans la prochaine partie, nous allons attaquer l'un des sujets les plus importants en programmation, si ce n'est LE plus important...
Roulement de tambour...
Musique de suspens...
Accent dramatique...
