Swift-style-guide: Utilisation de soi

Créé le 20 nov. 2017  ·  5Commentaires  ·  Source: raywenderlich/swift-style-guide

Salut,

Tout d'abord, merci d'avoir élaboré un guide de style à suivre. Je pense que c'est génial et très utile à bien des égards.

Cependant, je me demande s'il faut explicitement utiliser self pour faire référence à une variable locale ou appeler une fonction. Mon point est que nous devrions l'utiliser, car il peut être plus clair si quelque chose se trouve dans une classe (localement) ou non (globalement, singletons, etc.) en regardant simplement sa surbrillance de couleur.

Bien que la prise en charge de Swift fasse implicitement référence à self , cela ne signifie probablement pas nécessairement que ce serait une bonne pratique de le faire ?

Commentaire le plus utile

Mon avis : si vous avez besoin de vous-même pour voir si quelque chose est local ou une variable d'instance, alors votre méthode ou votre classe est trop grande.

Tous les 5 commentaires

Mon avis : si vous avez besoin de vous-même pour voir si quelque chose est local ou une variable d'instance, alors votre méthode ou votre classe est trop grande.

Pour moi, reconnaître que vous avez une auto-capture explicite dans les fermetures est trop précieux pour être caché avec un style qui utilise l'auto partout.

Cela dit, ce navire a déjà navigué pour le guide de style RW. Il faudrait un changement radical d'opinion pour le renverser.

@hollance @rayfix
Merci pour la réponse.

Je pense que lorsque les gens rejoignent une équipe avec une base de code relativement importante, ou révisent le code des autres, l'utilisation explicite de self rendra les choses beaucoup plus faciles à suivre, surtout lorsque les membres de l'équipe ont différents niveaux de codage compétences.

Personnellement, je ne vois pas (ou je n'ai pas vu) l'intérêt d'avoir une auto-capture explicite dans les fermetures. Au contraire, n'utiliser explicitement que self dans les fermetures rend le style de codage un peu incohérent.

Je suis d'accord avec le raisonnement d'Apple derrière le rejet de SE-0009 Exiger soi-même pour accéder aux membres de l'instance .

_* Obligatoire "soi". introduit une quantité importante de verbosité qui ne se justifie pas avec plus de clarté. S'il est vrai que « soi » obligatoire. peut empêcher une classe de bogues, le coût de l'élimination de ces bogues est assez élevé en termes d'encombrement visuel, ce qui va à l'encontre de la sensation généralement épurée de Swift. Paul Cantrell l'a bien exprimé dans sa revue https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html lorsqu'il a dit : « tout ce qui est largement répété devient invisible ». Swift vise à éviter de telles répétitions et répétitions dans sa conception, un principe également adopté par les Swift API Design Guidelines https://swift.org/documentation/api-design-guidelines.html ._

Il est préférable d'essayer d'améliorer la clarté en écrivant des méthodes et des classes plus petites (comme @hollance l'a également laissé entendre). L'utilisation de self dans les fermetures a plus de sens pour moi en raison du référencement faible/fort de soi.

Salut @RobertGummesson ,

Merci d'avoir ajouté la référence. Je suis tout à fait d'accord avec ce qui est mentionné, qui exprime une perspective plus neutre quant à l'utilisation explicite ou non de self. et explique les avantages/inconvénients.

Pour moi, la formulation « éviter d'utiliser self » est un peu trop forte. Comme RayWenderlich a une influence si importante dans la communauté, je pense qu'il serait plus approprié d'expliquer les avantages/inconvénients dans le guide de style et de laisser les développeurs décider eux-mêmes.

Cette page vous a été utile?
0 / 5 - 0 notes