J'ai remarqué que la plupart des codeurs d'objectif-c n'utilisent jamais la syntaxe code> ivar code> lorsque vous accédez directement aux variables d'instance. La plupart des échantillons de code que je vois se réfèrent simplement à la variable d'instance sans Je me sens comme si je veux écrire des choses comme: P> auto -> code>. Je pense qu'il est plutôt confus de faire référence à une variable d'instance sans préciser que c'est une variable d'instance et non simplement une variable de la portée actuelle. - (void)setVar:(Foo *)newVar {
[self->var autorelease];
self->var = [newVar retain];
}
4 Réponses :
Il n'y a aucune raison pour laquelle vous ne devriez pas l'écrire de cette façon. Je pense que les gens ont tendance à l'écrire dans l'autre sens car ils essaient d'éviter de nuire à leurs ivars de toute façon, il ne devrait donc y avoir aucune ambiguïté dans quelle variable ils parlent - et c'est plus court.
Merci beaucoup pour la réponse rapide!
Chuck est correct en ce qu'il n'y a pas auto -> est stylistiquement plus propre, et il en résulte certainement moins de code verbeux. Personnellement, je trouverais le auto -> se distraire (surtout si le code est bien conçu et que les variables sont bien nommées) mais si cela rend les choses plus compréhensibles pour vous, par tous les moyens le faire. Sachez simplement que si vous montrez votre code à d'autres programmeurs de l'objectif-C, ils sont susceptibles d'avoir un avis contradictoire. Il est donc bon d'avoir une peau de réflexion. En outre, la plupart des programmeurs trouvent que leur perception de ce qui rend le code «se sentir bien» change au fil du temps et avec l'expérience, et ces opinions se motrissent souvent avec l'âge. : -)
Comme je l'ai dit, c'est plus court. Je préfère cela, mais je ne pouvais pas faire l'argument selon lequel les identificateurs plus courts sont toujours meilleurs, mais je détesterais maintenir le code qui est tout x, y et z. C'est donc essentiellement une question d'où vous trouvez votre support heureux. Je soupçonne que les pythonistes préfèrent probablement le formulaire auto -> . Bien sûr, vous ne devriez pas faire l'accès direct ivar très souvent dans l'objectif-C, de toute façon. Peut-être être peu attrayant est une autre vertu de la syntaxe auto -> .
MDR. "Pensez la peau". Est-ce que cette peau est une sorte de mince et épaisse?
Réponse courte: Non, vous n'êtes pas un mauvais programmeur à cause de cela :) Il n'y a pas non plus de bonne raison pour ne pas écrire de code de cette façon; La plupart des programmeurs sont simplement paresseux ou n'ont jamais vraiment écrit une méthode épuisante dans toute leur vie.
Réponse longue: techniquement lorsque vous accédez à une variable sans "auto-" ", le compilateur sera d'abord pour une variable de ce nom dans la portée locale et s'il ne peut pas en trouver un, il répète que la recherche avec des variables d'instance. S'il trouve un succès là-bas, il générera un code comme si "auto-> ..." avait été écrit là-bas. S'il n'y avait aucune correspondance pour les variables d'instance non plus, le compilateur essaierait au sein de la portée globale, BTW.
La plupart des programmeurs ne lisent que leur propre code et ils savent assez bien ce qui est une variable d'instance et ce qui n'est pas. Une fois que vous avez déjà dû travailler avec du code, vous n'avez pas écrit vous-même, où la méthode est de 4 pages d'écran long (et j'ai un écran BIGG), vous êtes vraiment reconnaissant lorsque le programmeur l'a rendu absolument clair sur chaque accès variable: est cette variable Un paramètre introduit à l'appel de méthode, une variable locale de cette méthode, une variable d'instance de l'objet ou éventuellement une variable globale (uniquement globale à toutes les instances de cette classe ou éventuellement d'application globale). Vous êtes reconnaissant, car s'il n'y a qu'un tas de variables avec un nom similaire et sans aucun modèle de nommage ou d'accès spécial, toutefois de type différent, vous perdez assez rapidement la surveillance. Et s'appuyer sur le fait que la surbrillance de la syntaxe Xcode met en évidence les variables d'instance d'une manière différente de celle des variables locales est également stupide, car aucun programmeur n'est obligé de modifier le code dans Xcode pour commencer et même s'il le fait, il peut avoir une palette de couleurs où l'instance Les variables ont la même couleur que celle locale.
Accéder à des variables d'instance via Self-> est parfaitement bien, mais considérez également A pour peut-être utiliser un préfixe / suffixe, qui fera également évident que ce sont des variables d'instance et évitent également les conflits de nommage avec des paramètres de la méthode ou des variables locales.
L'objectif c ajoute automatiquement un trait de soulignement sur le nom I-var, de sorte que lorsque vous voyez "_Somevar", il est implicitement de la portée de la classe. Le soulignement est suffisant d'un marqueur visuel pour que sa portée soit claire sans ajouter de soi ->.
Je suis d'accord avec vous, que si vous voyez _somevar publié dans dealloc ou défini dans un setter personnalisé, vous pouvez être raisonnablement confiant qu'il s'agit d'un ivar. Mais si j'ai vu quelque part dans ces contextes, je suppose probablement que c'était un ivar, juste un qui a été défini manuellement ou synthétisé manuellement (avec @synthesize ). En bout de ligne, c'est un peu fort de dire qu'un (indicatif de code> _ signifie qu'il est "implicitement" un ivar. Le soulignement n'est ni nécessaire ni suffisant. Mais vous avez raison que la meilleure pratique consiste à utiliser des propriétés, que des ivars soient synthétisés pour vous et ils auront le principal soulignement.