Swift-style-guide: Utiliser soi-même

Je suis d'accord, et je suis aussi d'accord que ce sera un peu dur au début :)

Je suis d'accord avec ces deux accords.

Donc, à bas soi à moins que le compilateur ne gémisse à ce sujet !

Envoyé de mon iPhone

Le 10 juin 2014, à 5h48, Cesare [email protected] a écrit :

Je suis d'accord, et je suis aussi d'accord que ce sera un peu dur au début :)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Ce qui me dérange dans l'abandon de soi, c'est qu'il n'y a pas de moyen facile de
savoir immédiatement si une variable est une variable d'instance ou une variable locale.

Vous n'êtes pas d'accord ?

Le mardi 10 juin 2014, elephantronic [email protected] a écrit :

Je suis d'accord avec ces deux accords.

Donc, à bas soi à moins que le compilateur ne gémisse à ce sujet !

Envoyé de mon iPhone

Le 10 juin 2014 à 5h48, Cesare < [email protected]
<e i="16">

Je suis d'accord, et je suis aussi d'accord que ce sera un peu dur au début :)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45607945
.

Ce qui me dérange dans l'abandon de soi, c'est qu'il n'y a pas de moyen facile de
savoir immédiatement si une variable est une variable d'instance ou une variable locale.

De nombreux éditeurs que j'ai utilisés mettent en évidence les deux différemment. Espérons que Xcode suivra avec cette fonctionnalité.

Je n'utiliserais que self pour lever l'ambiguïté.

Le guide ne cible-t-il pas nos livres et tutoriels ? Je pense toujours utiliser moi-même
est plus lisible (mais je sais qu'apple ne l'utilise pas donc nous finirons par le faire
pas l'utiliser non plus)...

Le mardi 10 juin 2014, ColinEberhardt [email protected] a écrit :

Ce qui me dérange dans l'abandon de soi, c'est qu'il n'y a pas de moyen facile de
savoir immédiatement si une variable est une variable d'instance ou une variable locale.

De nombreux éditeurs que j'ai utilisés mettent en évidence les deux différemment. Avec un peu de chance
Xcode suivra avec cette fonctionnalité.

Je n'utiliserais moi-même que pour lever l'ambiguïté.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45625271
.

Convenu que nous devrions abandonner self

Apple ne l'utilise pas, donc je ne pense pas que nous devrions non plus. Je ne suis pas vraiment satisfait de cette décision du côté d'Apple, mais je pense que nous devrions suivre leurs conventions.

Je sais que je me suis dit moi-même, et je pense que je pense toujours cela, mais je viens de regarder le code dans le modèle de jeu Swift Sprite Kit. C'est GameViewController qui utilise self.view et self.classForKeyedUnarchiver. Voilà donc un exemple de propriété et de méthode standard, toutes deux utilisant self.

Dans la même classe, j'ai également trouvé deux instances de var compilées correctement comme let. J'espère que leurs modèles ne sont tout simplement pas prêts pour les heures de grande écoute, mais cela me fait réfléchir. J'aimerais voir comment certaines de ces choses progressent à travers les bêtas.

Je ne ferais pas trop confiance aux modèles ou aux exemples de code d'Apple. Ce n'est généralement pas le meilleur exemple de la façon de faire les choses... Ce même modèle termine également les lignes par un point-virgule, par exemple. :-)

Bon point. Nous devrions probablement ajouter des points-virgules partout aussi. ;)

--------- Message d'origine --------- Objet : Re : [guide de style rapide] Utiliser soi-même (#7)
De : "Matthijs Hollemans" [email protected]
Date : 11/06/14 03h19
À : "raywenderlich/swift-style-guide" [email protected]
Cc : "elephantronic" [email protected]

Je ne ferais pas trop confiance aux modèles ou aux exemples de code d'Apple. Ce n'est généralement pas le meilleur exemple de la façon de faire les choses... Ce même modèle termine également les lignes par un point-virgule, par exemple. :-)
-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je crois que self rend le code beaucoup plus clair. Cela permet de savoir très facilement s'il s'agit d'une propriété ou d'une variable d'instance. Pour la même raison, je vote pour toujours utiliser self dans objc pour les propriétés plutôt que d'utiliser leur variable d'instance _propertyName.

self le rend définitivement plus clair lors de la lecture d'un extrait de code. La vraie question est de savoir si cette clarté supplémentaire en vaut la peine.

Si vous tapez du code qui compile, il compile. Swift ne vous permet pas de compiler du code qui cache implicitement une autre variable/fonction d'une portée différente, nous n'avons donc pas besoin de dire self car si la méthode est la seule dans la portée, elle se compilera. S'il se trouve sur un autre objet _et_ cet objet, la compilation échouera jusqu'à ce que vous spécifiiez lequel vous voulez (en utilisant self, si nécessaire)

Obj-C est le seul langage que j'ai jamais vu qui demande aux gens de spécifier qu'ils possèdent ce qu'ils possèdent clairement, donc c'est bien que Swift l'ait supprimé.

Si vous écrivez une méthode, il ne devrait pas être difficile de voir quelles variables sont locales à cette méthode. En dehors de cette méthode, la portée n'a d'importance que pour le compilateur.

--------- Message d'origine --------- Objet : Re : [guide de style rapide] Utiliser soi-même (#7)
De : "ecerney" [email protected]
Date : 12/06/14 13h17
À : "raywenderlich/swift-style-guide" [email protected]
Cc : "elephantronic" [email protected]

Je crois que self rend le code beaucoup plus clair. Cela permet de savoir très facilement s'il s'agit d'une propriété ou d'une variable d'instance. Pour la même raison, je vote pour toujours utiliser self dans objc pour les propriétés plutôt que d'utiliser leur variable d'instance _propertyName.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je continue de ne pas être d'accord avec ce fil.

Ce style est censé être pour les auteurs de didacticiels et de livres et non pour
guide de style général sur Swift.

Dans le contexte de livres et de tutoriels où vous pouvez ajouter quelques lignes de code
d'une méthode à la fois, je pense qu'il est crucial d'utiliser soi-même pour s'assurer
le lecteur connaît le contexte de la variable.

Le jeudi 12 juin 2014, elephantronic [email protected] a écrit :

self le rend définitivement plus clair lors de la lecture d'un extrait de code. Le vrai
La question est de savoir si cette clarté supplémentaire en vaut la peine.

Si vous tapez du code qui compile, il compile. Swift ne vous laisse pas compiler
code qui cache implicitement une autre variable/fonction d'une portée différente, donc
nous n'avons pas besoin de dire self parce que si la méthode est la seule dans la portée,
ça va compiler. S'il se trouve sur un autre objet _et_ cet objet, il échouera
compiler jusqu'à ce que vous spécifiiez lequel vous voulez (en utilisant self, si
nécessaire)

Obj-C est le seul langage que j'ai jamais vu qui demande aux gens de spécifier que
ils possèdent ce qu'ils possèdent clairement, donc c'est bien que Swift ait supprimé
ce.

Si vous écrivez une méthode, il ne devrait pas être difficile de voir quelles variables
sont locaux à cette méthode. En dehors de cette méthode, la portée n'a d'importance que pour le
compilateur.

--------- Message d'origine --------- Objet : Re : [guide de style rapide]
Utiliser soi-même (#7)
De : "ecerney" < [email protected]
<_e i="31"/> Date : 12/06/2014 13h17
À : "raywenderlich/guide-de-style-rapide" <
[email protected]
<_e i="36"/> Cc : "elephantronic" < [email protected]
<e i="39">

Je crois que self rend le code beaucoup plus clair. Il est très facile de savoir
qu'il s'agisse d'une propriété ou d'une variable d'instance. Même raison pour laquelle je vote toujours
utiliser self dans objc pour les propriétés plutôt que d'utiliser leur variable d'instance

_nom de la propriété.

Répondez directement à cet e-mail ou consultez-le sur GitHub.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45927747
.

J'ai écrit un tutoriel Unity assez populaire. Il utilise C # et pas de soi. Je n'ai pas entendu de plaintes selon lesquelles les gens ne comprenaient pas d'où venaient les variables.

--------- Message d'origine --------- Objet : Re : [guide de style rapide] Utiliser soi-même (#7)
De : "Marin Todorov" [email protected]
Date : 12/06/14 14h16
À : "raywenderlich/swift-style-guide" [email protected]
Cc : "elephantronic" [email protected]

Je continue de ne pas être d'accord avec ce fil.

Ce style est censé être pour les auteurs de didacticiels et de livres et non pour
guide de style général sur Swift.

Dans le contexte de livres et de tutoriels où vous pouvez ajouter quelques lignes de code
d'une méthode à la fois, je pense qu'il est crucial d'utiliser soi-même pour s'assurer
le lecteur connaît le contexte de la variable.

Le jeudi 12 juin 2014, elephantronic [email protected] a écrit :

self le rend définitivement plus clair lors de la lecture d'un extrait de code. Le vrai
La question est de savoir si cette clarté supplémentaire en vaut la peine.

Si vous tapez du code qui compile, il compile. Swift ne vous laisse pas compiler
code qui cache implicitement une autre variable/fonction d'une portée différente, donc
nous n'avons pas besoin de dire self parce que si la méthode est la seule dans la portée,
ça va compiler. S'il se trouve sur un autre objet _et_ cet objet, il échouera
compiler jusqu'à ce que vous spécifiiez lequel vous voulez (en utilisant self, si
nécessaire)

Obj-C est le seul langage que j'ai jamais vu qui demande aux gens de spécifier que
ils possèdent ce qu'ils possèdent clairement, donc c'est bien que Swift ait supprimé
ce.

Si vous écrivez une méthode, il ne devrait pas être difficile de voir quelles variables
sont locaux à cette méthode. En dehors de cette méthode, la portée n'a d'importance que pour le
compilateur.

--------- Message d'origine --------- Objet : Re : [guide de style rapide]
Utiliser soi-même (#7)
De : "ecerney" < [email protected]
<_e i="40"/> Date : 12/06/2014 13h17
À : "raywenderlich/guide-de-style-rapide" <
[email protected]
<_e i="45"/> Cc : "elephantronic" < [email protected]
<e i="48">

Je crois que self rend le code beaucoup plus clair. Il est très facile de savoir
qu'il s'agisse d'une propriété ou d'une variable d'instance. Même raison pour laquelle je vote toujours
utiliser self dans objc pour les propriétés plutôt que d'utiliser leur variable d'instance

_nom de la propriété.

Répondez directement à cet e-mail ou consultez-le sur GitHub.

• 
  Répondez directement à cet e-mail ou consultez-le sur GitHub
  https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45927747
  .
  -
  Répondez directement à cet e-mail ou consultez-le sur GitHub.

L'argument "ça compile alors c'est bon" est faible. Je pense que nous devrions trouver notre style et nous y tenir. Ce n'est un secret pour personne que je privilégie la lisibilité à quelques touches supplémentaires à taper lorsqu'il s'agit de tutoriels. Je vote pour l'utilisation de soi.

Oui !!! Cesare est côté lisibilité ! On peut le faire!

4 ans de plus ! 4 ans de plus !

Je veux dire - utiliser self pour les variables de classe !

Le jeudi 12 juin 2014, Cesare [email protected] a écrit :

L'argument "ça compile alors c'est bon" est faible. Je pense que nous devrions trouver
notre style et s'y tenir. Ce n'est pas un secret que je privilégie la lisibilité
quelques touches supplémentaires à taper lorsqu'il s'agit de tutoriels. Je vote pour l'utilisation de soi.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45931720
.

Ok, que diriez-vous de cet argument?

L'utilisation forcée de soi est l'une des choses qu'Apple a supprimées lors de la création de Swift parce qu'ils ont vu à quel point c'était stupide et ont remarqué que toutes les autres langues du monde n'en avaient pas besoin et que tout le monde semble être d'accord avec ça, n'est-ce pas ? Si Apple le voulait, ils auraient facilement pu inclure self comme partie obligatoire du langage. Ils ont choisi de ne pas le faire pour la très bonne raison que c'est complètement inutile, et écrire des extras inutiles dans le code rend généralement les choses moins lisibles à long terme.

Obj-C était un langage construit au-dessus d'un autre langage. Des choses comme self ont été utilisées pour aider la syntaxe des crochets à indiquer une fonction Obj-C par rapport à une fonction C. Le compilateur ne comprenait pas les vraies classes et autres, ils ont donc dû créer une syntaxe spéciale pour le tromper.

Ce n'est plus nécessaire, et le conserver ne vous aidera ni vous ni nos lecteurs. Cela rendra en fait les choses plus difficiles lorsque vous essayez de lire le code des autres parce que vous serez tellement conditionné à vous voir que vous n'interpréterez pas les choses correctement si vous ne les voyez pas.

Lâchez les chaînes du passé et embrassez l'avenir. Vous vous sentirez mieux.

--------- Message d'origine --------- Objet : Re : [guide de style rapide] Utiliser soi-même (#7)
De : "Cesare" [email protected]
Date: 12/06/14 14h44
À : "raywenderlich/swift-style-guide" [email protected]
Cc : "elephantronic" [email protected]

L'argument "ça compile alors c'est bon" est faible. Je pense que nous devrions trouver notre style et nous y tenir. Ce n'est un secret pour personne que je privilégie la lisibilité à quelques touches supplémentaires à taper lorsqu'il s'agit de tutoriels. Je vote pour l'utilisation de soi.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je vois votre point @elephantronic et je suis peut-être d'accord avec vous mais dans 1-2 ans. La seule raison pour laquelle je propose d'utiliser self est qu'il m'est difficile (et je soupçonne beaucoup d'autres personnes) d'oublier complètement le passé. Si vous êtes un développeur Objc, vous êtes habitué à vous-même, si vous ne l'êtes pas, vous DEVEZ être capable de lire (sinon d'écrire) du code Objc. De toute façon, l'auto apparaît. Je vote donc pour l'utilisation de soi "pour le moment" et je propose de revoir ce problème dans un an environ, lorsque tout le monde sera plus familiarisé avec la langue.

Je vote pour ne pas utiliser self . Je suis d'accord avec @funkyboy que c'est dur au début. Mais je pense aussi pourquoi utiliserais-je le même nom pour l'instance var et la var locale, puis essayerais-je de résoudre l'ambiguïté? Ma compréhension de ce que @hollance a mentionné ( self.propertyName ) ne consiste pas à résoudre l'ambiguïté ou la lisibilité ; il s'agit de l'habitude que nous avons d'ObjC et apparemment ce n'est plus nécessaire dans Swift. Je vois self dans Swift en dernier recours : c'est-à-dire que le compilateur se plaint.

Est-il judicieux de soumettre celui-ci à un vote? Je pense qu'il y a eu des arguments bien pensés de chaque côté.

Je suis un +1 pour ne pas utiliser self là où ce n'est pas nécessaire.

Je suis également un +1 pour ne pas utiliser self lorsqu'il n'est pas nécessaire. Bien que je comprenne les préoccupations de Martin, je fais aussi pas mal de développement Android, et je vois _très_ rarement un this dans le code, bien qu'il soit parfois éclaté pour rendre quelque chose plus clair ou résoudre un conflit, c'est un beaucoup plus évident que vous ne le pensez lorsque vous utilisez une "propriété" par rapport à une variable locale.

J'ai vu Go quand j'ai regardé Swift pour la première fois, mais plus je regarde longtemps et plus fort, plus je vois Java.

+1 désintéressé

Assez juste, j'accepte le verdict démocratique :)
Permettez-moi de souligner une incohérence. En n'utilisant pas self, je pourrais en déduire que l'un des principes sur lesquels repose la directive est "ne l'écrivez pas si vous n'en avez pas besoin". Je n'aime peut-être pas ça, mais tant que c'est cohérent tout au long de la ligne directrice, je l'accepte. Je pense toujours que cela a un impact négatif sur la lisibilité.
Le même principe accompagne notre décision sur l'inférence de type, n'écrivez pas le type "parce que ce n'est pas nécessaire".
Si nous appliquons le même principe aux initialiseurs, nous devrions supprimer les noms externes des initialiseurs. Devine pourquoi? Parce qu'"ils ne sont pas nécessaires". Si nous "allons au minimum", faisons-le, mais totalement.

Nous avons convenu de ne pas écrire le type car il n'est pas nécessaire.

Nous avons convenu d'utiliser les valeurs par défaut de Swift sur les noms de paramètres, car c'est la valeur par défaut et cela n'a aucun sens de faire quelque chose de différent de ce que Swift veut que vous fassiez dans ces cas. Pour éliminer les noms de paramètres, vous devez écrire du code _extra_ puis l'expliquer.

--------- Message d'origine --------- Objet : Re : [guide de style rapide] Utiliser soi-même (#7)
De : "Cesare" [email protected]
Date : 12/06/14 18h30
À : "raywenderlich/swift-style-guide" [email protected]
Cc : "elephantronic" [email protected]

Assez juste, j'accepte le verdict démocratique :)
Permettez-moi de souligner une incohérence. En n'utilisant pas self, je pourrais en déduire que l'un des principes sur lesquels repose la directive est "ne l'écrivez pas si vous n'en avez pas besoin". Je n'aime peut-être pas ça, mais tant que c'est cohérent tout au long de la ligne directrice, je l'accepte. Je pense toujours que cela a un impact négatif sur la lisibilité.
Le même principe accompagne notre décision sur l'inférence de type, n'écrivez pas le type "parce que ce n'est pas nécessaire".
Si nous appliquons le même principe aux initialiseurs, nous devrions supprimer les noms externes des initialiseurs. Devine pourquoi? Parce qu'"ils ne sont pas nécessaires". Si nous "allons au minimum", faisons-le, mais totalement.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

self n'est que du bruit dans Swift, tuez-le. Nous nous adapterons.

Bonjour, désolé de réanimer le fil mort.

J'aimerais savoir comment vous vous sentez maintenant après avoir abandonné self ? Vas-tu bien maintenant? Y a-t-il eu des problèmes de lisibilité particuliers ?

Je l'ai abandonné et je n'ai jamais regardé en arrière. :)

Les livres et tutoriels de raywenderlich.com sont désintéressés depuis 4 ans maintenant et personne n'a eu de plaintes spécifiques.