10 lignes pour une méthode

CéroceCéroce Membre, Modérateur
février 2016 modifié dans Objective-C, Swift, C, C++ #1
P.S.: tes méthodes sont trop longues, cherche à  les raccourcir. ça va considérablement améliorer la lecture, et tu vas commencer à  voir des ressemblances dans le code, ce qui signifie que tu pourras factoriser.

Une technique: si tu resents le besoin de dire dans un commentaire ce que fait le code qui suit, alors retire le commentaire et extrait le code dans une méthode.

Exemple:
 
// Modification imagepicto2
let modifImagePicto2 = ...
Remplace par une méthode:
func modifyImagePicto2() {
let modifImagePicto2 = ...
}

Réponses

  • Merci Céroce pour tes remarques. Mais je ne comprend pas pour la méthode plus courte, car c'est une action. Avec closures...



    // Modification imagepicto2
    let modifImagePicto2 = UIAlertAction(title: "Second choix", style: .Destructive) { action -> Void in
    self.e2L5Position2String = self.labelsResultat[4]

    self.bouches2eViewController.label2eProtrusion.textColor = self.ChoixColor

    self.imagePicto2.image = UIImage(named: self.imagesResultat[4])

    self.resultatRoue.removeFromSuperview()
    self.roueResultat()

    self.enregistrer()
    }
    alertModifQuelleImage.addAction(modifImagePicto2)
  • CéroceCéroce Membre, Modérateur
    Tu as une grosse seule méthode bouches2eNormalTap() qui mesure 118 lignes.
    Idéalement, il faut éviter de dépasser 10 lignes pour une méthode.

    Dans ton exemple, tu pourrais laisser l'appel dans la méthode parente:

    alertModifQuelleImage.addAction(self.alertActionForChoice2())
    Et extraire la création de l'action:

    func alertActionForChoice2() -> UIAlertAction {
    return UIAlertAction(title: "Second choix", style: .Destructive) { action -> Void in
    self.e2L5Position2String = self.labelsResultat[4]

    self.bouches2eViewController.label2eProtrusion.textColor = self.ChoixColor

    self.imagePicto2.image = UIImage(named: self.imagesResultat[4])

    self.resultatRoue.removeFromSuperview()
    self.roueResultat()

    self.enregistrer()
    }
  • Joanna CarterJoanna Carter Membre, Modérateur


    ah d'accord, je comprend mieux, merci.


     


    10 lignes par méthode, chui grave loin du compte dans mon projet...




     


    C'est pas obligatoire de ne pas dépasser 10 lignes mais c'est vraiment conseillé (moi, je préfère autour de 20)

  • Je ne suis pas forcément d'avis de la règle des " 10 lignes ".


    C'est mieux certes, mais les deux règles qui vont de primes à  mon avis, c'est : Lisibilité (et surtout relisible après 3 mois) avec une "structure" compréhensible, et surtout éviter la duplication de code, auquel cas, il faudrait faire une méthode.


  • Oups, merci pour les cours. Un peu pointu pour moi.


    Mais je me rend compte que quand je devrais publier l'appli pour de vrai (là  chui en tests testflight...) je vais souffrir.

  • Joanna CarterJoanna Carter Membre, Modérateur

    Oups, merci pour les cours. Un peu pointu pour moi.




    Si tu ne veux pas les mauvaises retours sur ton app, ces conseils seront très précieux.
  • ouais, je sais... :'(


  • CéroceCéroce Membre, Modérateur

    Je ne suis pas forcément d'avis de la règle des " 10 lignes ".
    C'est mieux certes, mais les deux règles qui vont de primes à  mon avis, c'est : Lisibilité (et surtout relisible après 3 mois) avec une "structure" compréhensible, et surtout éviter la duplication de code, auquel cas, il faudrait faire une méthode.

    J'ai bien écrit "idéalement". Ce n'est pas une règle absolue, ni toujours faisable, par exemple quand il y a des switch-cases " mais on n'utilise pas de switch-cases en POO, pas vrai ;-)

    Mais je persiste et signe, quand on atteint 10 lignes, il faut se demander si justement la méthode ne fait déjà  pas trop de choses (une fonction = un traitement), et si on ne duplique pas déjà  du code ou de la logique.

    Je ne vais pas continuer cette discussion, parce qu'elle ne sert à  rien si on ne parle pas de code concret. J'ai juste voulu donner une indication factuelle à  busterTheo pour qu'il améliore la lisibilité de son code et perde moins de temps à  déboguer.
  • L'utilisation de beaucoup de petites méthodes de 10 lignes ne risque pas d'avoir une influence sur les performances de l'application ? Du moins en Objective-C, puisque l'appel d'une méthode est une chose compliqué avec émission d'un message et résolution dynamique de-je-ne-sais-plus-quoi ?


    Swift doit être plus efficace sur cet aspect, le code étant entièrement compilé.

  • CéroceCéroce Membre, Modérateur
    La résolution des messages en Objective-C n'est pas si lente que ça. Heureusement, sinon nous ne pourrions tout juste pas travailler. La différence se mesure en nanosecondes, hein.

    Mais surtout, ce n'est pas la question: la plupart du code n'a pas besoin d'être rapide. À quoi sert de gagner 10 ms pour réagir à  l'appui d'un bouton ?

    On se pose ce genre de questions quand on a *mesuré* que l'envoi des messages posait problème à  un endroit précis.
  • Oki ..

  • Sur Android il y a une limite sur le nombre de méthodes (qui peut être contournée) embarquée appelée multidex. Faire des méthodes de 10 lignes auraient été difficilement réalisables pour les développeurs Android. Pas ce problème sur iOS par contre !


  • C'est une limitation de Java ?

  • Pas spécifiquement Java. C'est sur Android, pour une question d'optimisation de mémoire. Le code compilé est placé dans un seul fichier, un .dex qui contient apparemment cette limitation de méthode.


  • On n'est pas aidé par la technique ..


    Il n'était pas question d'un portage de Swift sous Android ?

  • Je pense qu'il a déjà  eu lieu mais je n'en suis pas sur.


Connectez-vous ou Inscrivez-vous pour répondre.