Tutoriel pour apprendre le nommage des paramètres pour les applications Objectif-C ou Swift

Si Objective-C est un langage réputé comme très verbeux et difficile à lire pour les développeurs, il n'a pas apporté que des points négatifs, loin de là. Je pense être plutôt exacte en affirmant qu'une grande partie des développeurs avec un peu d'expérience dans le langage Objective-C a apprécié, après un temps d'adaptation certes, la verbosité des noms de méthodes, ainsi que le nommage des paramètres.

On entend souvent dire de la part des grands détracteurs d'Objective-C (ce qui est un peu moins vrai avec Swift aujourd'hui) que le nommage des paramètres lors de l'appel d'une méthode est inutile et redondant : selon eux, une variable doit porter un nom assez explicite pour que le code soit compris facilement à la lecture. Loin d'être en désaccord avec cette logique, j'apprécie tout de même davantage lire un appel d'une méthode où je sais exactement à quoi va servir chaque paramètre, surtout dans une méthode qui en contient un certain nombre.

Par exemple, l'utilisation des paramètres nommés s'avère très intéressante dans le cas d'une méthode qui va permettre d'ajouter un élément dans un tableau à un index précis :

[legoBricks insertObject: redBrick atIndex: 3];

Littéralement (sans s'occuper de la valeur des paramètres), on pourra lire cette méthode de cette manière : insertObject:atIndex:. On identifie directement les paramètres (un objet et un index) ainsi que leur rôle dans la méthode, sans avoir besoin de faire appel à l'aide pour voir la signature de la méthode à chaque fois.

Reste le sujet délicat de trouver un nom de paramètre pertinent, qui ait un sens à la fois à l'intérieur de la fonction qui l'utilisera, mais aussi lorsqu'elle sera appelée, mais nous verrons ça un peu plus tard.

En bref, retenons, pour la suite de l'article, que le nommage de paramètres tel que le propose Apple ne doit pas être considéré comme un défaut en termes de développement, mais comme une manière différente (et moins ambigüe) de lire les méthodes.

Comme rappelé dans le paragraphe précédent, Objective-C, en parallèle de ses défauts, prenait déjà le parti du nommage explicite de paramètres, comme le faisait le langage dont il s'inspire, le SmallTalk.
Concrètement, la définition d'une méthode ressemble à cela :

@interface LegoAstronaut: NSObject
    /* déclaration de méthode */
    - (void)buildSpaceshipWithHeight:(int) height andWidth:(int) width;
@end
 
@implementation LegoAstronaut
    - (void)buildSpaceshipWithHeight:(int) height andWidth:(int) width {
        //code
    }
@end

Ici, outre la syntaxe peu habituelle pour un développeur C# ou Java par exemple, on remarque que le premier paramètre aura pour nom height, et… Attendez, le deuxième paramètre porte le nom andWidth ou width ? Eh bien tout dépend de quel côté nous nous plaçons. À l'intérieur de la méthode, ce sera sous le nom width que le paramètre sera utilisé.
En revanche, pour appeler la méthode buildSpaceshipWithHeight:andWidth:, il faudra donner à ce paramètre le nom andWidth. Cette dernière phrase étant certainement un peu floue, voici un exemple d'appel de la méthode buildSpaceship :

LegoAstronaut *benny = [[LegoAstronaut alloc] init];
[benny buildSpaceshipWithHeight: 12 andWidth: 42];

Encore une fois, mis à part les crochets et autres particularités liées au langage (qui ne sont pas le sujet de ce tutoriel), on remarque que lors de l'appel de la méthode buildSpaceshipWithHeight:andWidth:, le deuxième paramètre est appelé andWidth. Cela permet de lire et comprendre ce que fait la méthode de manière fluide, comme si on lisait une phrase.

Quant au premier paramètre, on ne peut pas vraiment dire qu'il porte un nom extérieur. En Objective-C, on va généralement compléter le verbe au début de la signature avec with…, from… ou by… par exemple. Dans notre cas, on retrouve withHeight: juste avant l'insertion du premier paramètre.

Finalement, pour revenir à la structure de la signature d'une méthode, chaque paramètre (sauf le premier) aura un nom local, utilisé dans le corps de la méthode, et un nom externe, qui sera concerné lors de l'appel.

Cette façon de faire n'est tout de même pas très pratique, et c'est en partie à cause de cela que l'Objective-C a la réputation d'avoir des noms de méthodes à rallonge. Mais c'est un fait auquel les développeurs ont dû s'accoutumer, car, jusqu'à présent, Apple ne souhaitait pas changer cette convention.

En juin 2014, Apple annonçait la sortie du langage Swift, une alternative moderne et developer friendly, qui vise à remplacer à terme Objective-C, qui est aujourd'hui moins adapté aux besoins et considéré comme un peu vieux, car trop proche du C.

Sans revenir en détail sur le sujet, Swift se rapproche beaucoup de langages largement utilisés aujourd'hui et en vogue, comme C#, Ruby ou Python. Cela dit, même s'il se revendique moderne, Swift garde certaines habitudes et conventions de son grand frère, et c'est justement le cas pour le nommage des paramètres.
Il faut cependant souligner que, bien qu'avec ce nouveau langage Apple conserve le nommage explicite des paramètres, on trouve tout de même un certain nombre de différences :

• les paramètres du constructeur d'une classe doivent tous être nommés au moment de l'instanciation ;
• l'utilisation du nom externe du paramètre devient optionnelle.

III-A. Le cas des constructeurs▲

class LegoBuilder {
    let name: String
    let isMasterBuilder: Bool
         
      init(name: String, isMasterBuilder: Bool) {
          self.name = name
          self.isMasterBuilder = isMasterBuilder
      }
}
 
LegoBuilder(name: "Emmet", isMasterBuilder: true)

III-B. Les paramètres externes▲

func sayHelloTo(name: String, repeat: Int) {
  for _ in 1...repeat {
      print("Hello \(name)")
  }
}
 
sayHelloTo("Mathilde", repeat: 3)

func sayHelloTo(name name: String)
{
    print("Hello  \(name) !")
}
sayHelloTo(name: "Mathilde")

func sayHelloTo(name: String, repeat iterations: Int) {
  for _ in 1...iterations {
      print("Hello \(name)")
  }
}
 
sayHelloTo("Mathilde", repeat: 3)

class Point
{
    let x: Int
    let y: Int
     
    init(_ x: Int, _ y: Int) 
    {
      self.x = x
      self.y = y
    }
}
 
Point(0,0)

Avec l'arrivée (toute fraîche) de Swift 2.2 et les précisions concernant la version 3.0, Apple a communiqué sur nombre de changements qui vont avoir lieu dans le langage. Pour la version 2.2, quelques modifications sont apportées, mais sans grand impact. C'est dans la version 3.0 qu'apparaîtra un point très demandé et donc attendu. Voyons tout cela en détail.

IV-A. Le choix des noms des paramètres est plus permissif▲

func sayHelloTo(name: String, repeat repeatCount: Int) {
    for _ in 0 ..< repeatCount {
         print("Hello  \(name) !")
    }
}
sayHelloTo("Taylor", repeat: 5)

IV-B. Disparition du mot-clé var dans les paramètres▲

func sayHelloTo(var name: String) {
    name = name.uppercaseString
    print("Hello  \(name) !")
}

IV-C. L'utilisation des paramètres externes dans les API Guidelines (Swift 3.0)▲

removeAtIndex(index: Int) -> Element

remove(at index: Int) -> Element

IV-D. Le nom du premier paramètre d'une méthode devient obligatoire (Swift 3.0)▲

Nous avons vu, au travers de ce tutoriel, le fonctionnement du nommage des paramètres de fonctions/méthodes dans le cadre d'applications écrites en Objective-C ou Swift, et les évolutions de sa syntaxe. Avec au départ quelques défauts, Apple a su s'adapter aux souhaits des développeurs, pour arriver d'ici quelques mois à un nommage des paramètres, certes toujours un peu verbeux, mais cohérent et beaucoup plus developer-friendly.

Nous tenons à remercier la société Soat qui nous a autorisés à publier ce tutoriel.

Nous remercions également Laethy pour la mise au gabarit et Claude Leloup pour la relecture orthographique.